Tailscale Self-Hosted: Why I Love It

When it comes to remotely accessing your home network, not many tools are as simple to set up and easy to use as Tailscale. All you need to do is sign in with your credentials, and your devices are instantly connected to your private, encrypted tailnet. It’s got plenty of excellent features to play withbut there’s one issue for some people — Tailscale hosts the control plane.

Now, I’m not saying this is bad, good, or somewhere in between. The self-hosting community doesn’t like it when any part of their infrastructure is hosted on someone else’s server, and I won’t argue with them. The good news for those users is that Tailscale has an open-source, self-hostable version of the control plane, called Headscale. The devs are Tailscale staff, too, so it’s about as official as it could get without being official, and it has most of the features you might want to use.

I’ve been using it, and while I prefer the simplicity of Tailscale and not having to deal with the servers, it’s not too bad to get going, and you’ll get intimately acquainted with the CLI commands that Tailscale uses in the process.

What is Headscale and what does it do?

Self-host Tailscale’s control plane so all your data is yours

Tailscale works by setting up a decentralized mesh network called a tailnet, where centralized servers start the connection between the devices in the network before handing off so it’s peer-to-peer and fully encrypted. The central control server handles sharing IP addresses, locations, access control lists, and sharing the public keys that start the encrypted hand-off process, and those are run by Tailscale.

Headscale is a self-hostable version of those central control servers, so you can roll your own control plane and not have to rely on Tailscale’s infrastructure at all. That’s good peace of mind for the doomers that worry VC-backed companies like Tailscale might disappear one day or start charging large subscription fees, because at least the service can be used if the main company goes away.

It might not be the same experience and require more effort on the user’s part, but that’s part and parcel of the self-host experience and is understood by the users that want their own control servers.

Self-hosting comes with drawbacks

When I first heard about Headscale months ago, it was pretty barebones and didn’t have many of the features that Tailscale users have come to rely on. Now Headscale has the “base” support of Tailscale’s featuresplus most of the more advanced ones. The only things missing currently are some of the beta features like Funnel and Serve, network flow logs, dynamic ACL support, and the inability to use OIDC groups in ACLs.

You need the following networking requirements, and somewhere to host the Headscale server:

• TCP Ports: 80 (HTTP), 443 (HTTPS), 8080 (Headscale)
• UDP Ports: 3478 (STUN), 41641 (WireGuard direct connections)
• Domain name with DNS control (for TLS certificates)

The good news is you won’t need any ports forwarded or open for client networks. The biggest drawback is that Headscale is CLI-only, at least from the main devs. There are a few Docker variants with GUIs to use that come from the community, but these don’t have support for every feature, so you’ll end up using the CLI for many options. You’ll also need a reverse proxy set up to get the web-based GUI working.

It’s not a huge list of drawbacks to be sure, but it’s worth knowing what you’re in for. Also, the Headscale server now includes an embedded DERP server, which is the STUN-based fallback mode for connectivity between Tailscale devices. It might be worth self-hosting a second DERP server on another instance if you want the extra redundancy, and remember to turn off proxying in Cloudflare or wherever your DNS records are, as it’ll block the UDP packets that STUN needs.

Headscale can be a headache

Tailscale’s superpower is ease of use, self-hosting is more work

The beauty of services like Tailscale for me is that somebody else has done the necessary, and I can just sign in and use my network. I have a set of maxims that I use in the home lab and one of those is about offloading everything I don’t like, to focus on the things that interest me. Usually, complicated networking setups go in the first pile, but being able to self-host Headscale got me interested enough to try it out.

The setup was surprisingly simple, even with my rusty CLI skills. I’m going to wipe the VPS and reinstall Debian for long-term use, so that I can use the Docker stack of Headscale, one of the GUIs that the community has created, and a reverse proxy like Nginx, Caddyor Traefik to make the web GUI connect. It’s not that I don’t like doing things in the command line, but it’s often easier to use a local dev environment to wrangle YAML and other setup files, and push them to the server when done.

I’m not the intended user of Headscale, and I’ll fully admit that I’m going back to my usual tailnet. Being able to see how the control plane works from the inside has given me a new appreciation for the work that Tailscale and other next-gen VPN providers put in. My home lab experimentation time is fairly limited, and I want to spend the time I do have on other things, not on managing my VPN solution.

For those of you that do want to self-host Headscale long-term, more power to ya. Every computing decision is a trade-off between time, security, ease-of-use, and other considerations, and I appreciate that your internal calculus comes to a different solution than mine.

Headscale gives you full control over your tailnet

The Wireguard VPN protocol has enabled a new breed of mesh VPN solutions, able to create VPN connections that would have been unthinkable before. They quickly get complicated to manage, and that’s where the automated control plane of Headscale comes in. It’s only missing a couple of features from the servers that Tailscale manage on our behalf, and lets us keep our VPN data on our own hardware from start to finish.