How to Deploy NetBird on a Linux Server: A Complete Guide to a Modern VPN Alternative for Secure Private Networking

The classic corporate VPN is a simple model: one gateway, all traffic routed through it, every employee connected to the same point. For years this worked fine, but in 2026 the model is hitting its limits more and more often. Teams are spread across countries, infrastructure is split between several clouds, and the same database needs to be reachable from the office, a developer's home laptop, and a CI runner. Funnel all that through one gateway and it quickly becomes a bottleneck: slow when busy, dead when down, and dragging the rest of remote work along with it.

NetBird tackles the problem differently. Instead of routing everything through a central gateway, it builds a mesh network where devices connect directly to each other through encrypted WireGuard tunnels. The management server only handles authentication and key exchange. The actual traffic never touches it. The result: lower latency, fewer points of failure, and far easier scaling than a traditional VPN.

In this guide we will cover what NetBird is, how it differs from Tailscale and WireGuard, where it fits, and how to deploy your own self-hosted instance on a Linux server from scratch.

What NetBird is and why it matters

NetBird is an open-source platform for building private networks over the internet, positioned as a modern alternative to traditional VPN solutions. Under the hood it uses WireGuard, with several layers added on top that vanilla WireGuard does not ship with: automatic key distribution, NAT traversal, a web management dashboard, group and user-based access policies, and integration with corporate identity providers.

The core idea is that any employee or server can join a shared private network with a single command, no manual config editing or key swapping over email. From an admin's standpoint it feels closer to Slack for servers: add a user, assign permissions, done.

Who benefits the most:

• DevOps teams whose developers, staging environments, and production are spread across different clouds.
• Small and mid-sized businesses with remote workers who need secure access to internal services.
• Companies with strict data residency or compliance requirements (GDPR, HIPAA, SOC 2), since with self-hosting all traffic and metadata stay inside your own infrastructure.
• Studios and agencies linking several offices or sites into one network.

NetBird is licensed under Apache 2.0, so self-hosting is fully free with no caps on users or devices.

How NetBird works: the architecture in plain English

In any mesh network there are two independent stories: how the actual data flows, and how devices discover each other. WireGuard handles the first part: it encrypts packets and ferries them between two endpoints. Everything else is bolted on top, and that is exactly what NetBird provides, distinguishing it from classic VPN setups where management and data transport live on the same server.

The architecture has four components:

• Management Server. The main piece every client connects to. It stores the device list, hands out IP addresses in the 100.64.0.0/10 private subnet, handles authentication, and enforces policies. The actual traffic never passes through it.
• Signal Server. Helps two devices exchange public keys and figure out how to connect directly. It is involved during connection setup and then steps aside.
• STUN/TURN (Coturn). Required for NAT traversal. STUN lets devices discover their public address. TURN kicks in when a direct connection cannot be established and relays traffic instead. In practice this is rare, mostly when one side sits behind a symmetric NAT (typical for home routers).
• The web panel where admins manage users, groups, policies, and setup keys.

When two devices want to talk, the handshake roughly looks like this. Both connect to the management server first and pull the list of other peers. Then they exchange keys and addresses through signal. After that they try to set up a direct WireGuard tunnel. If it works, all traffic flows directly between them, bypassing every server. If NAT on one side will not open up, TURN takes over.

One important point: even if the management server goes down, existing connections keep working. Only new device registration and policy updates break. This is a sharp contrast with classic VPN architectures, where losing the gateway means losing the entire network.

NetBird vs WireGuard, Tailscale, and OpenVPN

To understand who actually needs NetBird, it helps to put it side by side with the alternatives.

Plain WireGuard is just a protocol. Fast, secure, lean codebase, but absolutely nothing beyond encrypted tunnels. All the surrounding infrastructure (key distribution, policies, NAT traversal, monitoring) is on you. On two servers it is painless. On fifty it becomes a constant headache.

OpenVPN is the early-2000s classic. Stable, battle-tested, but built on a star topology: every client connects to the server, all traffic flows through it. Performance lags behind WireGuard, configs are verbose, and the server becomes a single point of failure. Fine for a small office, cramped for a hundred-person distributed team.

Tailscale is NetBird's closest competitor in terms of approach. Same mesh on top of WireGuard, same polished interface. The defining difference is that Tailscale's control plane is closed and runs only in the vendor's cloud. For a small team on the free tier that is fine, but if full independence from external infrastructure or data residency requirements matter, the choice gets less obvious.

ZeroTier also builds mesh networks, but uses its own protocol instead of WireGuard. That gives some convenient features (virtual L2 segments) but also locks you into one vendor more tightly than NetBird does.

