Tailscale

A couple of weeks ago I asked Claude, via the Chrome extension on my Windows laptop, to find me the best-value used M1 MacBook Air on eBay. It was properly good at it. It searched with sensible filters, opened listings, read the descriptions for battery cycle counts and “cracked screen” small print, and left the three best tabs open for me to look through. Then I tried to picture doing the same from my phone on a day I’ve left the laptop at home, talking to the agents on my always-on dev VM. There’s no browser there. Claude Code’s web fetch tool gets blocked or served a stripped-down page by most retailers, eBay included. So I gave the VM its own browser: a real, headful Chromium in a Docker container. Claude drives it through Playwright MCP, I can watch and take over from my phone over VNC, and it’ll crop screenshots straight into this blog. Every image in this post came out of it, the cover included. ...

For about as long as I’ve been doing this, my laptop has been the computer: the IDE, the Docker daemon, forty browser tabs, all of it running locally, all of it dying the second the battery does or the lid has to close for a meeting. That model finally broke this year - not because of some clever trick, but because I moved the actual computer off the laptop entirely. The laptop’s job now is to open a window onto a machine that never sleeps, never loses its state, and honestly doesn’t care what OS it’s running. ...

Running large language models locally is genuinely useful — no API costs, no rate limits, and your data stays on your own hardware. The catch is getting GPU acceleration working inside a Proxmox LXC container, which involves a few non-obvious steps around driver installation and cgroup device passthrough. Why LXC and not a VM? VM GPU passthrough wasn’t an option here — no iGPU meant the host would have had no display output once the card was handed off. LXC was the practical solution, and it turns out to be a good one anyway: containers share the host kernel directly, so the GPU stays bound to the host’s NVIDIA driver and the container accesses it via bind-mounted device nodes and cgroup permissions. On top of that, LXCs are lighter weight than VMs, with less overhead and near-instant startup times. For a dedicated service like Ollama, it’s a solid fit. ...

In previous posts, I’ve explained how to use Tailscale’s MagicDNS and HTTPS certificate feature to generate a TLS cert for your Home Assistant install: Homeassistant Enable MagicDNS and HTTPS Certificates in Tailscale. That setup required you to reformat the TLS cert and copy it to the Home Assistant container… it wouldn’t be to much of a task to automate those actions, but fortunately there is now a superior method of applying and renewing a Tailscale cert for HASS (and many other self-hosted services). Let us dig in to that… ...

Tailscale is a virtual private network (VPN) service that allows secure remote access to resources across different networks. It offers a feature called MagicDNS that enables you to access your resources using a domain name instead of an IP address. Additionally, you can use HTTPS certificates to encrypt traffic between clients and servers, ensuring secure communication. In this tutorial, we’ll explain how to enable MagicDNS and HTTPS certificates in Tailscale and how to add a TLS certificate to Home Assistant using Tailscale. The most practical benifit for using Home Assistant within a Tailscale network is that it removes the requirement for network port forwarding and exposing services publicly, whilst still allowing your devices to access it from outside your local network. This blog post aims to give you the starting stes required to setup MagicDNS and HTTPS certificates in Tailscale, create a certificate on your home server and install that certificate in a Home Assistant docker container. ...