Set Up Netbird as a Self-Hosted Zero-Trust Network Overlay

Taking Network Security Into Your Own Hands

Zero-trust networking used to mean expensive enterprise contracts, proprietary hardware, and vendor lock-in that lasted years. Netbird changes that equation entirely. It is an open-source, WireGuard-based network overlay that lets you build a private, encrypted mesh network across any mix of servers, cloud instances, containers, and developer machines – without punching holes in firewalls or relying on a central VPN gateway. Every peer authenticates, every connection is encrypted end-to-end, and access control lives in policy rules rather than network topology.

Self-hosting Netbird means you run the management server, the signal relay, and the STUN/TURN coordination layer yourself. Your traffic routing decisions never touch a third-party cloud. For teams handling sensitive infrastructure, internal APIs, or regulated data, that distinction matters more than any convenience feature a managed service could offer.

What You Need Before Starting

Netbird’s self-hosted stack has four core components: the Management service (API and policy engine), the Signal service (peer coordination), the Relay service (fallback when direct peer-to-peer fails), and a Coturn instance for STUN/TURN. You will also need a domain with DNS pointing to your server, a valid SSL certificate (Let’s Encrypt works fine), and Docker with Docker Compose installed. The official setup script bundles all four components into a single Compose file, which keeps the initial deployment manageable.

Pick a small cloud VM or a dedicated machine with at least 1 CPU core and 1 GB of RAM for light use. The management service is the only component that writes to a database – it defaults to SQLite, though PostgreSQL is available for larger deployments. Open ports 443 (HTTPS for the dashboard and API), 3478 (STUN), 49152-65535 (UDP, for TURN relay traffic), and 10000 (Signal service gRPC) in your firewall before running anything.

If Docker container management is part of your broader self-hosted stack, setting up Portainer for visual Docker container management alongside Netbird gives you a clean browser interface for monitoring all running services without dropping into the terminal for every inspection task.

Running the Setup Script

Netbird provides an automated install script that generates your docker-compose.yml and .env configuration in one pass. Run it with your domain and an identity provider choice. For self-hosted deployments without an external IdP, Netbird supports Zitadel as a bundled option, which the script can configure automatically. The command looks like this:

• Download the setup script: curl -sSLO https://raw.githubusercontent.com/netbirdio/netbird/main/infrastructure_files/getting-started-with-zitadel.sh
• Make it executable: chmod +x getting-started-with-zitadel.sh
• Run it with your domain: ./getting-started-with-zitadel.sh
• Follow the prompts for domain, SSL, and admin credentials
• Start the stack: docker compose up -d

Once the containers are running, the Netbird dashboard is accessible at your domain over HTTPS. Log in with the admin credentials you set during setup. The Zitadel identity panel runs on a separate port – typically 8080 – and handles user creation, OAuth clients, and role assignments. You will need to create at least one user account in Zitadel before any client can authenticate against your management server.

Connecting Peers and Writing Access Policies

Installing the Netbird client on any peer is a single command. On Linux, the official install script handles repository setup and daemon configuration automatically. On macOS and Windows, there are native GUI clients available. After installation, run netbird up –management-url https://your-domain.com:443 and authenticate through the browser prompt that appears. The peer registers with your management server, generates its WireGuard keypair locally, and appears in the dashboard within seconds.

Access control in Netbird works through groups and policies rather than static IP rules. Every peer belongs to at least one group. Policies define which groups can communicate with which other groups, and optionally restrict traffic to specific ports and protocols. A simple production setup might have a “servers” group and a “developers” group, with a policy permitting developers to reach servers on port 22 and 443 only. Peers that do not match any policy rule cannot reach each other at all – that is the zero-trust enforcement mechanism working at the policy layer rather than relying on network segmentation alone.

Netbird also supports DNS-based routing and network routes for reaching subnets that sit behind a peer. If you have a home lab or an on-premises network that is not fully peered, you can designate one peer as a routing peer for a specific CIDR block. Other peers in the allowed group will route traffic for that subnet through the designated peer automatically, without any manual WireGuard configuration. This makes Netbird practical for hybrid environments where not every device can run a client directly.

One area worth watching is the TURN relay fallback behavior. When two peers cannot establish a direct WireGuard connection – due to symmetric NAT or restrictive firewalls – traffic routes through your Coturn instance. That relay traffic is still end-to-end encrypted between peers; Coturn cannot read it. But relay traffic does consume server bandwidth, and on a small VM with many peers behind restrictive NATs, that becomes a real resource consideration. Monitoring the Coturn logs and watching bandwidth on your relay server will tell you quickly whether your hosting tier is sized correctly for actual usage patterns, rather than theoretical peer counts.