NetBird vs Tailscale: which mesh VPN to run

NetBird vs Tailscale: the short answer

NetBird vs Tailscale is a choice about the control plane, because both mesh VPNs move your packets with WireGuard. Tailscale runs its coordination server for you, and that server is closed source. NetBird sells the same kind of hosted service. It also publishes its management server under an open licence, so you can run the whole system on one VPS. Pick Tailscale if nobody on your side should operate a server. Pick NetBird if the control plane itself must run on hardware you control.

If you are still comparing more than two tools, start with the wider list of Tailscale alternatives. The sections below compare these two tools directly, on the four points where they really differ.

What is the same: WireGuard underneath

A mesh VPN (virtual private network) connects every device directly to every other device. Traffic does not pass through one central gateway. Both tools give every device a WireGuard key pair. The private key is created on the device and never leaves it. Both then try to build a direct tunnel between two peers. They use a relay only when a direct path fails.

This means the encryption on the wire is the same protocol in both products. A relay in either system forwards WireGuard packets that it cannot decrypt, because it never holds a private key. For the baseline with no control plane at all, read what Tailscale adds on top of plain WireGuard.

One difference does sit in the data path. Tailscale runs WireGuard in userspace through wireguard-go. The NetBird README lists kernel WireGuard on Linux. Do not choose on that alone. Run iperf3 across the tunnel on your own VPS. The limit usually comes first from the CPU, the bandwidth allowance or the network path between peers.

Who runs the control plane?

The control plane is the server that knows the public key and tunnel address of every device. It tells each device which peers exist and which of them it may reach. It does not carry your traffic.

Tailscale. The coordination server is closed source. It runs only as Tailscale's hosted service. The clients are open source: the core daemon on every platform, plus the full Linux and Android clients. The graphical apps for Windows and macOS are closed. The code for DERP, Tailscale's relay server, is open. If you need a Tailscale-compatible control plane on your own box, the option is Headscale. Tailscale describes it as an independent, community-maintained project that it does not direct. The setup is covered in running Headscale as a self-hosted Tailscale control server.

NetBird. There is a hosted cloud at app.netbird.io, and the same code is on GitHub for you to run. As of October 2026 the repository README states the licences plainly. The client and most of the repository are BSD-3-Clause. The management/, signal/ and relay/ directories are AGPLv3 (GNU Affero General Public License, version 3). The AGPL adds one condition. If you modify those servers and let other people use them over a network, you must offer those people your modified source.

The NetBird server side has three parts. The management service holds the network state: peer keys, IP address allocation, access control and DNS settings. The signal service helps two peers exchange connection candidates. Those messages are encrypted between the peers, so signal cannot read them. The relay service carries traffic when no direct path exists.

How do you write access rules in each?

Both products start a new network with an allow-all rule. Every device can reach every other device until you change it. Replace that rule before you add a server that holds anything you care about.

Tailscale: one policy file

Tailscale keeps all access rules in the tailnet policy file. It is HuJSON (human JSON), which is JSON that also allows comments and trailing commas. You edit it in the admin console or push it through the API. Current rules are written as grants. This file lets one group reach tagged production servers on SSH and HTTPS only. It also includes a test:

{
  "groups": {
    "group:engineering": ["alice@example.com", "bob@example.com"]
  },
  "tagOwners": {
    "tag:production": ["group:engineering"]
  },
  "grants": [
    {
      "src": ["group:engineering"],
      "dst": ["tag:production"],
      "ip": ["tcp:22", "tcp:443"]
    }
  ],
  "tests": [
    {
      "src": "alice@example.com",
      "accept": ["tag:production:22"]
    }
  ]
}

The tests section matters. Its assertions run as checks every time the policy file changes, so a bad edit is caught before it applies. The default policy on a new tailnet is a single acls entry with "src": ["*"] and "dst": ["*:*"]. Leaving out the acls field entirely also means allow all. Delete that entry once your grants are in place. As of October 2026, the free Personal plan gives you 3 ACL groups.

NetBird: groups and policies in the dashboard

