NetBird vs ZeroTier: Mesh VPN Tools Compared

Quick Verdict

NetBird is the better choice for self-hosters who want full control. It runs on WireGuard, the management plane is fully self-hostable, and it ships with SSO integration, ACLs, and DNS management out of the box. ZeroTier is simpler to get started with — create a network, join nodes, done — but its control plane is cloud-hosted by default, and self-hosting the controller means relying on a community-maintained tool (ztncui) that lags behind the official product. If owning the entire stack matters to you, NetBird wins. If you want the fastest path to an overlay network and don’t mind a cloud dependency, ZeroTier works fine.

Overview

NetBird and ZeroTier solve the same core problem: connecting machines across different networks into a single mesh without traditional VPN tunnels or port forwarding. They take fundamentally different approaches to get there.

NetBird is a Go-based mesh VPN built on top of WireGuard. It provides a self-hostable management server that handles peer discovery, ACL enforcement, DNS management, and SSO integration. Every data-plane connection uses WireGuard, which means you get the performance and security properties of a well-audited, in-kernel VPN protocol. NetBird is licensed under BSD-3-Clause — genuinely open source.

ZeroTier is a C++-based virtual networking platform that creates L2 overlay networks. It uses its own proprietary protocol (not WireGuard) and relies on a cloud-hosted controller at my.zerotier.com by default. You can self-host a controller using the community-maintained ztncui project, but it’s not officially supported and tends to lag behind releases. ZeroTier uses the Business Source License 1.1 (BSL) — source-available but not open source.

Both create peer-to-peer mesh connections with NAT traversal. The difference is in philosophy: NetBird assumes you want to own the infrastructure; ZeroTier assumes you’re fine with a managed control plane.

Feature Comparison

Feature	NetBird	ZeroTier
Underlying protocol	WireGuard	Proprietary (ZeroTier protocol)
License	BSD-3-Clause (open source)	BSL 1.1 (source-available)
Self-hosted management plane	Yes — first-class, officially supported	Community-maintained only (ztncui)
NAT traversal	STUN/TURN with WireGuard	Own NAT traversal (uses root servers)
SSO integration	Built-in (OIDC — Keycloak, Auth0, Okta, etc.)	Not available (API keys only)
Access control lists	Built-in, policy-based	Basic rules via controller
DNS management	Built-in (split DNS, custom domains)	Basic DNS via controller
Network model	L3 mesh (WireGuard tunnels)	L2 virtual Ethernet (overlay)
Client platforms	Linux, macOS, Windows, iOS, Android	Linux, macOS, Windows, iOS, Android, FreeBSD
Peer-to-peer connections	Yes (direct WireGuard)	Yes (direct via ZeroTier protocol)
Relay fallback	TURN server (self-hostable)	Root servers (ZeroTier-hosted by default)
Management UI	Web dashboard (self-hosted)	Web dashboard (cloud at my.zerotier.com)
API	REST API	REST API
RAM usage (management/client)	~100 MB (management server)	~30 MB (client only — controller is cloud)
Multipath support	No	Yes (bond multiple links)
Active development	Very active (frequent releases)	Active (slower release cadence)

Docker Compose: NetBird Management Server

NetBird’s management server is the self-hosted control plane. It handles peer coordination, authentication, ACLs, and DNS. You run this on a server, then install the NetBird client on every machine you want in the mesh.

Create a docker-compose.yml:

