WireGuard vs Tailscale vs Headscale vs NetBird: The Self-Hosted Mesh VPN Decision

Answer first: it's not "WireGuard vs Tailscale"

WireGuard is a protocol — the thing that actually encrypts and moves your packets. Tailscale, Headscale, and NetBird are control planes built on top of that protocol: they handle key distribution, peer discovery, NAT traversal, and access policy so you don't hand-edit config files. So the popular query "WireGuard vs Tailscale" compares a protocol to a product. The real decision is who runs your control plane. Here's the short version:

• Tailscale — you want a mesh VPN that just works, run by someone else, with the best client experience and zero control-plane ops. The trade is a closed, hosted coordination server and per-user pricing.
• Headscale — you want Tailscale's exact client experience but with the coordination server self-hosted. Open-source, community-run, single-tailnet scope.
• NetBird — you want a fully open, fully self-hostable stack (client and control plane), with built-in identity/SSO and group-based access policy, and you're willing to run more moving parts.
• Raw WireGuard — you have a small, static topology, you want maximum control and the leanest possible data path, and you'll manage keys and config yourself.

The rest of this article is the map, the decision table, the performance reality (with real mechanism, not hand-waving), and an operator's verdict.

The map: protocol, control plane, relay

Almost every comparison in the search results skips the one diagram that makes this whole space click. Here it is as a layered model — each product is a different set of choices at each layer:

Two consequences fall out of this model immediately:

• Because every option uses the same WireGuard data plane, the encryption and the raw packet path are essentially the same. Differences in throughput come from how WireGuard is implemented (kernel vs userspace) and whether traffic goes direct or via a relay — not from the protocol.
• "Self-hosted" means different things per product. With Headscale you self-host the coordination server but still use Tailscale's official clients. With NetBird you can self-host everything. With Tailscale you self-host nothing (though you can run your own DERP relay). That distinction is the whole decision, and the table below turns it into criteria.

The decision table

These are the dimensions people actually choose on. Pricing is per the vendors' pages as of July 2026 and moves often — re-check before you commit.

A few cells deserve expansion because they're where people get surprised.

Client openness is not control-plane openness. Tailscale's clients are open source; its coordination server is not. That's the exact itch Headscale scratches — it's an open-source reimplementation of that server you run yourself, paired with Tailscale's official clients. NetBird is open source end-to-end (with the management, signal, and relay components under AGPLv3 and the rest BSD-3-Clause).

The WireGuard implementation differs, and it's measurable. Tailscale's client uses a userspace WireGuard (wireguard-go); NetBird uses the kernel WireGuard module on Linux when it's available, falling back to userspace only when it isn't. That single fact is the root of most throughput differences between them — explained next.

Performance: where the differences actually come from

Everyone repeats "they all use WireGuard so throughput is identical." That's true for the protocol and false in practice, for two concrete reasons: kernel vs userspace, and direct vs relayed.

Kernel vs userspace WireGuard

The kernel WireGuard module processes packets inside the kernel. A userspace implementation like wireguard-go has to move each packet across the user/kernel boundary, and that per-packet syscall overhead — not the encryption itself — is the tax. It scales with packet rate, so it shows up most on high-throughput, small-packet workloads.

How big is the gap? Use the numbers from the people who wrote the userspace implementation. Tailscale's own engineering blog reports an in-kernel WireGuard baseline of 2.66 Gbit/s versus wireguard-go at 2.42 Gbit/s in the same test — and, after adding segmentation-offload and batching optimisations, their userspace path reached 5.36 Gbit/s, actually beating the unoptimised kernel baseline. They also showed that raising the MTU from 1500 to 9001 alone moved wireguard-go from 2.42 to 7.88 Gbit/s. Read those honestly: on a default-MTU, unoptimised setup, userspace pays a real penalty; with jumbo frames and modern offloads, the userspace path can be very fast. The community rule of thumb of a ~10–15% penalty for userspace on default configs is directionally right but config-dependent.

The practical takeaways:

