NetBird — The Self-Hosted WireGuard Mesh VPN That Puts the Control Plane Back Under Your Roof

1. What Is NetBird, in Plain English

NetBird is an open-source networking platform that stitches your servers, laptops, phones, and cloud workloads into a single private WireGuard mesh — but unlike a traditional VPN, there is no central "concentrator" that every packet has to flow through. Each device talks to the others directly over an encrypted tunnel, and a lightweight control plane you operate yourself handles the boring coordination work: who is allowed to talk to whom, which cryptographic keys are valid, and how peers find each other across the messy reality of home routers and mobile networks. The easiest way to frame it is as the self-hostable, EU-origin answer to Tailscale. Tailscale gives you the same magical "install a client, get a private IP, done" experience, but its coordination server is operated by Tailscale Inc. in the United States. NetBird gives you that same experience with one decisive difference: the coordination server — the part that knows your device list, your users, and your access policies — runs on infrastructure you control. NetBird GmbH (the company behind the project, incorporated in Berlin) also offers a managed cloud, but the entire stack is licensed so that you can rip out their servers entirely and run the whole thing yourself. That distinction is the entire reason this article exists. For a homelabber who just wants to reach a NAS from a coffee shop, or a small team that refuses to route its internal topology through a third-party vendor, "who holds the control plane" is not a footnote. It is the headline. The project lives at github.com/netbirdio/netbird, is written primarily in Go, and at the time of writing sits at roughly 29,600 GitHub stars — comfortably in the top tier of self-hosting projects. The server components are licensed AGPL-3.0; the client libraries are BSD-3-Clause. The current stable release line is v0.79.x, shipped in September 2026, and the repository shows active daily commit activity.

2. The Pain NetBird Is Actually Solving

To appreciate what NetBird removes, you have to remember what "connecting to your stuff remotely" used to mean. The legacy answer is a road-warrior VPN: a single concentrator appliance or daemon (OpenVPN, IPsec, a corporate firewall) that every remote user tunnels into. All traffic funnels through that one box, which means the box is both a performance bottleneck and a single point of failure. When it dies, the entire company loses remote access. When it gets busy, everyone's throughput collapses to whatever that one box can push. Worse, the legacy model forces you to think in IP addresses and port forwards. Want to expose a service? You punch a hole in the firewall. Want to revoke a departing employee? You hope you remembered to delete their account and the right firewall rules — and if you forgot one, you have a silent hole. Traditional VPNs authenticate the connection, not the resource. Once you are "inside," you can usually reach far more than you should. NetBird flips the model. Instead of a perimeter you punch through, it builds a flat encrypted mesh where every peer is identified by a cryptographic key and a user identity, and access is granted per-resource through policies. There is no "inside the network" vs "outside the network" — there is only "this identity is allowed to reach this peer on this port," evaluated continuously. That is the zero-trust framing the project leans on, and it is not just marketing: the policy engine genuinely evaluates every connection against your rules. For the self-hoster, the practical win is simpler. You install the NetBird client on your laptop and your home server, they find each other through your own signal server, and they negotiate a direct WireGuard tunnel. No Dynamic DNS fiddling, no port forwarding on the home router, no exposing your services to the public internet just to reach them from your phone.

3. How NetBird Works — The Architecture

NetBird is not a single binary. It is a small orchestra of cooperating services. Understanding the pieces is the difference between a smooth self-host and a weekend of confusion.

• Management service — the brain. It stores the network state: peers, users, groups, and access-control policies. It issues and rotates WireGuard keys. It is the component you protect most, because it holds the map of your private network.
• Signal service — a matchmaker. When two peers want to connect, the signal server introduces them by exchanging the minimal connection hints they need to attempt a direct link (think of it as a secured handshake broker). It never sees the actual tunnel traffic.
• Relay service (turn) — a safety net. If two peers are trapped behind stubborn NATs that block direct connections, the relay forwards the already-encrypted WireGuard packets between them. Crucially, the relay only carries ciphertext it cannot decrypt.
• Coturn (TURN server) — standard STUN/TURN used to help peers discover their public reachability, especially for the relay fallback path.
• Reverse proxy (your choice) — typically Traefik or Caddy, terminating TLS and routing the public endpoints of the management and signal services. NetBird ships example configs for Traefik.

