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

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

If you already have a home server, Headscale can run there when clients can reach it. The decision is whether sharing the homelab’s power and internet connection fits your recovery needs.

Headscale’s requirements ask for public reachability and recommend HTTPS on port 443 for production. A connection behind CGNAT may need another way to provide that reachability. A suitable home connection can qualify, with the shared power and uplink risks that come with it.

Choose an existing reachable host or an off-site host around those reliability needs. A small VPS is one way to separate the coordination server from the homelab; buying one is optional.

Before spending money, decide whether free Tailscale already covers your needs.

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 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.

For production, follow Headscale’s reachability requirements:

• A server reachable through a public IP address; dual-stack IPv4 and IPv6 is recommended.
• HTTPS on port 443, the recommended production setup for client compatibility.

An existing home server can meet those requirements when its network permits inbound access. A small VPS is another option. Check the chosen plan’s networking before relying on it.

Off-site hosting is a resilience recommendation: it separates the coordination server from the homelab’s power and uplink. That can reduce a shared dependency, but it cannot restore a home connection that has lost power or internet access. Choose the host around your recovery needs; no new hosting purchase is required if an existing host fits.

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 an existing hostname does not meet your needs, compare domain or hosting options before installing. Set up DNS and certificate issuance for the hostname you choose. A new domain is optional.

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 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

Shared power or uplink failures can make a home-hosted coordination server unavailable when the homelab needs attention. Plan how you will recover the service. An off-site host reduces that shared dependency, while adding its own cost and maintenance.

Use off-site hosting when that resilience benefit justifies the tradeoff. Reusing a reachable home server remains a valid option.