Why I am moving from Tailscale to NetBird

I like Tailscale. I have used it for years, it is ridiculously easy to get running, and this article would be nonsense if I pretended otherwise. But Tailscale has one problem I can no longer wave away: it is a US-based service sitting in the control path of infrastructure I may have to defend in a German NIS2 or KRITIS audit.

Yes, the payload traffic is end-to-end encrypted. No, Tailscale cannot casually read traffic between my peers. That is not the whole audit question. Its multi-tenant control plane distributes public keys and network policy, and stores device, user, routing and connection metadata. Tailscale’s own security page says that control plane runs in AWS and stores backups in S3, with analytics in Snowflake. So the supplier, jurisdiction, subprocessors, outage model and exit strategy all end up in my risk assessment.

None of this makes Tailscale insecure, and NIS2 does not contain a line saying “thou shalt not buy American software.” It does require risk management, supply-chain security, resilience and accountability. In a normal startup, the Tailscale answers may be perfectly acceptable. Around grid infrastructure, energy storage, water, transport or another KRITIS environment, those answers create work—and ultimately the operator remains responsible.

That is why NetBird got my attention. NetBird GmbH is registered in Berlin. More importantly, every component required to run the network is open source and self-hostable: the client, management service, dashboard, signalling server and relay. The current code is BSD-3-Clause licensed. I can use NetBird Cloud if I want convenience, or run the official NetBird control plane myself without replacing it with somebody else’s approximation.

That distinction is the whole article, really. With NetBird I can keep the control-plane database, peer metadata, policy, audit log, signalling and relayed traffic on infrastructure under my control, in Germany, with my own identity provider. I do not have to write a magnificent transfer-impact assessment to explain why a foreign SaaS dependency absolutely must sit between operators and a battery site. I can remove the dependency.

Then I found the reverse proxy, Networks, posture checks and DNS routing, and realised NetBird was not merely the sovereignty choice. It is a serious product in its own right.

What NetBird actually is

NetBird creates a private overlay network between machines it calls peers. Each peer gets an IP from the carrier-grade NAT range 100.64.0.0/10, a private DNS name and a WireGuard identity. The client generates its WireGuard keys locally; the private key does not leave the device.

The control plane tells authorized peers about one another, distributes public keys and policies, and helps them negotiate a connection. Once two peers find a usable path, their data travels directly through an encrypted WireGuard tunnel. The management server coordinates the network, but it is not normally in the data path.

There are four conceptual pieces:

The client runs on each peer, applies DNS and firewall policy, and creates WireGuard tunnels.
The management service stores accounts, peers, public keys, groups, policies and network state.
The signal service helps peers exchange encrypted connection candidates; application traffic does not pass through it.
The relay is the fallback when NAT traversal cannot establish a direct connection. Relayed WireGuard traffic remains end-to-end encrypted, so the relay forwards packets but cannot decrypt them.

NetBird’s current relay can race QUIC over UDP against WebSocket over TCP. That matters in hotels, corporate networks and mobile networks where UDP is filtered: the WebSocket path looks like ordinary HTTPS traffic and is more likely to get through. The tradeoff is the same as with any mesh VPN: direct paths are fastest, while relaying adds latency and makes relay bandwidth part of your capacity planning. The architecture is documented clearly in How NetBird Works and Understanding NAT and Connectivity.

Not “open-core enough”: the whole control plane is there

This is where NetBird wins me over. Plenty of infrastructure products put the agent on GitHub and call themselves open source while the useful server remains a black box. NetBird publishes the bits that actually run the network. Management, signalling, relay, dashboard and client can all run on my machines. There is no mandatory phone-home path hiding behind the nice diagram.

New installations use a combined netbird-server container for management, signal and relay, instead of the older collection of separate containers. NetBird’s quick-start script can generate a configuration around your domain and reverse proxy; advanced installations can use a generic OpenID Connect provider such as Keycloak, Authentik, Zitadel or another compatible IdP. The built-in identity provider is enough to get started, so an external identity stack is no longer mandatory. See the self-hosting guide and identity-provider documentation.

Self-hosting lets me choose where account data, peer metadata, policies, audit events, signalling and relayed traffic live. More importantly, the servers deciding which public keys and policies reach my peers are mine too. “We operate it in this German data centre” is a gloriously short answer in an audit. Short answers are underrated.

Of course, sovereignty comes with a pager. You become responsible for upgrades, backups, certificates, monitoring, database integrity, identity-provider availability and enough relay capacity for the worst network your users encounter. If the control plane is unavailable, existing tunnels may continue for a while, but enrollment and network changes are affected. A self-hosted security service that nobody patches is not more sovereign; it is merely your own vulnerability.

Tailscale users are not completely stuck. Its clients can connect to a custom control-server URL and the open-source community project Headscale implements that server. Tailscale even documents how to configure its clients for Headscale. I like Headscale, but it is still a reimplementation. It does not mirror every SaaS feature and it is not the control server Tailscale sells or supports. In a homelab that may be irrelevant. In a KRITIS supplier review, “we use the vendor client with an unofficial server that aims for compatibility” is not the clean escape hatch people sometimes present it as. NetBird’s self-hosted server is NetBird.

Getting machines into the network

Human-operated devices can join through an identity provider. Servers, containers and automated workloads can use setup keys, NetBird’s equivalent of a pre-authentication token. Keys can be one-off or reusable, expire after a chosen period, have a usage limit and automatically place new peers into groups.

That last detail is more important than it looks. A provisioning job can add every production server to prod-servers, every CI runner to ci-runners and every site gateway to routing-peers without an administrator cleaning up the dashboard afterward. Ephemeral peers enrolled with the appropriate key are automatically removed after remaining offline, which suits CI jobs and autoscaling workloads. The setup-key documentation also covers Terraform, Ansible and unattended installation patterns.

Access control without policy-file archaeology

A new NetBird account starts with a permissive default policy, which is convenient for proving that the mesh works. Production networks should remove or narrow it. Policies connect a source group to a destination group or resource and can restrict protocol, ports and direction.

For example:

operators may reach site-gateways on HTTPS and SSH;
grafana may reach prometheus on TCP 9090, but not the rest of the monitoring subnet;
developers may reach staging, while only on-call may reach production;
contractors may reach one published application without receiving broad network access.

NetBird pushes the relevant network map and firewall rules to clients. This is more than a central firewall sitting between every packet: policy enforcement happens at the edge, and peers only receive the peer information permitted by their relationships. Groups can contain users, machines and network resources, so the same model scales from a homelab to multiple sites.

Posture checks add device context to a policy. NetBird can evaluate client version, OS or kernel version, country or region, local/public network ranges and running processes. That enables rules such as “allow production only from a current managed client outside risky regions” or “use the remote route only when the laptop is not already in the office.” There are platform caveats—mobile operating systems cannot expose every signal desktop agents can—but the primitives are useful and documented in NetBird’s posture-check overview.

The dashboard also has a Control Center graph for understanding connections between peers, groups and resources. That visual feedback is welcome once a policy set stops fitting in your head.

Networks for the boxes that cannot run an agent

Installing an agent on every laptop and server is ideal, but industrial controllers, printers, network appliances, old virtual machines and managed cloud services often cannot run one. NetBird’s Networks feature handles these through routing peers.

A routing peer sits inside the destination LAN, VPC or data centre and forwards authorized mesh traffic to declared resources. A resource can be:

a single IP address;
an IP range or subnet;
a domain name, including supported wildcard patterns.

Multiple routing peers can front the same network for high availability. By default, masquerading makes deployment easy because the destination sees the router’s local address and needs no return route. Disable masquerading when preserving the original NetBird source IP is worth adding a return route to the LAN. This is a real operational tradeoff: NAT is easier, original source addresses are better for downstream audit trails.

NetBird’s older Network Routes model still appears in documentation because exit nodes currently use it, but it is deprecated for ordinary subnet and domain routing. New configurations should use Networks, where resources and access control are tied together and denied until a policy grants access. The distinction and its security implications are explained in How Routing Peers Work.

This is exactly what I want in OT. Put a small, maintained Linux gateway beside a BMS, historian or PLC network; do not attempt to install VPN software on the controller. Operators reach only the declared management interfaces and ports, and the rest of the site remains invisible.

DNS, because it is always DNS

Every peer gets a stable private name, so daily use does not require memorizing 100.x.y.z addresses. NetBird’s local resolver can also distribute nameserver configuration to selected groups and provide split DNS for internal zones. Peers with DNS conflicts can opt out of managed DNS without leaving the mesh.