The clients — native apps for Linux, macOS, Windows, iOS, and Android, plus a headless Linux daemon — run WireGuard under the hood (via the OS WireGuard implementation or wireguard-go on platforms without kernel support). When a client starts, it authenticates to your management service (through your OIDC identity provider), receives its network configuration and permission set, and then negotiates tunnels with whatever peers its policies allow.

4. The WireGuard Data Path vs the Control Plane

The single most important mental model is the separation between the data plane and the control plane, and NetBird honors it strictly. The data plane is WireGuard. Once two peers have exchanged keys and connection details, they communicate peer-to-peer using WireGuard's Noise-protocol encryption. The management, signal, and relay servers are not in that path. Your file transfers, database queries, and SSH sessions flow directly between the two devices at near-line-speed, limited only by the slower peer's upload bandwidth — not by a central server. This is why a mesh scales differently from a hub-and-spoke VPN: adding peers adds direct links, not central load. The control plane is everything else: the management API, the key distribution, the policy evaluation, the peer directory. It is chatty at setup time and quiet afterward. If the control plane goes offline, existing tunnels keep working — your already-connected peers do not suddenly drop — but new peers cannot enroll and policies cannot be re-evaluated until it returns. That is an important failure mode to internalize, and we will return to it in the limitations section. This separation is also why NetBird's relay servers cannot spy on you. They forward opaque WireGuard UDP packets. Without the private keys, which live only on your devices, the relay sees only encrypted noise. The signal server is even more innocent: it brokers connection setup and then steps out of the conversation.

5. Identity-Based Access Control

NetBird's access model is built around four objects: peers (devices), users (people, from your IdP), groups (collections of either), and policies (rules that connect a source group to a destination group on specific ports and protocols). A policy is not "allow VLAN 10 to talk to VLAN 20." It is "allow the group 'engineers' to reach the group 'production-servers' on TCP 5432 and 22." Because groups can mix users and devices, you can express things like "only laptops owned by admins may reach the bastion," or "the CI runner may talk to the staging cluster but nothing else." Each policy is evaluated per flow, so revoking a user from a group instantly severs their access at the next policy refresh. This is a genuine step up from "once connected, free to roam." In a traditional VPN, the access decision is made once at the gate. In NetBird, the access decision travels with the connection. For a self-hoster, it means you can give a friend access to only your Minecraft server without accidentally granting them a route to your entire LAN.

6. Self-Hosting 101 — The Component Map

Self-hosting NetBird means running the five control-plane services plus your reverse proxy and a database. The officially blessed path is a single docker-compose.yml that bundles Management, Signal, Relay, Coturn, and a Traefik reverse proxy, with a SQLite database by default (PostgreSQL is supported and recommended at scale). You will need:

