NetBird's Simplified Architecture Makes Self-Hosted VPNs Easier

Anyone who's tried to build secure remote access to a home network knows the inventory list gets long fast. A VPN server. Port forwarding rules. A reverse proxy. Maybe an identity provider. Then the configs that connect them all. Christian Lempa, who runs a popular DevOps YouTube channel, just released a walkthrough of NetBird's complete architectural overhaul—and the changes address exactly this problem.

NetBird has been around for years as a remote access solution for self-hosted infrastructure. The original version worked, but it wasn't simple. Multiple containers, external dependencies, a Zitadel identity provider with its own PostgreSQL database, separate signal and relay servers. Functional, but fragile.

The new version collapses all of that into a single service.

What Actually Changed

Lempa demonstrates the installation on a VPS—his recommendation over hosting on local hardware, for reasons worth examining. "Your home lab basically becomes a single point of failure for any kind of network connectivity," he explains. If the server dies or your home internet drops, you lose access to the platform entirely. A small VPS costs maybe $5/month and removes your home infrastructure from the critical path.

The installation itself is now a one-liner script. You provide a domain name, choose whether to enable the built-in Traefik reverse proxy (recommended for automatic TLS), enter an email for Let's Encrypt notifications, and let it run. What you get is a single NetBird server container with embedded authentication, signal relay, and STUN services. No external identity provider unless you want one—Authentik, Keycloak, Entra ID, and Okta are all supported but optional.

The old Docker Compose file had six or seven distinct services. The new one has three: the NetBird server, a web dashboard, and the optional proxy. Upgrades are now just pulling new images and recreating containers.

Routing Peers and the New Networks Model

NetBird replaced its legacy "network routes" feature with something called Networks. The practical difference: you can now access internal resources without installing the NetBird client on every device.

Lempa walks through setting up a "routing peer"—essentially a gateway device that sits inside your local network with the NetBird client installed. When your laptop connects to NetBird from outside and wants to reach an internal server that doesn't have the client, the routing peer receives the connection and forwards the traffic.

He runs the routing peer as a Docker container on a local server, which keeps the installation isolated. When the container is deleted, there's no client software left behind. For high availability, you can attach multiple routing peers to a network. If one fails, devices automatically fail over to another active peer.

The access control is granular. When Lempa creates a resource for his Proxmox server, he can specify that only his MacBook Air can access it, and only on TCP port 8006—the web management interface. SSH connections get blocked even though they're technically possible. "This way you can very granularly define who has access to what type of resources and secure the entire network," he notes.

There are also posture checks—features that restrict network access if client devices don't meet certain requirements. Outdated operating systems, old NetBird client versions, missing security patches. It's enterprise-grade device compliance for self-hosted infrastructure.

The Reverse Proxy Capability

This is the feature that closed the gap with tools like Cloudflare Tunnels and Tailscale Funnel. You can now expose internal services to the public internet through NetBird without requiring the person accessing them to install a VPN client.

Lempa calls it "the one feature that made me want to make this video" because it was NetBird's main limitation compared to competitors. The reverse proxy is still in beta, but he reports it's been working reliably in testing.

The use case is straightforward: administrative services stay behind NetBird's VPN with full authentication and policy checks. But if you want to share an internal web app with external clients or partners who won't install client software, you create it as a public service instead of a protected resource.

The wildcard DNS setup matters here. Lempa configured *.netbird.servertest7.cloud.creative.de to point to his VPS's public IP. When he creates a new public service, the subdomain automatically resolves correctly without manual DNS changes for each one.

What's Missing From This Picture

What Lempa doesn't discuss—because it's outside his scope—is NetBird's security model under stress. A routing peer is a single point of compromise. If that container or host is breached, an attacker gains a tunnel into your internal network with whatever permissions that peer has been granted. The granular access controls help limit blast radius, but the architecture inherently trusts the routing peer.

NetBird uses WireGuard under the hood, which is cryptographically solid. But WireGuard doesn't provide authentication beyond key exchange. NetBird's embedded auth server handles that layer. For small homelab deployments with username/password auth, you're trusting that implementation. Organizations with compliance requirements will likely plug in an external IDP with MFA support.

The public reverse proxy feature also warrants careful thought. You're exposing internal services to the internet through a beta feature. TLS is automatic via Traefik and Let's Encrypt, but you're still creating an internet-accessible path to something that previously lived only on your LAN. The security model shifts from "completely unreachable" to "reachable with proper authentication." That's often the right trade-off, but it needs to be a conscious choice.

The Simplification Trade-Off

NetBird's cloud platform is free for up to five users, which would cover many personal and small team use cases without self-hosting anything. The self-hosted option exists for people who want infrastructure control or need to meet specific data residency requirements.

What NetBird has done with this rebuild is reduce the operational burden of self-hosting to something actually manageable. One service instead of six. Embedded authentication instead of managing a separate IDP. Built-in reverse proxy instead of configuring Nginx or Caddy separately. The minimum viable system requirements are one CPU core, 2GB RAM, and three open ports.

The interesting question is whether simplification at this scale costs flexibility. The old multi-service architecture was complex, but it was also modular. You could swap components, scale pieces independently, or integrate different identity providers more easily. The new monolithic server is simpler to deploy and maintain, but you're accepting NetBird's architectural decisions wholesale.

For homelab users and small teams, that trade-off probably works. The cognitive overhead of managing six interconnected services doesn't scale down well. For larger deployments or organizations with existing identity infrastructure, the external IDP support preserves enough flexibility to integrate properly.

Lempa's tutorial is admirably thorough—30 minutes walking through installation, configuration, client setup, resource policies, and the new reverse proxy. What makes it valuable isn't just the how-to steps, but the architectural explanations. Why use a VPS instead of local hardware. Why routing peers matter. Why the access control granularity exists. Understanding the model makes troubleshooting possible when something inevitably breaks.

NetBird isn't the only solution in this space. Tailscale has massive mindshare and arguably smoother UX. Cloudflare Tunnels are dead simple for basic web service exposure. Headscale exists if you want Tailscale's protocol without their coordination server. The landscape is crowded because the problem is real: secure remote access shouldn't require a networking degree, but it usually does.

What NetBird has done is remove enough complexity to make self-hosted remote access genuinely approachable while keeping enough power to handle real access control requirements. Whether that's the right trade-off depends entirely on your threat model and how much you trust NetBird's specific implementation choices. But for people who want infrastructure control without infrastructure complexity, this rebuild is solving a legitimate problem.

Rachel "Rach" Kovacs is Buzzrag's cybersecurity and privacy correspondent.