Self-hosted Tailscale alternative: Headscale or NetBird?

Choose Headscale if you want to keep Tailscale clients and run your own control server for a single network. Choose self-hosted NetBird if you want its own clients, dashboard, management, signal and relay services on your servers.

In short:

• Headscale. Keep Tailscale clients while hosting control for a single network.
• Self-hosted NetBird. Run NetBird clients and its management stack on your servers.
• Managed Tailscale. Keep the vendor-run control plane if you don't want to maintain that infrastructure.

Don't assume either self-hosted choice reproduces every Tailscale feature.

Choose based on what you want to run

Use this decision table to match the network setup to your main requirement.

Headscale is a replacement for the Tailscale control server, not a separate client platform. Its stated scope is a single Tailscale network, also called a tailnet, for personal use or a small open-source organisation. That makes it a clear fit for a lab or small network whose requirements match its documented features.

NetBird fits when owning its management stack matters more than keeping Tailscale clients. Its dashboard, identity options and server services form a different platform, so choose it for that operating model, not because you expect it to reproduce every Tailscale feature.

Stay on managed Tailscale if its supported service matters more to you than owning the control server. Headscale is community-maintained, not Tailscale-managed or part of the supported Tailscale product.

See which parts run on your servers

The control plane registers devices and distributes network settings. It's separate from the traffic devices exchange. A relay carries traffic when devices can't connect directly, so owning coordination and owning that fallback path are separate choices. Check identity services and client settings separately too.

In the table below, "Headscale setup" means Headscale with Tailscale clients. Check which components you'll run and which still depend on other services.

NetBird's quickstart combines management, signal, relay and Session Traversal Utilities for NAT (STUN) in one server configuration. STUN helps discover connection details through network address translation (NAT). Those roles don't disappear because they share a deployment. They aren't a required count of separate containers.

NetBird includes built-in local user management, so you don't need an external identity provider just to manage accounts. You can also add an external provider for single sign-on (SSO), which lets users sign in through an existing identity service. Headscale supports OpenID Connect registration through an identity provider.

NetBird uses direct peer connections when possible and a relay when a direct connection can't be made. Hosting a relay yourself doesn't make every connection direct. It also doesn't remove your internet connection or any hosting provider you use.

Check the clients and features you need

Headscale's stable client documentation gives a platform list and compatibility target, while NetBird's architecture and quickstart describe its core services.

Headscale's client compatibility target is an aim, not a guarantee for every configuration. Some platforms need extra configuration to connect. Keeping the same Tailscale clients won't close the control-server gap. If you need a feature marked unchecked, that can rule out Headscale for your network.

Tailscale's client source availability varies by platform. Its source statement says you can build the Linux and Android clients yourself. You can build the Windows and macOS clients without the graphical user interface (GUI), so don't assume every client interface is open source.

Use Headscale's stable feature scope instead of assuming development-branch features are available. The stable pages don't identify a specific release number for all these claims, so check the version you plan to deploy. NetBird's architecture and quickstart aren't a complete, version-pinned client or feature matrix. Check every device and feature you need before you choose NetBird. Unconfirmed support doesn't mean a feature is absent.

Plan for updates and service failures

Your operating work includes updates, stored state, public reachability and enough capacity for coordination and relays.

Headscale requires upgrades through stable versions without skipping minor versions, using the latest available patch release at each stage. It recommends SQLite, while PostgreSQL remains supported in maintenance mode. For NetBird, the quickstart notes that Traefik and CrowdSec are updated separately from NetBird.

NetBird's quickstart requires a publicly reachable Linux virtual machine with at least 1 CPU, or processor, and 2 GB of memory. It needs Transmission Control Protocol (TCP) ports 80 and 443, plus User Datagram Protocol (UDP) port 3478. A public domain must resolve to the machine's public IP address. These are network-service requirements, not instructions to expose remote administration.

For either self-hosted setup, plan backups, restore tests, monitoring, certificate renewal and relay capacity. Headscale warns that many devices with frequent network changes can keep resource use high. A quiet server network and a frequently changing device network aren't comparable by device count alone. Managed Tailscale removes control-server hosting work, but you still manage devices and access policies.

Check the parts you still rely on

Map who runs coordination, relays, identity, client logging and hosting before you treat self-hosting as enough control. Headscale tells clients to disable central log submission by default, but clients apply that setting after a successful connection. That doesn't mean no logs were sent before the connection, or that no other logs exist. For NetBird, check log collection and retention separately from management-service ownership.

Before you move the network, test the access rules and relay fallback on representative devices you own or administer. Keep their original setup so you can restore access. Confirm that allowed traffic works and blocked traffic stays blocked. A successful direct connection doesn't show that the relay path works or that every future connection will be direct. Resolve any failed requirement before you move the rest of your devices.

Choose Headscale when retaining Tailscale clients and its documented single-network scope meet your needs. Choose NetBird when its own clients, management stack and confirmed controls meet them. Keep managed Tailscale if it provides a must-have feature your chosen self-hosted setup doesn't, or if you won't maintain the control plane.

Related guides

• Tailscale alternatives for private devices and services
• Tailscale SSH alternatives with separate host authentication