Headscale vs Tailscale Explained: What Actually Differs

Most searches for headscale vs tailscale explained are one question with a hidden second half: can I keep the Tailscale client experience without the Tailscale account, and what does that cost me in work? The data plane answer is boring. Both run the same WireGuard tunnels between the same official clients, addressed out of 100.64.0.0/10, with the same NAT traversal and relay fallback. Everything that differs sits in the control plane: the service that authenticates devices, distributes the network map and hands down policy. Headscale swaps that component and leaves the rest alone.

One component changes hands, not the network

Tailscale’s open source page states the split: the client daemon is mostly open source, and “a closed source coordination server” is part of the architecture. Headscale fills that hole. Its README opens with a disclaimer that the project “is not associated with Tailscale Inc.”, though one maintainer is employed by Tailscale and permitted to contribute during work hours. Tailscale confirms this and calls Headscale “a community-maintained project, not Tailscale-managed or part of the supported Tailscale product.”

Scope is stated just as plainly. The FAQ says Headscale “implements a narrow scope, a single Tailscale network (tailnet), suitable for a personal use, or a small open-source organisation.” It is still on a 0.x line, v0.29.3 as of 29 July 2026, and upgrades may not skip minor versions. If the model underneath is unfamiliar, how a Tailscale mesh VPN works covers the layer Headscale reimplements.

Feature parity is close, and the gaps are specific

The features page is a checklist, which makes this a short argument. Supported: MagicDNS, split DNS, tags, subnet routers, exit nodes, route filtering with via, dual stack IPv4 and IPv6, ephemeral nodes, Taildrop, Taildrive, Tailscale SSH, ACLs and grants, auto approvers, policy tests, an embedded DERP server, and peer relays.

Three boxes are unchecked, plus one qualifier:

• Funnel (issue #1040), not implemented.
• Serve (issue #1921), not implemented.
• Network flow logs (issue #1687), not implemented.
• OIDC registration works, but OIDC groups cannot be used in ACLs.

That last one decides more migrations than the other three combined. You can register nodes through your identity provider, but you cannot write a policy rule against an IdP group: membership gets re-expressed by hand as Headscale users and tags, and stays that way. For a homelab, a non-issue. For a team provisioning access through Okta or Entra groups, it is the reason the SSO integration existed.

What you are signing up to operate

The requirements page is concrete: a server with a public IP, dual-stack v4 and v6 recommended, serving Headscale over HTTPS on tcp/443. That port is not really negotiable, because the Tailscale client assumes HTTPS on 443 in certain situations. Add tcp/80 for the Let’s Encrypt HTTP-01 challenge, udp/3478 for STUN if you enable the embedded DERP server, and keep tcp/9090 off the public internet.

Two support positions matter before committing. Container images exist, “but please be aware that we don’t officially support deploying headscale using Docker.” On reverse proxies the FAQ answer is “We don’t know. We don’t use reverse proxies with headscale ourselves.” Community docs cover both. Honest, but a different support surface from a vendor SLA.

SQLite is the default and the recommendation. PostgreSQL is “still supported, but is considered to be in maintenance mode”, and the shipped config calls it “highly discouraged as it is only supported for legacy reasons”, with no first-party migration tool back. The documented deployment is one process, one SQLite file under /var/lib/headscale, run as a dedicated system user; no active-active or failover topology is documented. You also inherit the patching, so the control plane’s advisories join everything else on that host, which is what aggregators like TechSentinel exist for.

The scaling ceiling is a map recalculation problem

The FAQ explains the bottleneck instead of quoting a device count. Headscale computes a map of every node that needs to reach every other node, and when an event changes it, “the whole world is recalculated, and a new world map is created for every node in the network.”

A thousand rarely-moving servers make that map expensive to compute once, after which the instance “will likely return to a very low resource usage until the next time there is an event.” Eighty laptops and phones make a cheap map recomputed constantly as devices roam. Overlap the two and usage stays pinned: in the documented worst case “the queue of nodes waiting for their map will grow to a point where Headscale never will be able to catch up.” Performance is explicitly not a development focus. Size against your fleet’s churn, not its count.

A related failure mode: a control plane outage does not tear down established tunnels, but it stops new enrolment, policy changes and map updates. Tailscale documents a default node key expiry of 180 days, after which “connections to/from the given endpoint will stop working.” Expiry is disableable per device, the standard move for subnet routers.

DERP is the one place self-hosting is easier

Headscale ships an embedded DERP server as a checkbox in the same binary. On the Tailscale side, custom DERP servers are documented as alpha and as “an advanced operation that requires significant resources on your part to set up and maintain.” The server needs direct internet access, not behind NAT or a load balancer, must allow ICMP, and needs 80, 443 and 3478 open. It breaks device sharing and other cross-tailnet features, and Mullvad exit nodes do not work with it. By default it supplements Tailscale’s DERP regions rather than replacing them; OmitDefaultRegions forces traffic through yours alone.

If relay latency is the real problem rather than metadata ownership, start with why Tailscale throughput drops on a relayed path and the mesh latency estimator before rebuilding a control plane.

Where the money math flips

Tailscale’s Personal plan is $0 with unlimited user devices, up to 6 users, up to 3 ACL groups, and up to 50 tagged resources to start. Standard is $8 per user per month for unlimited users, up to 10 ACL groups and SCIM. Premium is $18 per user per month and adds up to 300 ACL groups, network flow logs and log streaming.

Read that against the Headscale bill: a VPS with a public IPv4, a certificate and your time. At homelab scale Headscale saves nothing, because you were already free. What pushes people over are the three free-tier ceilings. At 10 users Standard is $80 per month, where a small always-on box becomes the cheaper line item, provided someone owns the upgrade path.

The other driver is not price. If policy requires that the device inventory and network map never leave infrastructure you control, that is a sovereignty requirement and the strongest argument for Headscale there is. Those requirements are increasingly regulatory rather than internal, the beat NeuralWatch tracks as governance frameworks get written down.

Picking one

• Under 6 users, no metadata mandate. Tailscale free. Headscale adds operational surface and buys you nothing you lack.
• You object to the hosted account, single small tailnet. Headscale. That is the stated design target, verbatim.
• You provision access from IdP groups. Tailscale, until OIDC groups land in Headscale ACLs.
• You need Funnel, Serve or network flow logs. Tailscale. Unimplemented upstream, not configuration you missed.
• Large fleet with high endpoint churn. Size the map recalculation cost from the scaling FAQ first.
• You want self-hosting with vendor support. Look wider: Tailscale vs ZeroTier vs NetBird covers products where self-hosting the whole stack is first-class.

The client config is identical either way, so a wrong first choice is recoverable. Start from the first tailnet setup guide and change the login server later.