Headscale: A Self-hosted Tailscale Alternative for Private Cloud Access

In Post 2 of this series we introduced Tailscale as the UX gold standard in the mesh VPN segment. With one honest caveat: The control plane is proprietary, runs on AWS in the United States, and is officially not self-hostable. If you want the feature set and full sovereignty at the same time, you end up looking at a different solution.

That solution is Headscale. It is the open-source community reimplementation of the Tailscale coordination server API, BSD-3 licensed, compatible with the official Tailscale clients, and fully self-hostable.

That brings us to the most honest part of this series: We use Headscale at Infralovers ourselves. Our internal Infralovers Cloud has been running with Headscale as its control plane for over a year. This post is therefore not just an evaluation, but also a field report from our own operations.

As of May 2026, Headscale v0.28.0

What Headscale is

Headscale is an open-source reimplementation of the Tailscale control plane, written in Go and released under a BSD-3 license. It is not the thing you install to connect to a network. It is the thing you run so that others can connect.

Three properties define the project:

• Community-driven, with a Tailscale bridge: The maintainers are Juan Font Alonso and Kristoffer Dalby, who have been running the project for years. One of them works at Tailscale Inc. and is allowed to contribute during work hours, with the other maintainers reviewing his contributions. That is an honest, transparent bridge between the commercial product and the community variant.
• A deliberate scope: The stated audience is "self-hosters, enthusiasts, and smaller open-source organizations". A single Headscale instance serves exactly one tailnet (single-tailnet design). Multi-tenant is not in scope.
• Mature, but not an enterprise product: The current release is v0.28.0 from February 4, 2026, with 38.5k GitHub stars and 132 releases in total. The project is active, but kept deliberately small.

A clear differentiation from Tailscale Cloud and NetBird: With Headscale there is no hosted offering, no subscription, and no commercial hotline. What you get instead is full control.

Architecture in one picture

Five points explain the setup:

