NetBird: hardening a self-hosted WireGuard ZTNA overlay's control plane

NetBird is an open-source zero-trust network access (ZTNA) platform built on the WireGuard protocol, distributed so it can be self-hosted rather than run only as a managed cloud service. For MSPs evaluating it as a VPN or remote-access replacement, the interesting engineering question is not whether it works — it is how seriously its control plane needs to be treated as production infrastructure.

Architecture and licensing

NetBird combines a lightweight client on each peer with a management plane that handles authentication, key exchange and policy distribution; once peers are connected, data traffic flows directly between them over encrypted WireGuard tunnels rather than through the management service. According to NetBird's GitHub repository, the project is licensed under BSD-3-Clause, except for the management, signal and relay directories, which are licensed under AGPLv3. That is a standard dual-license pattern for self-hostable infrastructure — not a proprietary "open core" trap — but the AGPLv3 obligations on the server components are worth reading before redistributing a modified build.

Why the control plane deserves production treatment

Because NetBird's management service issues the policy and identity decisions that every peer trusts, a self-hosted deployment should get the same operational rigor as any other identity system: SSO and MFA on administrative access, granular per-user and per-group access policies rather than a flat allow-all, audit logging of policy changes, and network-level lockdown of the management, signal and relay services so they are not needlessly internet-facing. Backup and disaster recovery for the control plane matter just as much as the peer-connectivity demo — losing the management database means losing the ability to add, remove or re-key peers, not just a dashboard.

A practical checklist for self-hosting NetBird

• Require SSO and MFA for every administrative account on the management service.
• Write access policies per user/group rather than relying on a broad default-allow rule.
• Restrict network exposure of the management, signal and relay components to what actually needs to reach them.
• Enable audit logging for policy and peer-membership changes.
• Back up the control-plane database and test restoring it before you need to.

Sources: NetBird — GitHub repository, NetBird.