Comparison table:

Strengths and weaknesses of NetBird

Where NetBird shines:

• Fully open source, including the management server. Tailscale only opens its client.
• Runs WireGuard in kernel mode on Linux, which outperforms userspace.
• Access policy management through the web UI without hand-editing JSON files.
• Integration with identity providers (Google, Microsoft Entra, Okta, Keycloak) plus a built-in Dex server for setups without an external IdP.
• Posture checks: you can block connections from outdated OS versions or devices missing recent updates.
• No caps on users or devices when self-hosted.

Where you will have to put in some work:

• Self-hosted setup needs a public domain and a valid TLS certificate. Without them the dashboard will not come up.
• Basic Docker knowledge is required. Without it even the automated installer raises questions.
• The project moves fast, releases come out regularly, and config formats sometimes change between versions. You need to follow the release notes.

Use cases

When NetBird actually solves a real problem:

1. Secure remote access to internal services. Employees reach internal GitLab, Confluence, or databases without exposing those services to the public internet.
2. Connecting multiple offices or data centers. A single Linux host at each site acts as a routing peer, exposing the entire local subnet to the rest of the network. Each site needs its own server, and a VPS at Serverspace is well-suited for this role: a minimal config is enough, and you can spin one up in the region you need within minutes.
3. Access to Kubernetes clusters and private databases across different VPCs. A single peer inside the VPC becomes the gateway through which the team reaches the cluster, with no public endpoints needed.
4. Replacing the SSH bastion. NetBird natively manages SSH access to servers and distributes keys automatically.
5. Connecting IoT and edge devices. Cameras, controllers, and remote industrial gateways can be pulled into a single private network without any public ports exposed.

What you need to install

Before you start, gather the following minimum:

A Linux server with Ubuntu 22.04 or 24.04. Debian 11+, CentOS Stream, RHEL, and compatibles also work. Minimum specs: 1 vCPU, 2 GB RAM, 20 GB disk. A basic VPS at Serverspace with Ubuntu pre-installed is a good fit and can be deployed in a couple of minutes.

• A public IP address.
• A domain name with an A record pointing to that IP. Without a domain you cannot auto-issue a TLS certificate via Let's Encrypt, and without a certificate the dashboard will not work.
• Open ports: TCP 80 and 443 for the dashboard and Let's Encrypt, UDP 3478 for STUN/TURN.
• Docker installed with the compose plugin v2 or newer.
• The jq and curl utilities.

Step-by-step NetBird installation on Linux

Now to the practical part. The whole thing takes about fifteen minutes if your domain and server are already set up. The walkthrough was tested on a fresh Serverspace VPS with Ubuntu 24.04.

Step 1. Prepare DNS

In your domain registrar's control panel, create an A record pointing to the server's public IP. For example:

You can also add a wildcard *.netbird.example.com pointing to the same IP. This is useful if you later want to enable the built-in reverse proxy to expose internal services.

Verify the record has propagated:

The response should be your server's IP. Do not move on until DNS is resolving correctly.

Step 2. Install Docker and dependencies

SSH into the server and update the system:

Install Docker with a single script:

Install the helper utilities:

Verify Docker started:

If both commands print version numbers, move on.

Step 3. Run the installer script

NetBird ships a quickstart script that brings up all required containers. Run:

The script asks a few questions:

• Domain name (the one you set up in step 1).
• Email for Let's Encrypt (used for certificate expiration notices).
• Reverse proxy type. The default is Traefik, and for most cases that is the right pick: it issues and renews the certificate automatically. Just hit Enter.

After the answers the script pulls the images, brings up management, signal, dashboard, and Coturn as a single Docker Compose stack, and Traefik issues the TLS certificate via Let's Encrypt. The whole process takes a few minutes depending on your network.

Step 4. First login to the dashboard

Open your domain in a browser:

You will see a login screen powered by the built-in Dex provider. Register the first user with an email and password.

Important: the first user automatically becomes the admin of the account. All subsequent registrations land in the same account, so do not leave the dashboard exposed in a public network unnecessarily, and do not put off creating the first user for too long.

After login you will land in an onboarding flow that walks you through creating your first network and connecting a couple of devices. If you would rather poke around the settings yourself, you can skip it and go straight to the main interface. The left sidebar has: Peers (connected devices), Setup Keys (registration keys), Access Control (policies), Networks (virtual networks), Team (users and groups).

Step 5. Create a setup key

A setup key is a single-use or reusable token that lets new devices join your network without an interactive login. Particularly handy for servers and automation.

In the Setup Keys section click Create Setup Key. Fill in:

