Nebula: Slack’s overlay VPN explained
Actualizado: 2026-05-03
Nebula has been around for six years, released by Slack in 2019 as an internal tool to connect their distributed fleet, and yet remains much less known than WireGuard or Tailscale. This is surprising because its design neatly solves a specific problem: connecting hundreds or thousands of nodes in a mesh, each with its own cryptographic identity, without relying on a central server that encrypts and decrypts all traffic.
The point here isn’t an installation tutorial (official documentation is clear) but to understand how it’s built, compare it with popular alternatives, and share what I learned in practice.
Key takeaways
- Nebula builds a minimal control plane (lighthouses for discovery) and a fully meshed data plane: real traffic flows directly between nodes, not through the lighthouse.
- It brings its own PKI: each node has a certificate signed by a local CA, with the IP and groups embedded, enabling expressive firewall rules and clean revocation.
- It’s the natural choice when you want a large self-hosted mesh without depending on a SaaS: Nebula does what WireGuard doesn’t scale to natively and what Tailscale does with SaaS.
- The CA is the critical link: it must live outside the network, never on the same lighthouse node.
- Lighthouses should be redundant: if the only one falls, new nodes can’t reconnect.
Architecture: lighthouses and mesh
Nebula builds a minimal control plane and a fully meshed data plane. Nodes find each other through a discovery system called a lighthouse: one or more designated nodes tracking each peer’s public addresses. When a new node wants to talk to another, it asks the lighthouse where to find it and then establishes a direct point-to-point connection.
The key is that connection doesn’t pass through the lighthouse. It only facilitates initial discovery and occasionally helps with NAT traversal, but real traffic flows directly between the two nodes. On a ten-node network it doesn’t matter; on a five-hundred-node network the difference is enormous in latency and infrastructure cost.
Encryption uses modern elliptic curves (Curve25519 for key exchange, AES-GCM or ChaCha20-Poly1305 for data) and the handshake is built on the Noise Protocol Framework, the same underlying scheme WireGuard and Signal use. Cryptographic security is solid and reasonably audited.
Own PKI and identity signing
An important difference from WireGuard is that Nebula brings its own PKI. Each node has a certificate signed by a local CA, and that certificate embeds:
- The IP the node will have inside the VPN.
- The groups it belongs to (arbitrary labels: “db”, “web”, “monitoring”).
Groups are used to define distributed firewall rules. Example: “nodes in the web group can talk to those in the db group on port 3306, no one else can.”
Three practical consequences:
- IP assignment is deterministic and centralized in the certificate signing; no DHCP inside the VPN.
- The internal firewall can express much more expressive policies than a simple IP range.
- Revoking a compromised node happens by adding it to a revocation list the lighthouses distribute.
The downside is that adding a new node requires signing a certificate with the CA — an administrative step WireGuard doesn’t have. The upside is that cryptographic identity and network identity are bound.
Comparison with WireGuard and Tailscale
WireGuard is simpler to deploy and its Linux-kernel integration is impeccable. If you need to connect two or three nodes, or a remote workforce to an internal network, WireGuard is almost always the right choice.
Where WireGuard loses is at scale. Connecting fifty nodes in a full mesh requires generating fifty configurations each listing the other forty-nine peers, and updating them every time something changes.
Tailscale solves the mesh problem with a centralized control plane as a hosted service, with a pleasant UI and features like MagicDNS and declarative ACLs. The cost is the Tailscale service dependency.
Nebula sits at an intermediate point: self-hostable like WireGuard, but designed from the start for meshes with discovery. It lacks Tailscale’s UI and niceties, but also lacks WireGuard’s operational cost at scale. It’s the natural choice when you want a large mesh VPN without relying on an external provider.
What I learned deploying it
Several details the documentation mentions but you only appreciate in production:
-
The PKI is your critical link. The CA’s private key must live somewhere outside the network, because whoever has access can sign arbitrary certificates and enter the network as any node. I’ve seen setups where the CA lived on the same lighthouse routing traffic: a clear antipattern.
-
Lighthouses should be redundant. If the only lighthouse falls, already-connected nodes keep talking, but new nodes or those losing their peer table won’t reconnect. Having at least two in distinct geographic zones is sensible, configured as a list on end nodes.
-
Nebula’s embedded firewall is powerful but requires discipline. Rules are defined in each node’s config and must stay consistent. For large networks, generate those rules from a common source (Terraform, Ansible, a script) rather than editing each machine by hand.
-
Docker and Kubernetes integration works but has nuances. In Kubernetes, projects like nebula-operator simplify management but aren’t yet at the maturity of tailscale-operator.
When Nebula is worth choosing
Nebula shines when several conditions hold at once:
- A distributed network with many nodes (dozens or hundreds) needing direct peer-to-peer talk.
- A self-hosting requirement for compliance or sovereignty reasons.
- A team capable of operating a PKI and maintaining configurations from a declarative source of truth.
- A traffic pattern where passing through a single concentrator would be a real bottleneck.
If your scenario is smaller (two offices, a ten-person remote team, a couple of servers on different clouds), pure WireGuard or Tailscale probably fit better. Nebula’s trick is solving the large-intermediate case well without depending on a SaaS, and that’s where it has no direct competition.
The project has the unglamorous virtue of not wanting to be everything for everyone: it does one thing, self-hosted mesh, and does it well. That clarity of scope is why I chose it for the network I migrated this month.
