Headscale: Self-Hosting the Tailscale Control Server (2026)

By LK Wood IV · 2026-08-15 · ~8 min read · St. Louis County, MO

Most people who look up Headscale want to run it on the machine already humming in their closet. That is the one deployment it does not do.

Headscale’s own requirements page asks for a server with a public IP address, recommends dual-stack IPv4 and IPv6, and serves over HTTPS on port 443 because the Tailscale client assumes that in certain situations. If your home connection sits behind CGNAT, you have no public IP to hand it. If it does have a real public IP, you can technically proceed, and you will have built a coordination server that depends on the same uplink as everything it coordinates.

So the shape of a Headscale deployment is fixed before you write any config: a small host somewhere else, with a public address and a name you can put a certificate on.

That is the practical answer. The more useful answer is the next section.

First, the case against doing this

Tailscale’s free Personal plan covers up to 6 users with unlimited user devices, 3 ACL groups, and access to nearly all features. It costs nothing and it is explicitly intended for homelabs and personal projects.

Read that against your actual situation. One person, a NAS, a Proxmox host, three VMs, a laptop and a phone? You are not close to a limit. There is no bill coming. Headscale would replace a working, maintained, zero-cost service with one you patch, back up, and get paged about.

I want to be blunt, because the search results for this topic are not: for the majority of homelabs, Headscale solves a problem you do not have. Running it is a hobby in its own right, and that is a completely legitimate reason to run it. It is not the same reason as necessity, and the two get blurred constantly.

Three situations where it genuinely earns the work:

You object to the metadata, not the cost. Tailscale’s coordination server knows your device names, your public keys, and who connects to what. The traffic is end-to-end encrypted and they cannot read it, but the graph is theirs. If that specific fact is what bothers you, Headscale is a direct answer and no amount of free tier fixes it.

Your structure does not fit the Personal plan. More than 6 users, or an ACL model that needs more than 3 groups, and you are looking at a paid tier. At that point the comparison is a real one.

You want the control plane to survive theirs. Existing tailnets keep passing traffic when the coordination server is unreachable, but new nodes and key rotations do not. If your tolerance for that is zero, owning the control plane is the only fix.

Everything else — “self-hosting is better,” “I want to own my stack” — is preference, and preference is fine. Just price it honestly against a free service that already works.

What it does support

The 2026 feature list is broad, which surprised me. Node registration by web auth and pre-auth keys, MagicDNS, split DNS and search domains, tags, subnet routers, exit nodes with route filtering, dual-stack, ephemeral nodes, embedded DERP and peer relays, ACLs and grants, autogroups, Tailscale SSH, OIDC single sign-on, Taildrop and Taildrive, Funnel and Serve, network flow logs.

The documented gap worth checking before you commit: OIDC groups cannot be used in ACLs. If your plan was to point Headscale at your identity provider and let group membership drive access policy, that specific path is closed. Verify it against your intended policy now rather than after you have migrated forty nodes.

Headscale is not a Tailscale product. It reimplements a protocol it does not control, which is the standing structural risk with anything in this category and is worth naming even though the project has tracked upstream well.

The host

A control server does very little work. It coordinates key exchange and hands out routes, then gets out of the way while nodes talk directly. SQLite is the assumed database in the setup requirements, so there is no separate database tier to size.

What it needs is not capacity. It is position:

• A public IPv4 address. Dual-stack with IPv6 is recommended.
• Port 443 reachable, with a valid certificate.
• Uptime that is independent of the network it serves.

Any small VPS tier meets the first two. The third is the one people undercut by hosting it at home, and it is the whole reason the requirement exists.

There is one more reason not to put it on your home connection, and it is the sharpest: if Headscale is the thing that lets you reach your homelab remotely, and Headscale lives in your homelab, then you cannot fix your homelab remotely. You have built a mesh VPN whose failure mode is a locked door with the key inside. I would put the control server anywhere except the network it exists to let me into.

The domain

HTTPS on 443 means a certificate, and a certificate means a hostname. A subdomain on a domain you already own works fine — nothing about this needs a dedicated registration.

If you do not own one yet, this is the same purchase you would make for any public service, and it is worth doing before the install rather than during it. Certificate issuance is the step where a missing DNS record turns twenty minutes into an evening.

Where this sits against the alternatives

If you have not committed yet, the comparison is worth doing properly. I have written up Tailscale against plain WireGuard, which is the real decision for most people, and Tailscale against Cloudflare Tunnel for the case where you want to publish rather than connect. NetBird against Tailscale covers the other self-hostable mesh worth a look, and it is the one I would compare Headscale to most carefully, because it was designed to be self-hosted rather than adapted to it.

If you just want remote access to your homelab today and are not attached to owning the control plane, Tailscale on a homelab takes about ten minutes. If you want no third party in the path at all, WireGuard on Proxmox is the honest floor — more manual, no coordination server to run, no vendor.

What I have not tested

I have not run Headscale through a Tailscale client major-version bump, which is the failure mode I would most want data on before recommending it to someone whose remote access depends on it. The project tracks upstream well by reputation. Reputation is not a measurement.

I have not tested the OIDC integration, so I cannot tell you how painful the ACL group limitation is in practice, only that it is documented.

I have not run it at a scale where SQLite is the constraint.

What getting this wrong costs

The expensive version is not a failed install. It is a successful one, six months ago, on a box in the closet, which you have quietly come to depend on. Then the power blips while you are travelling, and the control server that would have let you back in is the thing that is down.

Put it somewhere else. That is most of the advice on this page.