• Name: a meaningful label like "production-servers".
• Type: Reusable if you plan to enroll multiple devices with the same key.
• Usage limit: cap on the number of registrations (you can leave it unlimited).
• Auto-assign groups: groups that devices registered with this key automatically join.

Save the key and copy its value. You will need it in the next step.

Step 6. Connect your first peer

On any other Linux server you want to add to the network, install the client:

Connect to your management server using the setup key:

Within a few seconds the client confirms the connection. Check status:

The output shows your IP in the 100.64.0.0/10 subnet and information about reachable peers. Connect a second machine the same way and try pinging it by its NetBird address. If ping works, the mesh is live.

Configuration after first launch

The base install is up, but out of the box the network runs on a permissive "everyone can reach everyone" policy. Bad idea for production. Here is what to do first:

• Create groups (Team → Groups). For example: "admins", "developers", "production-servers".
• Distribute peers and users into groups.
• In Access Control, delete the default policy and create new ones, e.g. "developers can reach production-servers only on ports 22 and 5432".
• If you need access to internal office subnets or VPC subnets, set up a routing peer through the Networks section. The selected machine gets the forwarding flag turned on and becomes the gateway to its subnet for the rest of the peers.
• Enable automatic backups of the management server's Docker volumes. All settings, keys, and history live there.

Common mistakes and how to avoid them

Most issues during the first launch come down to a few recurring stories.

The dashboard will not load and Traefik logs show certificate issuance errors. Most often this means the DNS A record either has not propagated or points to the wrong IP. Verify with dig and wait 10-15 minutes after fixing DNS.

Peers connect but only see each other when they are on the same local network. Classic symptom of a closed UDP port 3478. Your management server needs that port open in every firewall layer: ufw on the server itself, and the provider's network policy. Some hosts with stateless firewalls also require opening the UDP port range from ip_local_port_range.

All access policies are wide open and any user sees any server. That is the default behavior, and you absolutely have to change it. Go to Access Control and replace the default policy with your own group-based rules.

Settings lost after migrating the server. Without a backup of the Docker volumes, you cannot restore the account or peer list, you will have to register everyone again. Set up regular volume backups right after install, not after the first incident.

Management server too exposed. The dashboard is publicly reachable by default, and the first registered user becomes admin. If the server sits idle for a few hours after install, someone else may register before you do. Register the first user immediately after install, and ideally limit access to the domain by IP at the reverse proxy layer.

Conclusion

NetBird hits a rare combination of requirements: open source with a management server in your own infrastructure, the convenience of Tailscale-style solutions, and WireGuard's performance. For teams where an aging OpenVPN setup can no longer keep up with distributed infrastructure, but handing control to a third-party cloud vendor is not an option, NetBird is one of the most sensible choices for a modern alternative.

Bringing up a fully working instance on a fresh Linux server takes about fifteen minutes. After that everything depends on your goals: you can stop at simple team access, or grow it into a full network with dozens of peers, group-based policies, corporate IdP integration, and Terraform-driven automation. The simplest path is to spin up a VPS at Serverspace with Ubuntu, spend a quarter of an hour on the install, and try NetBird on a couple of machines. If you like the approach, scaling from there is straightforward.

FAQ

Why is NetBird a better fit than Tailscale for organizations with strict data residency rules?

The key difference is that NetBird's management server can be deployed entirely on your own infrastructure, in the jurisdiction you need. Tailscale only open-sources the client; the control plane runs in the vendor's cloud. For organizations subject to GDPR, HIPAA, or internal security policies that require data localization, NetBird is practically the only option.

Can NetBird be deployed without a public domain?

Technically yes, but you would have to skip Let's Encrypt automation and supply your own certificate, or run plain HTTP without TLS, which is insecure. In practice it is easier to register any cheap domain and use it.

How many resources does the NetBird server consume with 50 peers?

Very few. The management server does not carry user traffic itself; it only stores metadata and exchanges short messages with clients. A 50-peer network runs comfortably on 1 vCPU and 2 GB RAM, with the load staying minimal most of the time.

How do you migrate from OpenVPN to NetBird without downtime?

The standard approach is to run NetBird in parallel. The agent gets installed on target servers and clients, you verify it works, and the legacy OpenVPN is shut down only after all users have been migrated. Since NetBird uses its own subnet, there is no conflict with the existing network.

Is it safe to run the management server on the public internet?

Yes, with proper configuration. The server itself has no access to the data flowing between peers (traffic is end-to-end encrypted and bypasses it). The essentials: lock everything down at the firewall, leave only the required ports open, use strong passwords in Dex, and ideally bolt on SSO with two-factor authentication through an external IdP.