If you've ever had to explain to a colleague why their VPN is slow, why they got disconnected when they switched networks, or why accessing a server in a different office requires a specific config file — you already know the problem NetBird solves.

Traditional VPNs are centralized by design. All traffic funnels through a gateway. That gateway is a single point of failure, a performance bottleneck, and the thing that breaks at the worst possible time. NetBird throws out that model entirely.

What NetBird is

NetBird is an open-source Zero Trust Network Access platform built on WireGuard. It creates a mesh network where every device connects directly to every other authorized device over encrypted WireGuard tunnels — no central gateway, no single point of failure, no port forwarding, no complex firewall rules.

It was launched on GitHub in 2021 by a Berlin-based team, and in January 2026 closed a $10 million Series A round led by Pace Capital with participation from Nauta Capital, InReach Ventures, and Antler. The platform is now used by companies ranging from small teams to large enterprises, including managed service providers and public sector organizations.

The license is BSD-3-Clause for the core components — genuinely open source, not BSL or dual-license with commercial restrictions on self-hosting.

How it works

Every machine in the network runs a NetBird agent. The agent manages the WireGuard interface and connects to NetBird's management service, which holds the network state and distributes updates to all peers. When two peers need to connect, they use WebRTC ICE (the same NAT traversal technology used in video calls) to establish a direct peer-to-peer connection — even through NATs, without opening any ports.

If a direct P2P connection isn't possible due to strict NAT (common with mobile carrier networks), traffic routes through a relay server. But in most cases, connections are direct and stay direct.

The result: your devices form a private overlay network with IPs in the 100.x.x.x range. Any device can reach any other authorized device on that network regardless of where either device is — office, home, cloud, edge, mobile.

Zero Trust, not just VPN

The traditional VPN model is binary: you're either on the network or you're not. Once you're in, you can typically reach everything. NetBird takes a different approach — access policies are defined per resource, per group, per user, and enforced continuously.

What this means practically:

  • Access control groups — define which peers can talk to which other peers. Your developers can reach the dev database, your ops team can reach the production servers, and those two groups don't overlap unless you explicitly allow it.
  • Dynamic posture checks — enforce device security rules before granting access: firewall status, antivirus presence, OS version, geographic location, network type. Integrate with MDM and EDR solutions to limit access to managed devices.
  • SSO + MFA — integrates with Okta, Microsoft Entra, Google, JumpCloud and any OIDC provider. No certificates, no .ovpn files to distribute, no PKI to manage. Users sign in through their existing identity provider.
  • Periodic re-authentication — peers registered with SSO can be required to re-authenticate periodically, reducing the risk of long-lived access tokens.

DNS-based resources and access rules

One of the more underappreciated NetBird features is how it handles DNS-based resource access. Instead of managing access purely by IP, you can define resources by hostname or DNS pattern and attach access policies directly to those resources.

What this enables in practice: you define a resource like *.internal.company.com or postgres.prod.internal, assign it to a group, and control which peer groups can resolve and reach it. The DNS resolution itself is handled by NetBird's private DNS zones — peers see the private hostname, not the underlying IP, which makes network changes transparent to applications and users.

For access rules, this is a meaningful shift from IP-based ACLs. Instead of writing rules like "group DevOps can reach 10.0.1.15 on port 5432", you write "group DevOps can reach postgres.prod.internal". When you migrate the database to a new server, you update the DNS record — the access policy stays the same.

Combined with posture checks, this gets powerful quickly: you can define a rule that only allows access to prod.internal resources from devices that pass posture checks — firewall enabled, OS up to date, and located in an approved country. The country check in posture rules is particularly useful for compliance requirements where you need to enforce that production access only happens from specific geographies.

Posture checks in depth

