NetBird's self-hosting bill is small, and its access control is not

A WireGuard mesh with a control plane attached

The project's own one-line description is that it combines a configuration-free peer-to-peer private network and a centralized access control system in a single platform. Both halves of that sentence matter, and most of the design follows from holding them together.

The mesh half is a WireGuard-based overlay network that automatically connects your machines over an encrypted tunnel. The README lists what that leaves behind: opening ports, complex firewall rules and VPN gateways. Kernel WireGuard is the base, and the connectivity column adds peer-to-peer connections, a connection relay fallback, routes to external networks, domain-based DNS routes, exit nodes, an IPv6 dual-stack overlay, browser SSH and RDP, and a reverse proxy with automatic TLS.

The relay fallback is the piece to understand. A pure mesh needs every pair of peers to reach each other directly, which is not always possible behind symmetric NAT. NetBird relays the traffic when it has to, so the mesh degrades rather than fails.

The wording configuration-free applies to the mesh, not to the access rules. Those are managed from a single place, and that place is a separate admin web UI in its own repository, netbirdio/dashboard.

Self-hosting needs three ports, a domain and one CPU

The self-hosted quickstart is the most concrete part of the README, and it comes with a number: around five minutes to get started, if you already have a public domain and a VM.

The infrastructure requirements are listed as three bullets. A Linux VM with at least 1 CPU and 2 GB of memory. Public reachability on TCP ports 80 and 443 and UDP port 3478. And a public domain name pointing at the VM. The software requirement is Docker with the Compose plugin, version 2 or higher.

Two of those are consequences of the design rather than arbitrary minimums. Ports 80 and 443 are the TLS and web interface, and UDP 3478 is the STUN port the relay fallback needs to discover addresses. Two gigabytes of RAM is the whole budget for the management server, the relay and the identity provider, which is what happens when the product list keeps the heavy dependencies out.

Installations with a different identity provider are pointed at a separate advanced guide, so the five-minute path assumes the built-in one.

Signing up means Google, Microsoft, GitHub or an email address

The cloud quickstart is three steps and one link.

Download and install NetBird from app.netbird.io/install. Follow the steps to sign up with Google, Microsoft, GitHub or your email address. Then open the admin UI at app.netbird.io.

That second step is the whole identity story for the hosted version: four identity providers, all of them external. If your organisation authenticates through something else, that is the point at which self-hosting becomes relevant, because IdP integrations are listed under management in the feature table rather than as a hosted-plan option.

The rest of the management column follows from that separation. Auto peer discovery and configuration means machines find each other without being told addresses. Private DNS and custom DNS zones cover name resolution inside the overlay. Multiuser support and multi-account profile switching handle more than one person and more than one network on the same client.

For automation there is a public API, a Terraform provider, an Ansible collection, setup keys for bulk provisioning and a self-hosting quickstart script.

The security column is where the list gets specific

Most feature tables for this kind of product stop at encrypted and private. The NetBird table does not, and the extra rows are the ones worth reading.

There is SSO and MFA support, and access control by groups and rules rather than by address. There are device posture checks, which is the mechanism for saying a machine that is not compliant does not get its access. There is periodic re-authentication, which forces users back through identity on a schedule instead of trusting a session indefinitely.

SSH is covered by central access policies, so the same rules apply to a shell session as to a file share, and SSH itself is listed under security rather than as a convenience feature.

Then there is quantum-resistance with Rosenpass. That is not a marketing line: the Go module requires cunicu.li/go-rosenpass, so the post-quantum key exchange is a dependency in the client rather than a roadmap item.

Observability is in the same column. Activity logging and traffic events are separate, which suggests audit records and connection records are separate data with separate retention.

Eighteen platforms, and most of them are not operating systems

The platforms column is the longest one in the table and needs reading carefully, because it mixes three different things.

Desktop and mobile clients: Linux, macOS, Windows, Android, Android TV, iOS, Apple TV and FreeBSD.

Network appliances and hypervisors: pfSense, OPNsense, MikroTik RouterOS, OpenWRT, Proxmox and Synology.

And two deployment shapes that are not clients at all: Serverless, for running NetBird on a function-as-a-service platform, and Container, which is a Docker image.

The appliance entries are the interesting ones for anyone already running a homelab. A client on OpenWRT or a MikroTik router changes what you can reach from inside the overlay, and NetBird documents those as use cases rather than as ports. The same applies to Raspberry Pi and TrueNAS in the NAS and single-board category.

What the list does not tell you is whether each entry is a first-party build or documentation for a community integration. For that you have to open the linked page, since each platform entry points at its own documentation path.

The default test suite refuses to touch your network

The Makefile has two test targets and the split is the interesting part, because it is a deliberate statement about what a contributor's machine is allowed to do.

test-unit is described as host-safe. It excludes the privileged-tagged tests, runs as a normal user with no sudo, and leaves host networking untouched. test-privileged runs those excluded tests inside a container started with --privileged and --cap-add=NET_ADMIN, through the ory/dockertest harness, and it needs Docker.

The commands behind them:

go test -tags devcert -timeout 10m ./...
go test -tags 'devcert privileged' -timeout 30m -run TestRunPrivilegedSuiteInDocker -v ./client/testutil/privileged/...

The privileged suite can be narrowed with two environment variables, PRIV_RUN and PRIV_PKGS, which matters because thirty minutes is a long feedback loop.

Linting follows the same philosophy. The default lint target only checks changed files, using --new-from-rev=origin/main with a two-minute timeout, and the Makefile says that is for pre-push; lint-all covers everything with a twelve-minute timeout to match CI. setup-hooks points core.hooksPath at .githooks so that pre-push runs make lint and commit-msg refuses attribution trailers.

Two release candidates and a canary named after a pull request

The release naming tells you how the project ships. The three most recent are v0.80.0-rc.2 on 2026-09-30, v0.80.0-rc.1 on 2026-09-28, and something different: v0.81.0-canary.pr-7662.1 on 2026-09-26.

That third tag is a canary built from a pull request, carrying the PR number in the version. So the project runs release candidates and per-PR canaries from the same pipeline, which is a reasonable way to test a specific change without cutting a release.

The Go module pins its toolchain unusually tightly. It declares go 1.26.0 and then a separate toolchain directive for go1.26.7, with a comment saying it is pinned to a patch release of 1.26.2 or newer and linking a Go issue, number 77875. Anyone building from source inherits that exact patch release.

The build side has a similar split. There are three goreleaser configurations, one plain and two for UI variants, one for Darwin and one for GTK3, which matches the admin web UI living in a separate repository and being embedded into the binaries.

One licensing detail to be aware of: the repository has a LICENSES directory and a CONTRIBUTOR_LICENSE_AGREEMENT, while the repository metadata reports no recognised licence.

Editorial conclusion

NetBird fits a team that wants a flat mesh instead of a hub-and-spoke VPN and needs access rules with names in them, and it fits self-hosters who can give a VM a domain and three open ports. Do not choose it for hardware you have to leave unmanaged, and do not read the platform list as eighteen downloads: it is one client binary plus a set of documented integrations. Before you start, decide which of the two quickstarts you are on, because the cloud route signs you up with Google, Microsoft, GitHub or an email address while the self-hosted route needs a public domain before anything else happens.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes