Compare · vs NetBird
An open-source mesh built for humans. Beacons is a from-scratch replacement for agents and humans both.
Beacons was originally scoped as a NetBird fork. We attempted the fork in early 2026, evaluated it honestly, and abandoned it. NetBird is a well-engineered product, but its identity model, multi-tenancy posture, and ACL system were built for human users on a small number of devices. Forcing it to serve autonomous organizations was a structural mismatch — not a feature gap. This page is the audit trail of that decision.
Why we tried the fork first
NetBird is open-source, written in Go, with a thoughtful control plane and a clean WireGuard implementation. It has a healthy community and reasonable defaults.
When we needed agent-native mesh networking, the first instinct was the right one: build on prior art. The NetBird-fork plan in the legacy `ARCHITECTURE.md` and `OVERVIEW.md` documents in this repository describes exactly that approach. Those documents are now annotated as deprecated and retained as the audit trail.
Why the fork did not work
NetBird's identity is rooted at a human user via OIDC, with setup keys as the credential a device presents to join. Replacing this with `did:oas` lineage was not a feature addition — it required rewriting the join model, the ACL model, the user model, the multi-tenancy posture, and the audit trail. Every layer that touched identity had to be re-derived.
NetBird's ACL model is hand-authored. The Beacons requirement is policy-derived. Bolting on a policy engine that fed NetBird hand-authored rules from governance would have given the wrong abstraction in the wrong place — every change to the governance would have required regenerating and pushing rules through a layer that didn't understand the dependencies.
Multi-tenancy in NetBird is bolted on. The Beacons requirement is for tenancy at the data-plane level. Adding that to NetBird would have required touching every storage interface, every API surface, every audit log entry — at which point we were not forking NetBird, we were writing Beacons.
What we kept
A reasonable engineering intuition that WireGuard + a control plane is the right starting point on Tier 1 hosts. The Beacons coordinator looks structurally similar to NetBird's management server in that regard.
Respect for the open-source posture. Beacons is open core (MIT/Apache-2.0), self-hostable, with commercial managed-control-plane features.
If NetBird already works for you
Keep using it. It is good software, and the team behind it is thoughtful. Beacons is not trying to replace NetBird for human-first deployments — it is trying to be correct for agent-native deployments, which is a different problem.