Domain resources are especially useful when a service’s addresses change or are only resolvable from inside a site. The routing peer can resolve the name using the site’s DNS and forward the result to the client path. This makes erp.corp.internal a policy target rather than forcing administrators to maintain a brittle list of IP addresses. DNS routing is not application proxying—the client still connects at the network layer—but it gives policies a much more useful vocabulary.

There are edge cases here. Split DNS, another VPN client, systemd-resolved, browser DNS-over-HTTPS and overlapping private zones can all disagree about who owns resolution. NetBird provides a per-peer --disable-dns escape hatch, and its DNS troubleshooting guide is worth bookmarking before rolling it across a fleet.

Exit nodes and the missing Mullvad button

An exit node routes a peer’s general internet traffic through another NetBird machine. Run one on a VPS to use its public address while travelling, in an office to make SaaS traffic originate from a known IP, or at home to reach the internet as if you were there. Access to the exit node can be limited to groups with policy.

This also provides the workaround for using NetBird with Mullvad: run a NetBird exit node that itself uses Mullvad for upstream internet traffic. In other words:

laptop -> encrypted NetBird tunnel -> your exit node -> Mullvad tunnel -> internet

It works, but you own the glue. You must configure forwarding, NAT, DNS and kill-switch behavior on the exit node, and you must ensure a Mullvad reconnect does not silently send traffic out through the server’s normal interface. It also adds another hop and another machine to maintain.

Tailscale’s native Mullvad exit-node add-on is much nicer for this exact use case: eligible Mullvad locations appear as exit nodes directly in Tailscale and billing is integrated. It is paid and still has documented limitations, but there is no equivalent first-class integration in NetBird today. If consumer VPN egress is a primary requirement, this is a clear Tailscale win.

The feature that sold me: reverse proxy

NetBird Reverse Proxy publishes an internal service to the public internet without opening an inbound port on the target network. Traffic reaches a proxy cluster, enters the NetBird mesh and travels to a peer or a resource behind a routing peer.

For HTTP services it can terminate TLS, forward to one or more targets, route by path, rewrite redirects and protect access with SSO, password or PIN authentication. Restrictions can include IP ranges, country and CrowdSec reputation. Layer 4 modes cover TCP, UDP and TLS; TLS passthrough uses SNI routing so the backend can retain end-to-end TLS termination.

The dashboard provisions a domain and certificate, while custom domains can be attached through DNS. This is the workflow I wanted for Grafana and management interfaces: define the internal target, choose authentication, point a domain at it and stop maintaining an unrelated tunnel daemon plus Caddy or Nginx configuration on every site.

Crucially, this is not only for NetBird Cloud. A self-hosted deployment can run its own proxy cluster, and cloud accounts can use Bring Your Own Proxy when traffic must terminate in a specific region or on infrastructure they control. For self-hosted installations, Traefik is currently required as the external proxy because NetBird depends on TLS passthrough behavior. Read the Reverse Proxy documentation and Bring Your Own Proxy guide before treating it as a production ingress tier.

There is one large asterisk: Reverse Proxy is currently beta. That means I would happily use it for a lab, dashboards and carefully monitored internal tools, but I would not quietly replace a battle-tested ingress platform for a revenue-critical public API without load tests, failure drills and an exit plan. NetBird also notes that Reverse Proxy does not currently support Rosenpass.

Tailscale is not empty-handed here. Serve can expose a local service inside a tailnet, and Funnel can expose it publicly with HTTPS. Tailscale also supports HTTPS certificates for tailnet names. NetBird’s appeal is the centralized, service-oriented proxy layer: HTTP and L4 services, multiple targets, authentication choices, restrictions, custom domains and self-hosted proxy clusters live in one management model. Whether that matters depends on whether you want simple per-node publishing or something closer to a small managed ingress layer.

SSH: useful, but not a NetBird exclusive

Tailscale has built-in SSH too, and it would be unfair to list this as a NetBird advantage without saying so. Tailscale SSH is mature: it authorizes connections through tailnet policy, maps identities to existing local users, can demand periodic IdP reauthentication with check mode, and supports session recording. It is one of Tailscale’s better features.

NetBird approaches the same problem with an embedded SSH server and two authentication modes:

JWT authentication is the default. Every new session authenticates the person through the configured OIDC identity provider and mints a JWT, unless JWT caching is enabled for a chosen period. Policies can then map specific NetBird users or groups to specific local operating-system accounts.
Machine identity is enabled with --disable-ssh-auth. Despite the flag’s slightly alarming name, the session is not open to the world: NetBird’s network ACLs still decide which peer may reach which SSH server. What disappears is the additional per-user OIDC/JWT check.

Current releases also support native OpenSSH clients, SFTP, command execution, local and remote port forwarding, and Windows peers. That is a useful bundle, especially if I want the identity and policy stack to remain on my self-hosted control plane.

One detail is easy to misunderstand: current NetBird SSH does not ask for the target account’s actual password by default. It authenticates the person through the configured identity provider and then authorizes access to an existing OS user. Tailscale does something similar: the tailnet identity is the proof, so its SSH server does not require the account’s normal password or SSH key either.

If I want two separate gates—first permission to reach the host over the mesh, then the host’s own SSH password or key—I can simply run ordinary OpenSSH over NetBird or Tailscale instead of enabling their embedded SSH server. Honestly, that can be the more conservative choice in a KRITIS environment. The mesh removes public port 22; sshd keeps the familiar host-level authentication and PAM controls.

So this round is not “NetBird has SSH and Tailscale does not.” Both do. NetBird’s win for me is that its SSH identity, policy and coordination path can be fully self-hosted. Its SSH documentation is also worth reading carefully because recent releases introduced version requirements and breaking changes.

Can I see what it is doing?

The management dashboard records changes to peers, users, groups, setup keys, policies and settings. Audit events can be searched in the UI and streamed to SIEM systems. NetBird also documents Prometheus metrics for its self-hosted components, including relay connections, authentication time, reconnects and transferred bytes. That is the difference between “the VPN feels slow” and being able to see that a relay is saturated or every direct connection has fallen back to TCP.

For configuration as code, NetBird provides an API, CLI and Terraform provider. Kubernetes users get an operator, and setup keys make containers and ephemeral workloads straightforward to enroll. This is enough to automate real deployments without inventing a dashboard-clicking ritual.

Where NetBird still annoys me

NetBird is not ahead everywhere. Tailscale has had years to sand off rough edges and collect support for every strange box somebody found behind a television.

1. The app and hardware ecosystem is smaller

NetBird officially covers Linux, Windows, macOS, iOS and Android, and now documents tvOS, Synology, TrueNAS, pfSense and OPNsense. That is already enough for many business fleets.

Tailscale goes wider and often deeper. It has polished paths for Android TV, Apple TV, Amazon Fire TV, Chromebook, Synology, QNAP, TrueNAS, Unraid and many router or appliance environments. Its NAS documentation distinguishes official packages from community support, and the app-store experience matters enormously when the target has no pleasant shell. Tailscale also benefits from years of community recipes for Home Assistant, Kubernetes, serverless environments, routers and tiny homelab boxes.

A subnet or routing peer can bridge unsupported devices in either product, but that is not equivalent to a native app. A native client lets the device move between networks, retain its own identity and participate directly in policy. Before migrating, check every device rather than assuming that “WireGuard-based” means an installer exists for it.

2. Tailscale’s client experience is more mature

Tailscale remains exceptionally good at the first five minutes. Login, peer discovery, DNS and exit node selection feel coherent across platforms. NetBird’s desktop and mobile clients work, but the experience can be less uniform and newer capabilities often land first in the CLI or require careful version matching.

Mobile fleet management shows the gap: NetBird documents native MDM policy support for Windows and macOS, while iOS and Android MDM support is still on its roadmap. For a company issuing hundreds of phones, “the app exists” and “security settings can be enforced at fleet scale” are very different claims.

3. No native Mullvad service

The self-managed exit-node workaround is technically sound, but it is not the same experience as choosing a Mullvad location in the client. Tailscale wins this round without qualification.

4. Some exciting NetBird features are young

Reverse Proxy is beta. Networks replaced the older Routes workflow for most use cases, but exit nodes still depend on the old model. NetBird SSH recently underwent substantial rewrites with explicit upgrade constraints. Rapid development is exciting, but it also means reading release notes and testing mixed client versions before upgrading the control plane.