NetBird's posture checks go beyond simple device inventory. The checks that are most useful in production:

  • Country/location check — restrict access based on the peer's geographic location. Useful for compliance requirements (e.g. production access only from EU countries) or for limiting blast radius if credentials are compromised in a high-risk geography.
  • OS version check — ensure peers are running a minimum OS version before allowing access. Prevents access from unpatched systems.
  • Firewall check — verify the local firewall is active on the connecting device.
  • NetBird version check — ensure peers are running a minimum agent version, useful when you've deployed a security fix and want to enforce adoption before granting access.
  • MDM/EDR integration — on Team/Business plans, integrate with device management platforms to restrict access to managed, enrolled devices only.

Posture checks are evaluated continuously, not just at connection time. If a peer's OS falls out of compliance or a firewall gets disabled, access is revoked without requiring manual intervention.

Network routes and gateway peers for HA

Not every resource you need to reach will have a NetBird agent installed. Legacy servers, network appliances, IoT devices, on-premises subnets — these can't run an agent but still need to be accessible to your network. This is where routing peers come in.

A routing peer is a NetBird-enabled machine that acts as a gateway into a subnet. You designate a peer as a routing peer for a specific CIDR range (e.g. 192.168.1.0/24 for your office LAN), and NetBird peers that are authorized to reach that range will route traffic through it automatically. No manual WireGuard config, no firewall rules — just define the route in the NetBird UI and the agents update themselves.

For high availability, NetBird supports multiple routing peers for the same subnet. If the primary routing peer goes down, traffic fails over to a secondary peer automatically. This is a significant operational improvement over traditional site-to-site VPN setups where a downed gateway means complete loss of access until someone manually intervenes.

A practical HA setup looks like this:

  • Two Linux VMs in your office or data center, both running NetBird agent, both designated as routing peers for the internal subnet
  • NetBird automatically distributes traffic across both and fails over if one becomes unavailable
  • The failover is transparent to connected peers — no reconnection required, no manual config changes

Combined with DNS-based resources, this means you can build a resilient access layer where neither the routing infrastructure nor the resource addressing is a single point of failure.

Built-in reverse proxy

NetBird v0.65, released in February 2026, added something that changes the self-hosting equation significantly: a built-in reverse proxy directly in the management server.

The idea is simple but powerful. You point a custom domain at your NetBird server, configure the proxy in the dashboard, and your internal services become securely accessible from any browser — no VPN client required on the end user's side, no port forwarding, no manual TLS certificate management.

NetBird handles TLS termination automatically with Let's Encrypt certificates. Traffic arrives at the NetBird proxy, gets forwarded through an encrypted WireGuard tunnel to the target service inside your network. The target service needs no public IP and no open ports — it just needs to be reachable within the NetBird mesh.

Access control on the proxy is independent of the underlying service's own auth:

  • SSO — authenticate via the same IdP connected to NetBird, full OIDC flow
  • Password — simple password for services or users outside your IdP
  • PIN code — lightweight protection for internal services
  • No auth — for public-facing services or testing

NetBird v0.67 extended this with Layer 4 support — not just HTTP/HTTPS but raw TCP and UDP traffic. This means you can expose non-HTTP services like databases, game servers, VoIP endpoints, and legacy applications through the reverse proxy without wrapping them in HTTP.

There's also a netbird share command introduced in v0.66 — one command gives your local service a secure, public URL through the reverse proxy. Ephemeral by default: the URL lives while the command runs and cleans itself up on exit. No dashboard clicks, no YAML files, no orphaned configurations. Think ngrok but integrated into your Zero Trust network.

For self-hosted deployments, the reverse proxy requires Traefik as the external reverse proxy in front of the NetBird management server — Traefik is the only supported option because it supports TLS passthrough, which is required for the feature to work correctly.

Key features

  • WireGuard mesh — direct P2P encrypted tunnels between all authorized peers
  • Zero-config deployment — install the agent, authenticate, and the device is on the network
  • SSO + MFA + SCIM provisioning — full IdP integration including user lifecycle management
  • DNS-based resources — define access by hostname, not IP, with private DNS zones
  • Access rules per resource — granular policies attached to DNS resources, not just IP ranges
  • Dynamic posture checks — country, OS version, firewall, NetBird version, MDM/EDR
  • Routing peers with HA — multiple gateways per subnet, automatic failover
  • Built-in reverse proxy — expose internal services publicly with SSO, auto-TLS, L4/L7 support
  • netbird share — ephemeral public URLs for local services, no config required
  • Network segmentation — group-based access control, not flat network access
  • Browser-based RDP/SSH — access remote desktops and terminals through a browser
  • Activity logging — audit trail of network events and configuration changes
  • API + Terraform provider — full API access and official Terraform provider
  • Self-hostable — run the full stack on your own infrastructure