services:
  netbird-management:
    image: netbirdio/management:0.35.2
    container_name: netbird-management
    restart: unless-stopped
    ports:
      - "8080:8080"       # Management API and web UI
      - "33073:33073/udp" # Signal server (peer coordination)
    volumes:
      - netbird-mgmt-data:/var/lib/netbird
      - ./management.json:/etc/netbird/management.json:ro
    environment:
      - NB_LOG_LEVEL=info
    command: ["--config", "/etc/netbird/management.json", "--port", "8080"]

  netbird-signal:
    image: netbirdio/signal:0.35.2
    container_name: netbird-signal
    restart: unless-stopped
    ports:
      - "10000:80"
    volumes:
      - netbird-signal-data:/var/lib/netbird

  netbird-coturn:
    image: coturn/coturn:4.6.3
    container_name: netbird-coturn
    restart: unless-stopped
    ports:
      - "3478:3478/udp"   # STUN/TURN
      - "3478:3478/tcp"
    volumes:
      - ./turnserver.conf:/etc/coturn/turnserver.conf:ro
    command: ["-c", "/etc/coturn/turnserver.conf"]

volumes:
  netbird-mgmt-data:
  netbird-signal-data:

You will also need a management.json configuration file. The NetBird documentation provides a generator, but a minimal example:

{
  "Stuns": [
    { "Proto": "udp", "URI": "stun:YOUR_SERVER_IP:3478" }
  ],
  "TURNConfig": {
    "Turns": [
      {
        "Proto": "udp",
        "URI": "turn:YOUR_SERVER_IP:3478",
        "Username": "netbird",
        "Password": "CHANGE_THIS_TURN_PASSWORD"
      }
    ],
    "TimeBasedCredentials": false
  },
  "Signal": {
    "Proto": "https",
    "URI": "YOUR_SERVER_DOMAIN:10000"
  },
  "HttpConfig": {
    "AuthIssuer": "https://YOUR_IDP_DOMAIN",
    "AuthAudience": "YOUR_CLIENT_ID",
    "OIDCConfigEndpoint": "https://YOUR_IDP_DOMAIN/.well-known/openid-configuration"
  }
}

And a turnserver.conf for coturn:

listening-port=3478
fingerprint
lt-cred-mech
user=netbird:CHANGE_THIS_TURN_PASSWORD
realm=netbird
log-file=stdout

Replace YOUR_SERVER_IP, YOUR_SERVER_DOMAIN, YOUR_IDP_DOMAIN, and YOUR_CLIENT_ID with your actual values. NetBird requires an OIDC identity provider — Keycloak, Authentik, Auth0, or similar.

Start the stack:

docker compose up -d

After deployment, install the NetBird client on each machine and point it to your management server:

netbird up --management-url https://YOUR_SERVER_DOMAIN:8080

Docker Compose: ZeroTier Client

ZeroTier’s architecture is different. The controller runs at my.zerotier.com (or via ztncui if self-hosted). The Docker image is the client — you run it on machines that need to join your ZeroTier network.

Create a docker-compose.yml:

services:
  zerotier:
    image: zerotier/zerotier:1.14.2
    container_name: zerotier
    restart: unless-stopped
    cap_add:
      - NET_ADMIN
      - SYS_ADMIN
    devices:
      - /dev/net/tun:/dev/net/tun
    network_mode: host
    volumes:
      - zerotier-data:/var/lib/zerotier-one
    environment:
      - ZEROTIER_ONE_LOCAL_PHYS=eth0  # Your physical interface
    command: ["YOUR_NETWORK_ID"]       # Replace with your ZeroTier network ID

volumes:
  zerotier-data:

Replace YOUR_NETWORK_ID with the 16-character network ID from your ZeroTier controller.

Start the client:

docker compose up -d

Then authorize the node in the ZeroTier controller (either at my.zerotier.com or your self-hosted ztncui instance).

Self-hosting the ZeroTier controller requires the community-maintained ztncui project. It wraps the ZeroTier controller API in a web UI, but it is not officially supported by ZeroTier Inc. and may not support every feature of the latest ZeroTier releases. If full self-hosting is a hard requirement, this is a significant disadvantage compared to NetBird.

Installation Complexity

NetBird has a steeper initial setup. You need to deploy three services (management, signal, coturn), configure an OIDC identity provider, set up DNS records, and create a management.json config file. The NetBird team provides setup scripts and documentation, but expect to spend 30-60 minutes on the first deployment. The payoff is a fully self-hosted stack with SSO, ACLs, and DNS management from day one.