NetBird builds access control from groups and policies. A group is a set of peers. You can add peers to a group by hand, through the groups attached to a setup key, or from the user groups in your identity provider. A policy names a source group and a destination group. It can be one-way or bidirectional. It can also limit the protocol and the ports, with ranges written as 8000-9000. A policy can also carry posture checks. A posture check is a condition a peer must meet before the connection is allowed.

You build all of this in the dashboard. A new account ships with a policy named Default that lets all peers talk to each other. Add your own policies first, then disable Default. If you want rules as text, NetBird has a public REST API. It also has an official Terraform provider (netbirdio/netbird) that works with both NetBird Cloud and a self-hosted management server. The NetBird access-control documentation describes no built-in test assertions like Tailscale's tests section. With Terraform, you review the plan output instead.

How is traffic relayed when no direct path exists?

Both tools first try a direct connection. They use STUN (session traversal utilities for NAT) to learn the public address of each peer. Then they try to open a path through NAT (network address translation) on both sides. Strict firewalls and some mobile networks block this, so both tools need a fallback.

Tailscale falls back to DERP (designated encrypted relay for packets) servers. Tailscale runs them in many regions, and they carry traffic over HTTPS. They cost you nothing extra. Tailscale also has peer relays. A peer relay is one of your own devices acting as a relay, and Tailscale tries it before DERP. Tailscale's documentation presents peer relays as the option when you need lower latency and higher throughput than DERP gives. Peer relays became generally available on 18 February 2026, on all plans including the free one. You turn one on with a UDP port of your choice, and allow it with a grant in the policy file:

sudo tailscale set --relay-server-port=40000

To see which path a connection uses, run tailscale ping against a peer. A reply that says via DERP(fra) is relayed. A reply that names an IP address and port is direct. If a connection stays relayed, why a relayed Tailscale link is slow and how to get a direct one goes through the causes.

NetBird relayed traffic through the coturn TURN server in older releases. Version 0.29.0 introduced NetBird Relay, which has since replaced coturn for relayed connections. The relay accepts WebSocket connections on the /relay path, or QUIC on UDP port 33080. Current guidance also moves STUN into the relay service. On NetBird Cloud, NetBird runs the relays. On a self-hosted server, you run the relay. Every relayed byte counts against your VPS bandwidth, and every relayed path goes through the location of that VPS. Check the path for each peer with:

netbird status -d

Each peer shows a connection type of P2P (direct) or Relayed.

What does self-hosting NetBird on one VPS involve?

The official quickstart sets up the whole server side with one script. As of October 2026 it asks for a Linux machine with at least 1 CPU and 2 GB of memory. It also needs a public domain name that resolves to the VPS, plus Docker with the compose plugin, jq and curl. Open TCP 80, TCP 443 and UDP 3478 in the VPS firewall. Open them in your provider's network firewall too, which is a separate control on most panels.

export NETBIRD_DOMAIN=netbird.example.com; curl -fsSL https://github.com/netbirdio/netbird/releases/latest/download/getting-started.sh | bash

The script deploys four kinds of service:

• Traefik as the reverse proxy, with TLS (transport layer security) certificates from Let's Encrypt.
• An embedded Dex server as the identity provider, so you can create users in the dashboard with no external login system.
• The management, signal and relay services described above.
• Optional extras: the NetBird Proxy service and CrowdSec IP reputation filtering.

Each part is now yours to run. The identity provider decides who can log in and add devices. Dex is enough for a small team. You can connect an external single sign-on provider later, such as a self-hosted Authentik SSO server. TLS depends on order. Let's Encrypt validates the domain by connecting to this VPS, so create the DNS record and open the ports before you run the script. If the domain does not resolve to the VPS yet, validation fails and no certificate is issued. Backups and upgrades are yours too. The full install, with a check after each step, is in the guide to self-hosting a NetBird VPN server.

Enrolling a Linux server in each

Joining a mesh needs outbound network access to the control plane, so run these commands on your own machine. A server has no browser, so both tools use a key you create in advance instead of an interactive login.

Tailscale, with an auth key from the admin console:

curl -fsSL https://tailscale.com/install.sh | sh
sudo tailscale up --auth-key=YOUR_AUTH_KEY
tailscale status

tailscale status should list this machine with a 100.x.y.z address, plus the other devices in your tailnet. An auth key with no expiry set expires after 90 days, which is the maximum. A server that you already enrolled stays enrolled. A script that enrols new servers needs a fresh key.