• If you need to saturate a fast link with a single flow and want the leanest path, raw kernel WireGuard (or NetBird's kernel mode on Linux) has the edge on a default config.
• MTU matters more than the product choice. A misconfigured overlay MTU (WireGuard's interface default is around 1420 to leave room for encapsulation) costs you more throughput than kernel-vs-userspace does. Get MTU right first.
• For the vast majority of real traffic — many small flows, well under a gigabit — the difference is imperceptible and you should choose on ops and features, not benchmarks.

Independent benchmarks bear those takeaways out. A University of Amsterdam study over a 1 Gbit/s link found kernel WireGuard and userspace wireguard-go both saturated the link (~900 Mbit/s) — but wireguard-go burned 230% of a CPU core to do it, versus well under one core for the kernel module. The userspace tax is CPU, and it only becomes a throughput ceiling once the CPU is the bottleneck (faster links, smaller packets). On real 10 GbE hardware, Protectli measured raw kernel WireGuard at 4.15–5.01 Gbit/s (iperf3, four streams) across its mid-range appliances; on a modest 2016-era desktop over gigabit, TechOverflow measured Tailscale at 354/194 Mbit/s — about half what the same link did without it, exactly the weak-CPU case where the userspace path is the limit.

The one head-to-head worth citing is NetBird's own, and it's refreshingly honest: testing NetBird 0.68.3 against Tailscale 1.96.4 on cloud hosts, both hit ~1.26–1.30 Gbit/s over a same-country datacentre link, and the author — writing on NetBird's blog — concluded the two are "basically the same … no consistent, repeatable advantage." That's the honest bottom line: on capable hardware these all keep pace with each other; the kernel-vs-userspace gap only surfaces when CPU is the bottleneck, and MTU usually matters more than the product you picked.

Direct vs relayed, and NAT traversal

When two peers can open a direct connection, WireGuard runs peer-to-peer and you get the numbers above. When they can't — CGNAT on both ends, strict firewalls, blocked UDP — traffic falls back to a relay, and a relay is a shared, geographically-placed extra hop that adds latency and can cap throughput.

• Tailscale and Headscale use DERP (Designated Encrypted Relay for Packets). DERP forwards already-encrypted WireGuard packets, so it can't decrypt your traffic; it's a fallback, not a man-in-the-middle. You can self-host a DERP node to control where relayed traffic goes.
• NetBird uses ICE (STUN to discover public mappings, TURN to relay) and has been moving from Coturn to its own WebSocket-based relay.

How often does that fallback actually happen, and what does it cost? Tailscale is the only one to publish hard numbers, and they're reassuring: it reports "direct NAT traversal well north of 90%" in typical conditions — more than nine connections in ten end up direct rather than relayed — though it doesn't break that down for the hard cases (CGNAT on both ends, symmetric NAT), where the odds fall. When a connection does ride a relay, the latency cost tracks how far away the relay sits: in one Tailscale case study on an India-to-US path, routing through a distant DERP node measured 452 ms against 298 ms for a closer near-direct path — roughly 150 ms of avoidable detour. NetBird publishes no equivalent success-rate figure, so for it — and for your own network, whatever the tool — the direct-vs-relay outcome and the relay's latency penalty are things to measure rather than assume.

The four options, honestly

Raw WireGuard

Strongest claim: the leanest, fastest, most auditable option — a tiny, in-kernel codebase with no control plane to trust or run. For a handful of static peers (a few servers, a site-to-site link), nothing beats it for simplicity and performance. We use it exactly this way in our site-to-site VPN with WireGuard on VyOS guide.

Sharpest limitation: it has no control plane, and that's fine until it isn't. Past roughly ten peers, hand-managing keys, IP allocation, and the AllowedIPs mesh becomes real work, and there's no built-in NAT traversal — peers behind CGNAT need a relay you build yourself. The moment you want SSO, ACLs, or automatic peer discovery, you're rebuilding what the other three already are.

Tailscale

Strongest claim: the best experience in the category. The clients are excellent on every platform, NAT traversal "just works" via DERP, SSO and ACLs are first-class, and there's zero control-plane to operate. If your goal is a working mesh this afternoon and you don't want to run infrastructure, this is the shortest path.

Sharpest limitation: the coordination server is closed source and hosted by Tailscale, and pricing is per-user — a free Personal tier (6 users, unlimited devices as of July 2026), then Standard at $8/user/month and Premium at $18/user/month. For an infrastructure team that's fine; for a large or cost-sensitive fleet, the per-seat model and the closed control plane are the two things that push people toward Headscale or NetBird.

Headscale

Strongest claim: Tailscale's client experience with a control plane you own. You run one open-source server (currently v0.29.x as of July 2026) and point the official Tailscale clients at it — so you keep the polished apps while the coordination, keys, and ACLs live on your hardware, with no per-seat bill. ACL support (the policy v2 engine) and an embedded DERP relay are in place.

Sharpest limitation: it's a community project scoped to a single tailnet — deliberately not the multi-tenant, enterprise-console product Tailscale sells. There's no official admin GUI (UIs are third-party), and the project explicitly says it doesn't support running behind reverse proxies or in containers, even though people do. It's a great fit for one team or one organisation; it's not trying to be a managed platform.

NetBird

Strongest claim: the most open and the most feature-complete self-hosted option. Client and control plane are both open source and fully self-hostable, it ships identity/SSO (an embedded IdP in the default self-host stack, plus OIDC to Keycloak/Authentik/Entra/Okta), group-based access policies, and it uses kernel WireGuard on Linux for the fastest data path. Recent releases even added a built-in reverse proxy for exposing internal services without opening ports (beta). If "self-host everything, with identity built in" is the goal, NetBird is the most complete answer.

Sharpest limitation: it's the youngest and the heaviest to run — management, signal, and relay services plus an IdP, versus Headscale's single binary. It moves fast (v0.74.x as of July 2026, with frequent releases and some features still in beta), which is great for capabilities and means you're tracking a faster-moving target. Budget more setup and upgrade attention than Tailscale or Headscale.

The operator angle the vendor SERP ignores

Half the search results for this topic are written by NetBird (their own knowledge hub) or a vendor partner, and none of them cover the case that matters to an infrastructure operator: using a mesh to reach management and out-of-band networks safely.

The pattern is a WireGuard-based mesh with subnet routing — a relay/exit node inside a protected network advertises routes to it, so authorised mesh members can reach an IPMI/BMC VLAN, an OOB management segment, or an internal service network without exposing any of it to the public internet. Done well, this replaces the "jump box on a public IP" pattern with an identity-gated overlay: access is tied to SSO and revoked centrally, the management plane never has a public listener, and every hop is WireGuard-encrypted end to end. Tailscale, Headscale, and NetBird all support subnet routing; the choice among them is the same control-plane-ownership question as everywhere else — with the extra weight that, for infrastructure access specifically, many operators want the coordination server on their own hardware (Headscale or self-hosted NetBird) rather than a third party's.

The practical guidance for that use case: advertise only the specific management subnet you need rather than a broad route, gate it behind an ACL tied to the smallest possible group, and keep the subnet router itself patched and monitored — it has just become a bridge into your most sensitive network, so it earns the same scrutiny as a bastion host.

Verdict, with conditions

• Choose Tailscale if you want the least operational burden and the best clients, you're comfortable with a closed hosted control plane, and per-user pricing fits your team size. It's the right default for zero-ops teams.
• Choose Headscale if you love the Tailscale experience but need the coordination server on your own hardware — one team or organisation, single tailnet, no per-seat bill. The cleanest "Tailscale UX, self-hosted control" answer.
• Choose NetBird if you want everything open and self-hosted, with identity/SSO and access policy built in, and you can run a few more services to get it. The best fit for a fully-owned zero-trust mesh.
• Choose raw WireGuard if your topology is small and static and you want the leanest, fastest, most auditable path — and you're happy managing keys and config yourself.

For an infrastructure operator specifically, the tie-breaker is usually control-plane ownership for management-network access: that pulls toward Headscale or self-hosted NetBird over the SaaS option, even when Tailscale would be the easier day-one choice.

Frequently asked questions

Is Tailscale just WireGuard?

No — Tailscale uses the WireGuard protocol for its data plane, but adds a whole control plane on top: a coordination server for key distribution and peer discovery, DERP relays for NAT traversal, SSO, and ACLs. And it uses a userspace WireGuard implementation (wireguard-go) in its client rather than the kernel module. So Tailscale is WireGuard plus everything WireGuard deliberately leaves out.

Is Headscale production ready?

For its intended scope, yes — a single tailnet for a team or organisation, run by people comfortable operating one open-source server. It supports ACLs and an embedded DERP relay and pairs with the official Tailscale clients. What it is not is a multi-tenant, GUI-managed enterprise platform — that's Tailscale's paid product. Match Headscale to a single-org deployment and it's solid; expect to drive it by CLI/API and to supply your own OIDC.

Can NetBird be fully self-hosted?

Yes — that's its defining feature. Both the clients and the control plane (management, signal, and relay services) are open source and self-hostable, and the default self-host stack includes an embedded identity provider, so you can run the entire mesh — including SSO — on your own infrastructure with no dependency on a vendor's cloud.

Which is fastest?

On a default configuration, raw kernel WireGuard (and NetBird's kernel mode on Linux) has a small edge over userspace implementations like Tailscale's, because it avoids per-packet user/kernel crossings — Tailscale's own benchmarks put kernel WireGuard at 2.66 Gbit/s versus 2.42 for unoptimised wireguard-go. But MTU and whether a connection is direct or relayed swing throughput far more than the product choice does, and for typical sub-gigabit traffic the difference is imperceptible. Choose on ops and features, not on a benchmark, unless you're saturating fast links.

Where to run the control plane, relay, or exit node

Every option here except pure SaaS Tailscale needs a host: Headscale's coordination server, NetBird's management/signal/relay stack, a self-hosted DERP node, or a WireGuard exit/subnet-router all want a small, always-on, low-latency box with a stable public IP. That's a natural fit for a VPS on our cloud — enough for a control plane and a relay, on the same ASN 55285 network with always-on DDoS mitigation in front of the public listener. If you're routing into heavier infrastructure or running exit nodes at line rate, a dedicated server gives you the uncontended bandwidth and kernel-level control WireGuard rewards.

Already building with WireGuard directly? Our guides on a site-to-site VPN with WireGuard on VyOS and a flexible router and VPN backbone on VyOS cover the raw-protocol end of this spectrum, and our Linux distribution guide covers the OS to run underneath any of it.