ZeroTier is trivially easy to start with. Create an account at my.zerotier.com, create a network, install the client on your machines, authorize them. Done in under 5 minutes. But this ease comes from offloading the control plane to ZeroTier’s cloud. Self-hosting the controller with ztncui adds significant complexity and fragility, bringing you closer to NetBird’s setup effort but with less polish.

Performance and Resource Usage

Both create direct peer-to-peer connections when possible, falling back to relay servers when NAT traversal fails. In practice, most connections are direct, so throughput is similar.

NetBird uses WireGuard for data-plane encryption. WireGuard is implemented in the Linux kernel, which gives it excellent throughput with minimal CPU overhead. On a modern machine, WireGuard can saturate a gigabit link with negligible CPU usage. The management server uses roughly 100 MB of RAM.

ZeroTier uses its own userspace protocol. It is well-optimized but cannot match WireGuard’s kernel-level performance on Linux. On a 1 Gbps link, expect 700-900 Mbps through ZeroTier versus near line-rate through WireGuard. The client uses around 30 MB of RAM, but since the controller is cloud-hosted, there is no server-side resource cost (unless you self-host ztncui).

For most self-hosting use cases — accessing services remotely, connecting a few servers — both are more than fast enough. The performance difference matters at scale or on constrained hardware.

Community and Support

NetBird has a growing community with an active GitHub repository (frequent commits, responsive maintainers). Documentation is good and improving. The project has strong momentum — it is one of the fastest-growing self-hosted networking tools. Commercial support is available through NetBird’s hosted offering.

ZeroTier has a larger, more established community. It has been around since 2014, has extensive documentation, and a wide ecosystem of integrations. However, the self-hosting story is weaker — official support focuses on the cloud-hosted controller. Community forums are active but the self-hosted controller (ztncui) has a smaller, less active community.

Use Cases

Choose NetBird If…

• You want a fully self-hosted mesh VPN with no cloud dependencies
• You need SSO integration (OIDC) for authenticating users
• WireGuard performance matters to you (kernel-level encryption)
• You want built-in ACLs and DNS management
• Open-source licensing (BSD-3-Clause) matters to your organization
• You are comfortable with a more involved initial setup

Choose ZeroTier If…

• You want the fastest possible setup with minimal configuration
• You are fine with a cloud-hosted control plane (or minimal self-hosting via ztncui)
• You need L2 networking (ZeroTier creates virtual Ethernet segments, not just L3 tunnels)
• You need multipath support (bonding multiple network links)
• You want broader platform support (FreeBSD, embedded devices)
• Your use case is small-scale and a managed control plane is acceptable

Final Verdict

NetBird is the better choice for self-hosters. The entire point of self-hosting is owning your infrastructure, and NetBird delivers on that promise. Its management server, signal server, and TURN relay are all self-hostable with official support. You get WireGuard performance, SSO integration, granular ACLs, and DNS management — all under a genuine open-source license.

ZeroTier is a solid product for overlay networking, but its architecture assumes you will use their cloud controller. Self-hosting the controller is a second-class experience relying on community tools. The proprietary protocol, while performant, does not match WireGuard’s audit pedigree and kernel-level efficiency. And the BSL license means you are using source-available software, not open source.

If you just need to connect three machines quickly and do not care about owning the control plane, ZeroTier gets you there faster. For anything beyond that — especially in a self-hosting context where sovereignty over your infrastructure is the whole point — NetBird is the right tool.

For an even simpler self-hosted WireGuard mesh, consider Headscale (a self-hosted Tailscale control server) as another alternative in this space.

Related

• How to Self-Host NetBird
• How to Self-Host ZeroTier
• Best Self-Hosted VPN and Remote Access Tools
• How to Self-Host Headscale
• How to Self-Host Tailscale with Headscale
• Docker Compose Basics
• Reverse Proxy Setup
• Remote Access: Tailscale, WireGuard, and Cloudflare Tunnel