• The Headscale server is the control plane. It coordinates keys, nodes, ACLs, and MagicDNS entries. It is not in the data path.
• The official Tailscale clients connect to Headscale instead of the Tailscale cloud (tailscale up --login-server=https://hs.example.com).
• The WireGuard P2P mesh between nodes is identical to the native Tailscale data path. Headscale only influences who is allowed to know whom.
• DERP relays serve as the TURN fallback. You can register your own DERP servers or share the public DERP network from Tailscale.
• OIDC IdP for authentication, HuJSON ACL file for policies, both versioned in Git.

Because Headscale only handles coordination, it runs on surprisingly little hardware. A small VM is enough for mid-sized setups.

Feature overview

What Headscale ships today:

• MagicDNS with your own zone. Hostnames are resolved automatically across the tailnet.
• ACLs as a HuJSON file, fully versionable in Git and therefore GitOps friendly.
• Tags for nodes (e.g. tag:server for VMs, tag:ci for ephemeral CI runners).
• Ephemeral nodes that disappear automatically after a session, ideal for GitHub Actions or other CI workloads.
• Pre-auth keys for automated onboarding, with configurable lifetimes and tag assignment.
• Subnet routers and exit nodes like Tailscale.
• OIDC auth with Authelia, Authentik, Google, Kanidm, Keycloak, Microsoft Entra ID. Any OIDC-compliant provider should work.

Where Headscale (still) does not score

An honest word on the gaps, before we get to the field report:

• No official web UI. The third-party project headscale-ui (BSD-3, actively maintained, 2.6k stars) fills the gap, but it is not "first-class" from the project itself.
• OIDC groups cannot be used in ACLs (as of v0.28.0). If you need fine-grained group RBAC, you have to map it into Headscale tags.
• The mobile login flow is rougher than on Tailscale Cloud, because the official app defaults to the Tailscale cloud. On Android the custom server override works well, on iOS a browser step is required.
• Single tailnet per instance. Multi-tenant setups require multiple Headscale instances.
• Operational responsibility is entirely yours. Patches, backups, TLS, IdP integration, monitoring: all your problem.

How we use Headscale for the Infralovers Cloud

We picked Headscale over a year ago when we wanted to put our internal Infralovers Cloud on a clean, sovereign foundation. Here is the honest architecture:

Hosting: A dedicated instance hs-control runs only the Headscale control plane. Other VMs carry the applications. The separation is deliberate: an application issue must not take down VPN availability, and the blast radius of an incident stays small.

IaC: The entire setup is configured with Terraform and provisioned with Ansible. The repository lives in Git, changes go through pull requests, and CI deploys automatically.

Container runtime: Podman, not Docker. In front of Headscale, Caddy runs as a TLS reverse proxy. Caddy has excellent support for Headscale and handles Let's Encrypt certificate issuance without configuration acrobatics.

VPN-first security: SSH (port 22) on both VMs is only reachable through the VPN. Direct SSH from the internet is blocked at the firewall. Anyone doing maintenance enters the VPN first. For emergencies there is a console available in case the VPN itself has issues.

CI/CD integration: GitHub Actions runners connect as ephemeral nodes to the tailnet, equipped with the tag:ci tag. They get only the permissions the tag grants in the ACL, deploy, and disappear again. There are no persistent credentials in the CI configuration, which massively simplifies auth-key rotation and incident response.

MagicDNS: Hostnames are resolved automatically across the VPN. We get the same comfort as on Tailscale, but entirely under our own control and inside our own DNS zone.

Backups: The Headscale SQLite database, the ACL file, and the rest of the configuration live on a persistent volume. Restic backs the volume up daily to S3-compatible storage, with a "retention policy" and health checks.

Important: Headscale is classified as "Lab / Semi-Production" in our setup. We use it to distribute admin access to infrastructure and to protect internal services. We do not market our Headscale as an external service, and we deliberately do not use it for customer workloads.

If you find this stack interesting: We are currently also evaluating a migration to NetBird for parts of the setup, because the mobile experience there is smoother. The beautiful thing about this setup is that such a migration stays evaluable without any vendor dictating it. If you want to read more about NetBird, we have a good post about it.

EU sovereignty: with Headscale, finally on your side

Sovereignty is the thread running through this series, and Headscale is the piece where the answer ends up entirely in your hands:

• Headscale itself is BSD-3 open source and jurisdiction-neutral. Sovereignty is determined by your hosting target, not by the vendor.
• Hosting choice: In our case Hetzner Cloud in Nuremberg and Falkenstein, fully inside the EU. You could just as well pick IONOS, OVH, Open Telekom Cloud, or an on-prem environment.
• No outbound telemetry: By default, Headscale sends nothing back to Tailscale Inc. You can also run the DERP layer yourself, so that no byte leaves your own network.
• Audit: Full source-code access, plus your own logs and metrics. You always know what is happening.

For NIS2 and DORA contexts this means a clean mapping: The VPN vendor is you, which simplifies vendor assessment significantly. What remains is the classic sub-processor assessment of the compute hoster.

Where Headscale shines today, and where it does not

Strengths

• BSD-3, fully self-hostable, no vendor lock-in.
• Full compatibility with the official Tailscale clients.
• Low operational cost: A small VM is enough for mid-sized setups.
• Excellent fit for IaC stacks (Terraform, Ansible, Podman/Docker, GitOps).
• Clear tag and ACL model, perfect for CI use cases with ephemeral nodes.

Limitations

• No official web UI, with headscale-ui as a third-party solution.
• OIDC groups currently not usable in ACLs.
• The mobile login flow is more cumbersome than on Tailscale Cloud.
• Single tailnet, no multi-tenant.
• Operational responsibility fully on the operator.

When Headscale is the right choice

Four scenarios where Headscale clearly moves to the front of the field:

1) "We want Tailscale-grade comfort, but full sovereignty."

That is exactly what Headscale was built for. You keep the mesh VPN comfort, MagicDNS, and the official clients, and you take over the control plane entirely yourself.

2) "We are building a private cloud under our own control."

With Hetzner, IONOS, or OVH plus Headscale, you get a fully EU-operated mesh access path with no third party in the data flow. That is exactly our own stack for the Infralovers Cloud.

3) "We love IaC and CI/CD."

Terraform, Ansible, Podman, and Headscale together make a GitOps-friendly VPN stack. Ephemeral nodes for deployment pipelines are a killer feature, and we use it every day.

4) "We do not want recurring license costs."

Headscale is free. You only pay for the VM and your time. For small teams, the total cost of ownership is significantly below what Tailscale Standard ($8/user) or NetBird Team ($5/user) generate over the course of a year.

Conclusion

Headscale is the right choice when you like the comfort of the Tailscale ecosystem, but want to keep the control plane and the connection data in your own hands. We have used it at Infralovers for over a year and run our own private cloud on Hetzner with it. The trade-offs (no official web UI, rough mobile login, operational responsibility) are real, but for teams with an IaC and CI/CD mindset they are very manageable.

That makes this series complete from a content perspective. The closing direct comparison of NetBird, Tailscale, and Headscale along the axes of self-hosting, private cloud access, license cost, client comfort, and EU-first follows in Post 4.

If you are planning a sovereign private cloud, setting up a NIS2 or DORA program, or implementing a concrete Headscale deployment, we at Infralovers are happy to support you. We share our own experience from the Infralovers Cloud architecture and combine that with our training portfolio on Sovereign Cloud, NIS2 Compliance, and Cloud Native Essentials.