Self-hosting NetBird

Self-hosting requires a Linux VM with at least 1 CPU and 2GB RAM, publicly accessible on TCP 80, TCP 443, and UDP 3478. The setup is a single command:

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

This sets up the management service, signal service, and relay via Docker Compose. After that, you manage everything through the web UI or API. Adding a new machine to the network is installing the agent and authenticating — that's it.

For teams already running Docker and comfortable with a VPS, the operational overhead is minimal. NetBird is designed to run and then largely be forgotten about — it doesn't need constant tuning.

Pricing

NetBird Cloud has a free tier: up to 5 users and 100 machines at $0. For most homelabs and small teams, this is enough to evaluate and even run in production. The Team plan adds unlimited users and machines, SCIM provisioning, and priority support. Self-hosting is free beyond infrastructure costs — no seat limits, no feature gates on the open-source version.

NetBird vs Tailscale

Tailscale is the most direct comparison. Both are WireGuard-based mesh VPNs with SSO integration and a similar zero-config philosophy. The key differences:

  • Open source — NetBird's core is BSD-3, Tailscale's client is source-available but the coordination server (headscale aside) is closed. For self-hosting purists, NetBird is the cleaner option.
  • European sovereignty — NetBird is Berlin-based, important for teams subject to GDPR, NIS2, or DORA compliance requirements who want control plane infrastructure under European law.
  • Posture checks — NetBird's dynamic device posture checks including country-based restrictions are more granular than Tailscale's device authorization model.
  • Routing HA — NetBird's multi-peer routing with automatic failover is more mature than Tailscale's subnet router setup.
  • Reverse proxy — NetBird's built-in reverse proxy with SSO, auto-TLS, and L4 support has no direct equivalent in Tailscale.
  • Tailscale wins on polish — the client experience, documentation, and ecosystem (Tailscale Funnel, SSH, etc.) is more mature.

For teams that prioritize open source and European data sovereignty, NetBird. For teams that prioritize the best possible out-of-box experience and don't have sovereignty constraints, Tailscale.

NetBird vs traditional VPN (OpenVPN, WireGuard standalone)

Traditional VPN setups require a central server, certificate management, client configuration distribution, and ongoing firewall maintenance. Every remote employee needs an .ovpn or WireGuard config file. Adding a new server means updating firewall rules and potentially reconfiguring clients.

NetBird eliminates all of that. No certificates, no config files, no firewall rules per connection. The trade-off is a dependency on NetBird's management infrastructure — either their cloud or your self-hosted instance. For teams already running their own infrastructure, that dependency is easy to own.

My take

NetBird is the most practical answer to "how do I securely connect distributed infrastructure without a traditional VPN" in 2026. The WireGuard foundation means performance is excellent, the Zero Trust model is actually implemented rather than just marketed, and features like DNS-based resources, country-level posture checks, HA routing peers, and the built-in reverse proxy put it ahead of most alternatives for production DevOps use cases.

The $10M Series A in January 2026 gives the project runway and signals that the commercial side is working — important for anyone evaluating whether to build production infrastructure on an open-source tool. NetBird isn't going anywhere.

For DevOps teams managing distributed infrastructure across cloud, on-premises, and remote workers — NetBird is worth a serious look.

Need help setting up NetBird?

Getting NetBird into production — self-hosted management service, routing peers with HA, SSO integration, DNS resources, posture policies, reverse proxy — is straightforward if you know what you're doing. If you'd rather skip the trial and error, Pipoline can handle the full setup. Get in touch and we'll figure out what makes sense for your infrastructure.