5. Self-hosting moves work onto your side of the table

Running the official server is a feature, not proof that everyone should use it. Tailscale’s hosted control plane and global relay network remove a category of operations work. NetBird Cloud offers the same basic convenience. Choose self-hosting because you have a concrete sovereignty, compliance, connectivity or customization requirement—not because Docker Compose made the first ten minutes look free.

The German company is not a footnote

This point is often softened until it means nothing, so I will say it plainly: for German critical infrastructure, buying the network control layer from a German company is an advantage.

Tailscale is a US company running a multi-tenant control plane. Even if it never sees decrypted payload traffic, it remains a foreign supplier handling sensitive network metadata and coordinating access. That brings contracts, subprocessors, international data-transfer questions, the US legal environment, supplier failure and geopolitical dependency into the threat model. Perhaps your assessment accepts all of that. Fine. You still have to perform, document and periodically revisit the assessment.

NIS2 explicitly puts risk management, resilience and supply-chain security on the operator’s desk; those are part of the risk-management measures in Article 21. German KRITIS supervision adds serious evidence and audit expectations. “The packets are encrypted” does not answer who runs the coordinator, where its metadata sits, what happens when the service or commercial relationship disappears, and how the operator takes control during a crisis.

NetBird gives me three much better answers:

German vendor: NetBird GmbH is registered in Berlin. Procurement, contracts and escalation sit in a German and European legal context.
Inspectable software: the client and all required server infrastructure are open source under BSD-3-Clause. My security team can inspect it, pin versions and build it without waiting for a SaaS roadmap.
Operational independence: management, policy, identity, signalling, relay and proxy can run in my environment. If I self-host, the vendor is no longer a live technical dependency for operating my network.

That last point is the killer feature. A German company alone would not be enough; a German SaaS can still become a dependency. Open source alone would not be enough; an open client with a proprietary coordinator leaves the important trust boundary elsewhere. NetBird combines both and lets me bring the entire thing home.

No product makes an organisation NIS2-, KRITIS-, GDPR- or DORA-compliant by installation. NetBird’s ISO 27001 certification does not transfer to my deployment either. But it lets me design a much cleaner system boundary, reduce the supplier surface and produce evidence from infrastructure I operate. That is not compliance theatre. It is less risk to explain and fewer external assumptions to defend.

How I would roll it out

For a company connecting offices, cloud workloads and energy sites, I would start small:

Run NetBird Cloud for a proof of concept, or deploy the self-hosted quick start behind a dedicated domain if control-plane ownership is itself the requirement.
Connect two ordinary peers and inspect whether they establish a direct path or use a relay.
Remove the permissive default policy and create groups around roles and resources, not locations.
Add one routing peer at a non-critical site and expose a single resource and port through a Network.
Add a second routing peer before calling the path highly available.
Configure private DNS only for a test group; VPN and DNS conflicts are easier to debug before a fleet-wide rollout.
Publish a disposable dashboard through Reverse Proxy, test SSO, certificate renewal and failure behavior, and remember that the feature is beta.
Export audit events and scrape component metrics before onboarding production access.
Document control-plane backup and upgrade procedures, including client/server version constraints.

For an OT site, the routing peer should live in a management segment, not directly beside safety-critical controllers with unrestricted reach. NetBird can enforce narrow overlay policy, but it does not replace network segmentation, asset inventory, local firewalling or a safety review.

Am I replacing Tailscale?

For infrastructure I may need to defend under NIS2 or KRITIS: yes. The control plane is too central to leave its ownership as a vague future problem. NetBird lets me run the official stack in Germany and keep the policy, metadata, signalling, relay path and ingress under my control. That settles it.

I am not deleting Tailscale from every personal device tomorrow. It still has the nicer app ecosystem, better odd-hardware support and native Mullvad exit nodes. If I wanted a VPN for the family television, Tailscale would probably win before the coffee was ready.

But NetBird is no longer merely the principled self-hosted alternative that I tolerate because I care about sovereignty. Networks, posture checks, DNS routing, SSH and the reverse proxy are good features. The rough edges are real, yet none of them outweigh owning the infrastructure that decides who can reach a critical site.

Tailscale made mesh VPNs pleasantly boring. NetBird makes the control plane mine. In a homelab that is a preference. In critical infrastructure it can be the deciding requirement.