Headscale vs Nebula (2026): Two Very Different Ideas of a Self-Hosted Mesh

Both projects answer the same question - how do I run a private mesh network without paying a company to hold the map - and they answer it in almost opposite ways. Choosing between them is not really a performance decision. It is a decision about which client software you are willing to depend on, and which failure you would rather explain to your colleagues.

The one-sentence version

Headscale replaces the Tailscale coordination server with one you run, keeping the official clients and the WireGuard data plane. Nebula replaces everything, with its own protocol, its own binary and a certificate authority you operate yourself.

Where the trust actually lives

This is the difference that outlasts every feature comparison.

In a Headscale network, a machine joins by authenticating to your control server. You own that server, so you own the decision - but the client is software maintained by Tailscale Inc., pointed at your server by overriding the login URL. That arrangement has held for years, and it is not contractual.

In a Nebula network, a machine joins because it holds a certificate signed by your certificate authority. You generate that CA, and it never has to leave the machine you generated it on. Nothing enrols without your signature. The cost is that certificate lifecycle - issuing, distributing, expiring, revoking - becomes your job from day one rather than a thing you grow into.

Neither model is safer in the abstract. One asks you to trust a client vendor's continued tolerance; the other asks you to be competent with a CA.

A dense fibre patch panel seen at a sharp angle, with rows of turquoise duplex connectors on the right and pale aqua and yellow fibre cables looping away to the left — A fibre patch panel with rows of turquoise duplex connectors, cables looping away to the left. Both projects are ways of deciding, in software, which of these paths a packet is allowed to take.

How each one finds its peers

Nebula uses lighthouses: nodes with a stable, reachable address whose job is to know where everyone is and introduce peers to each other. They are ordinary Nebula nodes with one flag set, they carry very little traffic, and you typically run two on cheap VPS instances.

Headscale plays the coordination role itself, distributing keys and the network map, with DERP relays for traffic that cannot establish a direct path. You can run your own DERP rather than using public ones.

The architectures rhyme. What differs is the operational shape: Nebula's lighthouse is a node in the mesh, Headscale's control plane is a service with a database behind it.

Firewall rules, and where they are enforced

Nebula puts a host firewall in the node's own configuration. Each host declares which inbound connections it accepts, expressed in terms of certificate groups rather than IP addresses. Enforcement is local, which means a compromised control plane cannot silently open a host.

Headscale expresses access control as Tailscale-compatible ACLs, defined centrally and pushed out. One file describes the whole network, which is far easier to audit and reason about - and which puts more weight on that file being right.

Centralised policy is more legible; distributed policy is harder to defeat from one place.

A practical way to choose

If this is true of your fleet	Lean toward
Laptops and phones used by people who should not manage certificates	Headscale
Servers, containers and appliances you already configure declaratively	Nebula
You want MagicDNS, exit nodes and a familiar login flow	Headscale
You want zero dependency on any vendor's client roadmap	Nebula
Your instinct is that a compromised control plane must not open hosts	Nebula
Your instinct is that one auditable policy file beats many	Headscale

What we would not claim

Throughput comparisons between the two circulate widely and mostly measure the machine they were run on. WireGuard commonly runs in the Linux kernel while Nebula's transport runs in userspace, which tends to favour WireGuard on a Linux server - but on saturated links, on other operating systems, or on modest CPUs, that advantage often vanishes into the noise. If throughput is genuinely your deciding factor, the only number worth having is the one you measure on your own path, with your own hardware, on the route your traffic actually takes.

★ Nuremberg GDPR datacenter · ✓ Dedicated IPv4 included · 200+ Mbps guaranteed

Self-host your VPN on your own VPS → ContaboFull root access · public IPv4 · pick your region→

Frequently asked questions

What is the core difference between Headscale and Nebula?

Headscale is an open-source reimplementation of the Tailscale control server: it coordinates a mesh whose data plane is WireGuard, and the machines run the official Tailscale clients pointed at your server. Nebula is a complete overlay network of its own, built by Slack, with its own protocol, its own client binary, and its own certificate authority that you generate and hold. Headscale replaces one company's server; Nebula replaces the whole stack.

Which one is easier to set up?

Headscale, for most people, because the clients are the polished official Tailscale apps and enrolling a machine is a login command. Nebula asks you to run a certificate authority from the first minute - you generate a CA key, sign a certificate per host, and distribute config files. That is more work up front, but it is also explicit: nothing joins your network without a certificate you signed.

How does each one handle nodes behind NAT?

Both punch holes through NAT and both need a helper for the cases where that fails. Nebula calls its helpers lighthouses: always-reachable nodes that hold the map of who is where and assist with introductions. Headscale plays the role Tailscale's coordination server plays, and falls back to DERP relays for traffic that cannot go direct - you can host your own. The concept is the same; the naming and the operational burden differ.

Is Nebula faster than WireGuard-based Headscale?

There is no single honest answer, and anyone quoting one figure is describing their own hardware. Nebula implements its own encrypted transport in userspace using the Noise framework, while WireGuard usually runs in the kernel on Linux, which tends to favour WireGuard on a Linux server. On other platforms, and on links where the bottleneck is the network rather than the CPU, the difference often disappears. Benchmark your own path before treating throughput as the deciding factor.

What happens to each network if the control server goes down?

This is the question worth asking, and both degrade rather than collapse. Existing Nebula tunnels keep working without a lighthouse; what breaks is discovery of peers you have not talked to recently. With Headscale down, established WireGuard tunnels also persist, but key rotation, new enrolments and ACL updates stop. In both cases the mesh keeps carrying traffic while losing its ability to change - so plan backups of the control plane's state, not high availability of its uptime.

Which should I choose for a small team?

If the machines are laptops and phones belonging to people who should not have to think about certificates, Headscale wins on client experience - the official apps, MagicDNS and a login flow people already understand. If the fleet is servers, containers or appliances that you configure anyway, Nebula's certificate model is a better fit and removes any dependency on one vendor's client roadmap.