NetBird, with a setup key from the dashboard:

curl -fsSL https://pkgs.netbird.io/install.sh | sh
netbird up --setup-key YOUR_SETUP_KEY
netbird status

For a self-hosted server, add --management-url https://netbird.example.com to the netbird up line. Without it, the client contacts NetBird Cloud, which does not know a setup key created on your own server. netbird status should report the management and signal services as connected.

Free plans and prices, as of October 2026

These figures come from the two pricing pages on 2 October 2026. They change, so check again before you commit.

Tailscale Personal is free for up to 6 users with unlimited user devices. It includes 50 tagged resources (servers that belong to a tag rather than a person) and 3 ACL groups. Paid plans are Standard at $8 per user per month and Premium at $18. Enterprise is priced on request. The breakdown of what a household or a small team actually pays for Tailscale covers the edge cases.

NetBird Cloud is free for up to 5 users and 100 machines. Team costs €6 per user per month and Business costs €12. Enterprise is priced on request. The paid plans include 100 machines plus 10 per user, and each extra machine costs €0.50 per month. Self-hosted NetBird has no licence fee. You pay for the VPS and for the time to run it.

Pick Tailscale if...

• Nobody on your team wants to run, patch or back up a control server.
• You want access rules as one text file, with tests that catch a bad change before it applies.
• Your users travel and connect from hotel and mobile networks. There, Tailscale's DERP servers in many regions give a nearby fallback with no setup.
• Your group fits the 6-user free plan, or the per-user price is acceptable.

Pick NetBird if...

• The control plane must run on infrastructure you own, using the official project rather than a separate reimplementation.
• You need more than 6 people on a self-hosted network without per-user fees.
• Your team prefers to manage groups and policies in a dashboard, or already uses Terraform for everything else.
• You want to start on NetBird Cloud and keep the option of moving to your own server, with the same client.

What each side lacks

Every item here comes from the vendor's own documentation or pricing page, as checked on 2 October 2026.

Tailscale lacks:

• An official self-hosted control server. The coordination server is closed source, and Headscale is a separate community project.
• Open source graphical clients on Windows and macOS. The daemon underneath is open, but the apps are not.

NetBird lacks:

• Built-in test assertions for access policies. Its access-control documentation describes none, so policy review depends on you or on Terraform plans.
• When you self-host, relays that someone else runs. Your relay sits on your VPS. A peer far from that VPS gets a long relayed path, and you pay for the bandwidth.

Both start with an allow-all policy, so a new network is fully open until you write rules. For the full threat model on the hosted side, see what a hosted control plane can and cannot see.

FAQ

Is NetBird fully open source?

Yes, but under two licences. As of October 2026 the NetBird README states that the client and most of the repository are BSD-3-Clause. The management/, signal/ and relay/ directories are AGPLv3. If you modify those server components and let other people use them over a network, the AGPL requires you to offer those people your modified source.

Can I self-host Tailscale's control server like NetBird's?

No. Tailscale's coordination server is closed source and runs only as its hosted service. The usual self-hosted replacement is Headscale, an independent open source coordination server that works with the official Tailscale clients. Tailscale employs the head maintainer of Headscale, but says it does not direct the project.

Can the relay read my traffic in NetBird or Tailscale?

No. In both products the WireGuard private key is created on the device and never leaves it. A Tailscale DERP server, a Tailscale peer relay and a NetBird relay all forward only encrypted WireGuard packets. The relay can still see which peers it connects and how much data passes between them.

What VPS do I need to self-host NetBird?

As of October 2026, the official quickstart asks for at least 1 CPU and 2 GB of memory. It also needs a public domain that resolves to the VPS, Docker with the compose plugin, and open ports TCP 80, TCP 443 and UDP 3478. Plan bandwidth for relayed traffic too. On a self-hosted server, every relayed connection passes through your VPS.

Which one has the bigger free plan?

As of October 2026, Tailscale Personal allows up to 6 users with unlimited user devices. The free NetBird Cloud plan allows up to 5 users and 100 machines. A self-hosted NetBird server has no user limit and no licence fee, but you pay for the VPS and you run it yourself.