• A Linux host (VM or bare metal) with a public IP. This is the one non-negotiable: the signal and relay services must be reachable from the internet so peers behind NAT can find each other.
• A domain name you control, with DNS records pointing at that host. You will issue TLS certificates (Let's Encrypt is the standard, free choice) so clients trust the management endpoint.
• Docker and Docker Compose installed.
• About 20 minutes of focused configuration the first time.

The good news: the project's netbirdio/netbird repository ships a deploy/docker/ directory with a working compose file and a setup.env that you populate with your domain, the management URL, the signal URL, and a handful of generated secrets (the setup script can even generate some of them for you). You are not assembling this from scratch.

7. Installation Walkthrough

The practical sequence most people follow: 1. Provision the host. A small VPS works. Point an A record (e.g. netbird.yourdomain.com) and a wildcard or specific records for the signal subdomain at the host's IP. 2. Clone the deploy repo and copy setup.env.example to setup.env. Fill in NETBIRD_DOMAIN, NETBIRD_MGMT_API_HOST, NETBIRD_SIGNAL_HOST, and the TLS email for Let's Encrypt. 3. Generate keys and secrets. The provided script produces the WireGuard management key pair and a few random strings for session security. 4. Run the stack. docker compose up -d brings up Management, Signal, Relay, Coturn, and Traefik. Traefik obtains certificates automatically. 5. Create your first admin user. The management service supports OIDC, but for a first bootstrap you typically use the built-in IdP or a local account, then wire up your real OIDC provider afterward. 6. Install a client on your laptop, log in through the client to your self-hosted endpoint, and watch it appear in the management dashboard as a peer with a private IP from NetBird's address range. The first-run experience has improved dramatically across 2025 and 2026; the v0.79 line includes reliability fixes for DNS conflicts and faster recovery after network changes that make the client far less finicky than early versions.

8. Connecting Your First Peers

Once the dashboard shows your laptop, adding more devices is trivial and symmetric. Install the client on a second machine, authenticate against your self-hosted endpoint, and both devices receive each other's WireGuard keys and allowed-IP routes through the management service. Within a few seconds they attempt a direct connection. If both are on normal networks, the tunnel forms peer-to-peer and stays there. The dashboard assigns each peer a stable private IP (from the NetBird network range you configure, often something like 100.64.0.0/10 style CGNAT space to avoid clashing with your LAN). You can pin hostnames, tag devices, and place them in groups. For headless servers — a NAS, a Raspberry Pi, a cloud VM — there is a headless setup command that logs in via a setup key rather than an interactive browser, which is exactly what you want for automation.

9. Access Control Policies in Practice

Here is where the zero-trust claim becomes concrete. Suppose you have three peers: your laptop, a home server running a PostgreSQL database, and a friend's laptop you want to grant limited access to. You create a group db-servers containing the home server, and a group friends containing your friend's peer. You then write a policy: source friends, destination db-servers, protocol TCP, ports 5432. Your own laptop, being in a different (admin) group, might have a broader policy. The moment you save the policy, the management service pushes the updated allowed-IP and key configuration to the relevant peers. Your friend can now reach Postgres and nothing else — not your LAN, not your router, not your other services. Policies can also be scoped by port ranges and can be enabled or disabled with a toggle, which makes temporary access (a contractor for a week, a debugging session) a one-line change rather than a firewall reconfiguration.

10. DNS and Private Name Resolution

NetBird can run its own DNS within the mesh, which means peers can reach each other by name rather than memorizing private IPs. This is handled by the client's local resolver, and the v0.79 line specifically hardened DNS behavior when something else already owns port 53 (a classic conflict with systemd-resolved): it now falls back from an eBPF DNS forwarder to UDP/TCP DNAT rules with proper cleanup, so a port-53 clash no longer silently breaks name resolution across your whole machine. For the self-hoster this is the difference between typing postgres.netbird and 100.64.0.7. You can also route specific domains through the mesh — handy if you want .internal.company.com to resolve only inside the network.

11. Routing Traffic and Exit Nodes

Beyond peer-to-peer, NetBird supports routes: you can advertise that a peer (or the network behind it) is reachable, and other peers can be allowed to use it as a gateway. The canonical example is an "exit node" — a peer with a good internet connection that other peers route their traffic through, effectively giving them a secure egress point. Another is exposing an entire on-prem subnet: advertise 192.168.1.0/24 from a peer sitting on that LAN, and remote peers can reach devices inside it without those devices ever installing NetBird. Routes are gated by the same policy engine, so "allow this peer to use that exit node" is just another rule. This is powerful, and also a place where careless route advertising can accidentally bridge networks you did not intend to bridge — a limitation we will address honestly later.

12. Mobile and Desktop Clients

NetBird ships native clients for every mainstream platform: Windows, macOS, Linux, iOS, and Android, plus a CLI and a headless daemon for servers. The desktop app got a proper light-mode theme in v0.79 (System / Light / Dark), and the mobile SDKs gained shared MDM policy enforcement so managed-device fleets behave consistently across phones and computers. The honest caveat on mobile: iOS and Android both aggressively suspend background network processes to save battery. A WireGuard tunnel may be torn down when an app is backgrounded, meaning push-style "always on" reachability is not guaranteed the way it is on a plugged-in server. For interactive use — "open the app, tap connect, reach my files" — it is perfectly fine. For "my phone should always be a stable reachable node in the mesh" — it is not reliable, and that is an OS limitation, not a NetBird bug.

13. OIDC SSO With Your Own Identity Provider

This is the feature that, more than any other, defines NetBird's sovereignty story. Authentication is delegated to an OIDC-compatible identity provider that you operate. The open-source edition integrates cleanly with Keycloak, Authentik, and Zitadel — all of which are themselves self-hostable (and two of which we have covered in this series). When a user logs into the NetBird client, they are redirected to your IdP, prove who they are there (with your MFA rules, your password policy, your user directory), and NetBird receives only a verified identity assertion. Your credentials never touch the NetBird management service. For a team, this means user lifecycle is handled where it should be: disable the account in your IdP, and the user loses NetBird access automatically. You are not maintaining a second user directory inside yet another product.

14. Real Self-Hosting Cost Numbers

Let us put actual numbers on running NetBird yourself, because "free as in AGPL" does not mean "free as in zero infrastructure." Compute. The control plane is lightweight. For a homelab or a small team (up to a few dozen peers), a single small VPS is enough: one vCPU and 512 MB–1 GB of RAM comfortably runs Management, Signal, Relay, Coturn, and the reverse proxy. A Hetzner CX22 (2 vCPU, 4 GB RAM, 40 GB SSD, inclusive traffic) runs about €4.51/month — roughly $4.90. If you want more headroom for growth or for hosting the database separately, a CX31 (2 vCPU, 8 GB) is about €8.21/month (~$8.90). Netcup and similar EU budget hosts land in the same band. Domain. One domain or subdomain, roughly $10–15/year, i.e. about $1/month amortized. TLS certificates via Let's Encrypt are free. Database. SQLite (default) costs nothing extra and is fine for small deployments. If you outgrow it, a managed PostgreSQL adds maybe $0–13/month depending on whether you run it on the same VPS or a separate instance. Bandwidth. This is the pleasant surprise. Because WireGuard traffic is peer-to-peer, your server mostly carries only the small control-plane chatter. The relay only engages when direct connection fails; even then, relayed traffic is modest unless you have many peers stuck behind symmetric NAT. Most self-hosters stay well within their VPS provider's fair-use traffic allowance and never pay egress overage. Total all-in. For a typical self-hosted deployment: roughly $6–12/month (mostly the VPS), with no per-user fee, ever. Compare that to Tailscale's Standard plan at about $6 per user per month: a 10-person team pays ~$60/month there, versus ~$10/month self-hosting NetBird — and the gap widens as your headcount grows, since NetBird's cost is essentially flat while Tailscale's scales linearly with seats. For a 50-person org the difference is hundreds of dollars a month for functionally similar connectivity. The catch, of course, is that your $10/month does not include an SLA, a support line, or someone to page at 3 a.m. — those are real costs you absorb in engineering time.

15. Where Your Data Goes — Data Sovereignty

This is the section the whole project is built around, so let's be precise about what the self-hosted deployment actually stores and where it travels. What the management server stores on your infrastructure:

• Peer records: device names, public WireGuard keys, assigned private IPs, last-seen timestamps, and source IPs at check-in (these are PII — see the caveat below).
• User identities: the assertion received from your OIDC provider (typically an email and a subject ID), never passwords.
• Group memberships and access-control policies you define.
• Audit logs of management events (who connected, policy changes) if enabled.

What never touches the control plane:

• The actual WireGuard session traffic between your devices. It is end-to-end encrypted and peer-to-peer. The signal server only brokers setup; the relay only forwards ciphertext it cannot read.

Jurisdiction. If you run the stack on a VPS in the EU (say, a German region), your coordination data resides under EU/GDPR jurisdiction, operated by you — not under US CLOUD Act reach, which is the explicit differentiator NetBird markets against US-based competitors. The vendor itself, NetBird GmbH, is Berlin-incorporated. The honest caveats on sovereignty:

• The default SQLite database is not encrypted at rest. You should encrypt the underlying volume (LUKS, or your provider's disk encryption) or use an encrypted database backend. "Self-hosted" does not automatically mean "encrypted at rest."
• Audit and check-in logs contain IP addresses and timestamps — that is personal data under GDPR. If you operate this for others, you need a lawful basis and a retention policy.
• If you instead use NetBird's managed cloud (not self-hosted), your coordination data lives with NetBird GmbH. That is still EU-based, but it is no longer "your roof." This article assumes the self-hosted path.
• OIDC delegates auth to your IdP, so the strength of your sovereignty here is only as good as your IdP's hardening. Run Authentik or Keycloak properly and you keep the chain unbroken.

In short: self-hosted NetBird keeps your network map, your user directory linkage, and your policy definitions on your own server, while the traffic itself is E2E encrypted and never centralizes. That is a genuinely strong sovereignty posture — provided you harden the database and treat the logs as PII.

16. Honest Limitations

No tool this powerful is free of rough edges, and NetBird has several worth naming before you commit. 1. It is a multi-service control plane. Management, Signal, Relay, Coturn, reverse proxy, and a database — that is a real surface to operate. If you wanted "one binary, done," this is not that. 2. Community edition is active-passive for high availability. True active-active HA, SCIM user provisioning, and SIEM event streaming are commercial features. For most homelabs that is fine; for a regulated enterprise it may be a blocker without a paid tier. 3. NAT traversal can fail. Behind symmetric NAT or restrictive corporate firewalls, peers fall back to the relay, which adds latency and consumes your server's bandwidth. In the worst case, some networks simply will not connect directly. 4. The AGPL-3.0 server license is copyleft. If you modify the server and offer it as a network service to others, you must release your corresponding source. That is a feature for some and a constraint for others — but it is not the permissive MIT you might assume. 5. Mobile background connectivity is unreliable due to OS battery management, as noted. 6. DNS port-53 conflicts are a classic first-run trap (now much better handled in v0.79, but still possible on unusual hosts). 7. Learning curve. If you are not comfortable with Docker, reverse proxies, and TLS, the setup will feel opaque. The docs are good but assume networking literacy. 8. Control-plane downtime hurts enrollment, not existing tunnels. If your management server dies, already-connected peers keep talking, but no new peer can join and no policy can update until it returns. Plan backups accordingly. 9. Route advertising is powerful and dangerous. A mistyped route can bridge networks you did not mean to expose. The policy engine protects access, but it does not stop you from advertising a too-broad subnet. 10. Community support only. GitHub issues and Discord are where you get help. There is no SLA on the free edition. 11. You own certificate and domain hygiene. Expired TLS certs or a lapsed DNS record are now your outage, not a vendor's. 12. Client updates are distributed. You are responsible for keeping clients reasonably current; very old clients may not support newer policy features. None of these are disqualifying for the target audience, but they are the difference between "magical" and "a system I maintain."

17. Security Model and Threat Surface

NetBird's security rests on three legs. First, WireGuard's cryptographic core — a well-audited, modern protocol with no optional weak ciphers. Second, the policy engine, which enforces least-privilege access per flow. Third, delegated identity via OIDC, so credential strength lives in your IdP. The threat surface you must defend is the control plane. If an attacker compromises your management server, they could in principle enroll rogue peers and alter policies — though they would still need valid credentials (your OIDC) to enroll users, and they would still face WireGuard's key authentication for the data plane. Hardening priorities: protect the management host with a firewall, run it behind your reverse proxy with strong TLS, isolate the database, encrypt it at rest, and restrict who can reach the management API. Integrating your IdP's MFA is not optional if you care about sovereignty — it is the front door. One more subtle point: because the relay can carry traffic when direct links fail, you should treat the relay host as handling sensitive (encrypted) bytes. It cannot read them, but you still do not want it compromised for availability reasons.

18. High Availability and Production Hardening

For a serious deployment, a single VPS is a single point of failure for enrollment. The community edition supports active-passive: run a warm standby of the management service with the same database, and fail over manually or via your orchestrator. The data plane stays resilient regardless, because existing tunnels do not depend on the management server being up. Hardening checklist for production:

• Use PostgreSQL rather than SQLite once you exceed a handful of peers or need concurrent writes.
• Put the whole stack behind an external reverse proxy you already trust (Traefik or Caddy), with automatic certificate renewal.
• Restrict management API access by network policy; do not expose more than necessary.
• Enable audit logging and ship logs to your SIEM or at least a retained store (mind the PII).
• Encrypt the database volume.
• Run the rootless container image (added in v0.79) on hardened hosts to reduce container-escape blast radius.
• Monitor the control plane with the same tools you use elsewhere — and note that we have covered monitoring and reverse-proxy options elsewhere in this series (see Related below).

19. Backups and Disaster Recovery

Back up the database. This sounds obvious, but it is the one step that turns a control-plane outage from "catastrophic" to "annoying." With SQLite, schedule a periodic copy of the database file (while the service is quiesced or via a backup client that handles open files). With PostgreSQL, use your standard pg_dump or replica snapshot. Also back up your setup.env and compose configuration, because regenerating the WireGuard management keys means re-enrolling every peer. Store secrets in a password manager, not in a world-readable file on the host. Test a restore once; a backup you have never restored is a hope, not a plan.

20. Upgrades and Maintenance

NetBird releases frequently — the v0.79 line alone bundled a large set of client, management, and relay fixes. Upgrading the self-hosted stack is usually a matter of pulling new images and recreating the containers, plus applying any migration notes from the release. Because the data plane is independent, upgrading the control plane does not drop your tunnels; peers simply re-sync their config on the next management contact. Maintenance cadence: subscribe to the GitHub releases, skim the changelog for breaking changes (they are rare but real), and stage upgrades on a test host if you run a large network. The SQLite network-map fixes in v0.79 are a good example of why staying current matters — they resolved routers dropping out of the map on empty peer-group fields.

21. NetBird vs Tailscale vs Headscale

A fair comparison needs three entries.

• Tailscale offers the smoothest experience and the best mobile behavior, but its coordination server is operated by Tailscale Inc. in the US. You trade sovereignty for convenience and an SLA. Pricing is per seat.
• Headscale is the open-source, single-binary reimplementation of Tailscale's control server. It is lighter to run than NetBird's multi-service plane, but it inherits Tailscale's client and lacks NetBird's richer built-in policy/group UI and relay packaging. For pure "I want Tailscale but self-hosted," Headscale is the minimalist choice.
• NetBird sits between them: more moving parts than Headscale, more sovereign than Tailscale, with a first-class policy engine and bundled relay/TURN. If you want the Tailscale feel and a self-hosted control plane and* granular per-flow policies without bolting them on, NetBird is the most complete out-of-the-box answer.

The right pick depends on whether your priority is "fewest services to run" (Headscale), "zero ops" (Tailscale), or "sovereign plus powerful policies" (NetBird).

22. Common Failure Modes and How to Debug

When NetBird misbehaves, it is almost always one of these:

• Peers show "connected" but cannot ping. Check the policy: the peers may be enrolled but no policy grants the source group access to the destination. Enrollment is not access.
• A peer stays in "relay" mode with high latency. Symmetric NAT or a strict firewall is forcing the fallback. Verify the signal and relay ports are reachable; consider a TURN relay with a public IP.
• DNS resolution breaks system-wide after install. Classic port-53 clash; the v0.79 DNAT fallback usually fixes it, but on unusual hosts you may need to disable the NetBird DNS forwarder for the LAN.
• New peers cannot enroll after a control-plane restart. The management service may not have come back cleanly, or the database did not mount. Check container logs and the database volume.
• Mobile client drops. Expected OS behavior; use on-demand connection rather than expecting always-on.
• TLS errors in the client. Usually an expired certificate or a mismatch between the configured management host and the certificate's SAN. Renew the cert and align the URLs in setup.env.

The management service logs and the client's "connection details" view (showing direct vs relay, latency, and the negotiated path) are your best friends here.

23. Use Cases That Fit Beautifully

• Homelab remote access. Reach your NAS, home assistant, and self-hosted services from anywhere without port-forwarding your router or exposing anything publicly. This is the most common entry point, and it pairs naturally with the reverse-proxy and dashboard tools we have reviewed.
• Small distributed teams. A handful of people across home networks and cloud VMs, all able to reach shared internal tools (a staging database, a private dashboard) as if on one LAN — without a commercial VPN bill.
• Secure access to cloud workloads. Spin up a VPS, enroll it, and reach it by private IP from your laptop, no cloud security-group juggling.
• IoT and edge. Headless Linux devices enroll via setup keys and become manageable nodes in a private mesh.

24. When NOT to Use NetBird

Be honest about the mismatch cases. If you are a non-technical user who just wants "VPN on my phone," the setup burden will defeat you — use the managed cloud or a commercial product. If you need guaranteed always-on mobile reachability, OS limitations will frustrate you. If you run a large enterprise requiring active-active HA, SCIM, and a support SLA out of the box, budget for the commercial tier rather than fighting the community edition's ceiling. And if your only goal is "expose one web app," a single reverse proxy with authenticated access may be simpler than standing up a whole mesh.

25. Community, Support, and Governance

NetBird is developed in the open on GitHub under netbirdio/netbird, with an active issue tracker and a community Discord. The company behind it, NetBird GmbH, sells a managed cloud and enterprise features (HA, SCIM, SIEM streaming, support) that fund the open-source core — a sustainable model that keeps the AGPL server free. Because the server is AGPL-3.0, the project cannot be quietly re-licensed into a closed service without violating the license's network-copyleft clause, which is a meaningful protection for users who worry about open-source projects getting rug-pulled. The client's BSD-3-Clause license keeps integrators unencumbered on the device side. Governance is vendor-led rather than foundation-run, which is worth noting: the roadmap ultimately serves the company's commercial interests, even as the core stays open. For most self-hosters that is a non-issue, but if vendor independence is a hard requirement, weigh it against foundation-governed alternatives.

26. Alternatives Worth Knowing

Beyond Tailscale and Headscale (covered above), the adjacent ecosystem includes:

• WireGuard itself, bare-metal, if you want maximum simplicity and are happy managing keys and config by hand (no policy UI, no auto-NAT traversal).
• Innernet / wg-access-server, lighter WireGuard front-ends with varying feature depth.
• ZeroTier, a different mesh approach (not WireGuard) with its own self-hosted controller option.
• OpenZiti / Nebula, mesh designs emphasizing application-embedded zero-trust rather than network-level VPN.

Each trades away something NetBird bundles — usually the polished policy UI, the relay fallback, or the OIDC integration — in exchange for a smaller footprint or a different security model.

27. A Practical Rollout Checklist

If you decide to self-host, here is the sequence that avoids the usual pain: 1. Stand up a small VPS and a domain; point DNS at it. 2. Issue TLS certs via Let's Encrypt through your reverse proxy. 3. Deploy the compose stack; verify each service container is healthy. 4. Bootstrap an admin account; log in to the dashboard. 5. Wire up your OIDC IdP (Authentik or Keycloak) and enforce MFA. 6. Enroll your laptop and one server; confirm a direct tunnel forms. 7. Write one minimal policy (your admin group → a test resource) and verify it works. 8. Encrypt the database volume and schedule backups. 9. Document the recovery steps; test a restore. 10. Only then enroll the rest of your devices and teammates. Move slowly through steps 1–7 and the rest is downhill.

28. Bottom Line

NetBird is, in 2026, the most complete self-hostable answer to the "Tailscale but mine" question. It gives you a WireGuard mesh where the control plane — the part that knows your devices, users, and access rules — runs on your own infrastructure, under your own jurisdiction, behind your own identity provider. Traffic stays end-to-end encrypted and peer-to-peer, so the server you operate never sees your data in the clear. The real cost is modest: roughly $6–12/month for a small VPS, with no per-user fee, versus steadily rising SaaS bills as your team grows. The trade you make is operational: NetBird is a multi-service system you maintain, its community edition stops short of enterprise-grade HA and provisioning, and mobile background connectivity remains at the mercy of phone operating systems. None of that is fatal for the homelabber or the small team that values sovereignty over zero-ops. If your priority is keeping your network map, your user directory linkage, and your policy definitions under your own roof — while still getting the magical "install and connect" experience — NetBird earns its place in the self-hosting stack. Related:

• Headscale — Run Your Own Tailscale Control Server
• Traefik — The Self-Hosted Reverse Proxy That Just Works
• Caddy — Automatic HTTPS for Every Self-Hosted Service
• Authentik — Self-Hosted Identity and SSO
• CrowdSec — Collaborative Threat Intelligence for Your Stack