Every device I own — laptops, phone, a couple of servers, a NAS, a pile of
Raspberry Pis — sits on one flat, private network that follows me everywhere. I'm
on the same LAN whether I'm at home or on hotel WiFi. No port forwards, no exposed
services, no VPN concentrator to log into. It's a WireGuard mesh, and it is the
single best quality-of-life change I've made to my homelab.
The obvious tool for this is Tailscale, and it's
excellent. I use NetBird instead. This post is the honest
comparison: why I chose it, exactly how it slots into the rest of my setup, the
things it made me fix along the way — and, because these posts are useless if they
only sell you the thing, where Tailscale is genuinely the better call.
What they have in common (which is most of it)
Both build a WireGuard mesh. Both give every device a stable private IP that
works from anywhere. Both punch through NAT for you, so peers connect directly
where they can and fall back to a relay only when they must. Both replace the old
model — one VPN gateway you tunnel into, then route around a network — with a
model where every device talks straight to every other device, encrypted, no
matter whose network it's sitting on.
The mental shift is the same with either: you stop thinking about "where is this
service exposed" and start thinking about "who is allowed to reach it." That's
the whole win, and both tools deliver it.
So the choice isn't about WireGuard, or performance, or the basic experience. It
comes down to one thing.
The one reason: the control plane, and who runs it
A WireGuard mesh needs a coordination server — the thing that knows which
peers exist, hands out keys, and tells everyone how to find everyone else. The
data (your actual traffic) is peer-to-peer and end-to-end encrypted either way.
But that control plane is the brain, and the difference between these two products
is who runs it.
- Tailscale: the coordination server is Tailscale's, hosted by them, and it's proprietary. You can self-host an alternative — Headscale, a community reimplementation — but that's a separate open-source project playing catch-up with a moving target, not the product Tailscale ships.
- NetBird: the entire stack, control plane included, is open source, and it's designed to be self-hosted. I run the brain myself.
For me that was decisive, and not for ideology. It's this: I already run an
identity provider, and I wanted my VPN to be my single sign-on, not a second
account system bolted next to it.
NetBird speaks OIDC to my existing self-hosted identity provider. So logging into
the mesh is logging into everything else — same username, same 2FA, same place
to revoke a person. When I offboard a device or a user, I do it in one identity
system and it's gone from the VPN too. There's no second control plane, run by
someone else, holding a second copy of "who's allowed on my network." The list of
who can reach my machines lives in the same system as every other access decision
I make. That's the property I wanted, and it's the one Tailscale's hosted model
can't give me without handing the brain to a third party.
How it actually fits into the rest of my setup
The mesh isn't a standalone thing; it's load-bearing for how the whole estate
hangs together.
It's how internal names resolve away from home. Some of my services are
deliberately LAN-only — they're not on the public internet at all. On the mesh,
peers can still resolve and reach them by name, so my dashboard and my home
automation are one hostname away whether I'm on the sofa or on a train, without
any of it being exposed to the outside world. The VPN is the only door, and the
door is identity-gated.
It's the private path between my two sites. Machines in different physical
locations sit on the same overlay and talk to each other directly, as if they
were in the same rack. No site-to-site tunnel to hand-configure, no static
routes.
It layers cleanly with the rest of the security model. Public services go
through a reverse proxy and the identity provider at the edge. Private services
skip all that and are reachable only over the mesh. Two paths, one identity system
governing both. Nothing internal is one misconfigured firewall rule away from the
internet, because it was never on the internet to begin with.
The parts that didn't just work
In the spirit of the rest of these writeups — here's what cost me time, because
the tidy version above skips the evening I spent confused.
The token format gotcha. Wiring NetBird to my identity provider, the dashboard
authenticated fine but API calls failed. The cause: my IdP was handing out
opaque access tokens, and NetBird's dashboard needed a JWT it could
actually read claims from. The fix was one setting — telling the dashboard to use
the ID token as its token source rather than the opaque access token. Obvious in
hindsight, invisible while it's happening: login worked, so I looked everywhere
except the token format. (This is the recurring theme of my whole homelab: when
two auth systems are wired together, the failure is almost always at the seam
between them, and it never announces itself as "the seam is wrong.")
Split-horizon DNS will lie to you. A name that resolves over the mesh does
not automatically resolve the same way for a device on the home LAN, and vice
versa. I had a service that was reachable by name from a phone on cellular (over
the mesh) but "down" from a laptop on the home WiFi — because the two were
resolving the same hostname differently. The lesson I keep relearning: when
something is reachable from one network and not another, check what each client's
resolver actually returns before you touch anything else.
Self-hosting the control plane is a real responsibility. This is the honest
cost of the thing I picked it for: the brain is now mine to keep alive, patch,
and back up. If my coordination server is down when I'm away and a peer's
connection drops, re-establishing can be a bad time. Tailscale users simply do not
have this problem — that's the trade I signed up for, eyes open.
Where Tailscale is the better choice — genuinely
I'd be doing you a disservice to pretend NetBird is strictly better. For a lot of
people, Tailscale is the right answer, and here's when I'd tell you to just use it:
- You want it to work in ten minutes and never think about it again. Tailscale is more polished, the onboarding is smoother, and MagicDNS / exit nodes / subnet routers are all beautifully turnkey. NetBird is good and improving fast, but "self-host the whole control plane and wire it to your own IdP" is not a ten-minute job, and it's not meant to be.
- You don't already run an identity provider. My entire reason for choosing NetBird is that I had an IdP and wanted the VPN to join it. If you don't have one, Tailscale's built-in identity (log in with Google/GitHub/etc.) removes a whole category of work, and pointing NetBird at an IdP you'd have to stand up first is solving a problem you don't have.
- You want the biggest community and the most battle-tested edges. Tailscale has more users, more docs, more Stack Overflow answers, more third-party integrations. When you hit something weird, someone has usually hit it first.
- You don't want to be on call for your own VPN. If the coordination server being your responsibility sounds like a downside rather than the entire point, that's a completely valid read, and Tailscale removes it.
Tailscale optimises for "it just works, run by people who do this full-time."
NetBird, for me, optimises for "I run all of it, and it joins the identity system
I already trust." Those are different goals, and only you know which one is yours.
How to actually decide
Strip it to one question:
Do you want to own the control plane, and do you have (or want) a single
identity provider for it to plug into?
- Yes to both → NetBird earns its keep. Your VPN becomes another OIDC client of the identity system you already run, and there's no second brain hosted by someone else holding the keys to your network.
- No, or "I just want it to work" → use Tailscale, or Headscale if you want self-hosting without the full NetBird stack. There's no shame in the turnkey option; for most homelabs it's the correct one.
I went the self-hosted, identity-first way because the thing I value most in this
estate is that every access decision lives in one place I control — and a VPN
whose "who's allowed" list is hosted by a third party broke that rule. NetBird let
me keep it. That's the whole reason, and everything else in this post is detail
hanging off it.
Homelab notes from someone who runs the whole mesh, including the brain, and has
debugged it from a hotel room more than once. Specifics are kept vague on purpose —
the decision framework travels; my IP ranges don't need to.
🤖 Drafted with AI assistance from my own homelab notes, logs and repos, then reviewed and edited before publishing.
Top comments (0)