Nebula

Last reviewed Aug 26, 2026 · 925 words

Nebula asks you to run a certificate authority, and everything else about it follows from whether you are willing to. There is no coordination server, no account, no company in the loop: each host gets a certificate signed by your CA, and any two hosts with valid certificates can find each other through a "lighthouse" you also run and talk directly over encrypted UDP. That is more self-hosted than Tailscale, whose control plane is Tailscale's, and more work than Tailscale by a wide margin. The catalogue's "manual certificate management" and "no management GUI" are not minor cons; they are the product's shape.

The mental model: CA, lighthouse, hosts

Three roles. The CA is a key pair you generate once and keep offline. A lighthouse is any host with a public IP whose only special job is to tell other hosts where their peers currently are; a 5 dollar VPS is the usual choice. Every other host is just a host. Traffic does not route through the lighthouse; once two peers have learned each other's addresses, they hole-punch and talk directly, and the lighthouse only sees metadata. Every host carries its own certificate, which encodes its overlay IP, its name and a set of groups such as servers or laptops. Those groups are what the firewall rules match on.

Bootstrapping a three-node network is short enough to show in full:

nebula-cert ca -name "home"
nebula-cert sign -name lighthouse -ip 10.42.0.1/24
nebula-cert sign -name nas -ip 10.42.0.10/24 -groups servers
nebula-cert sign -name laptop -ip 10.42.0.20/24 -groups laptops

Each host then gets ca.crt, its own .crt and .key, and a config.yml naming the lighthouse's public address. Nebula listens on UDP 4242 by default, and that is the only port the lighthouse needs open. Start nebula -config config.yml on each machine and the overlay is up.

The firewall lives in the certificate, not on the host

This is the feature that makes Nebula worth the trouble. The firewall section of each host's config.yml allows traffic by group, port and protocol, and because group membership is signed into the certificate, a host cannot claim a group it was not issued:

firewall:
  outbound:
    - port: any
      proto: any
      host: any
  inbound:
    - port: 22
      proto: tcp
      group: laptops
    - port: 445
      proto: tcp
      group: laptops

That NAS now accepts SSH and SMB only from hosts holding a laptops certificate, and nothing from servers, regardless of what the operating system firewall says. Tailscale's ACLs achieve the same result from a central policy file; Nebula does it per host with no central policy to compromise. For a network with a handful of trust tiers, this is the cleanest expression of "who may talk to whom" I have used.

What you pay for the independence

Certificates expire. nebula-cert sign takes a -duration and the default is a year less a day, so twelve months after setup every host stops talking unless you have rotated. Put it in the calendar. There is no device enrolment flow: adding a phone means generating a certificate on the CA machine, moving three files to the device, and configuring the mobile app by hand. There is no admin page showing which hosts are online; you get logs and the nebula process's own metrics endpoint. And there is no DNS magic: hosts are reachable by overlay IP unless you add a lighthouse DNS feature or run your own resolver.

Defined Networking, the company the original authors founded, sells a managed control plane that adds enrolment, a dashboard and automated rotation on top of open-source Nebula, with a free tier for small networks at last check. That is the honest answer for anyone who likes Nebula's design but not the paperwork, and it puts the project in the same position as Headscale versus Tailscale: open core, optional hosted convenience.

Where it sits against Tailscale, Headscale and NetBird

Tailscale wins on ease for almost everyone: install, log in, done, with MagicDNS and a device list for free. Headscale gives you Tailscale's client experience with your own control server and is the right answer if what bothers you is only the third-party coordinator. NetBird is the self-hosted mesh with a proper web UI. Nebula's niche is narrower: fleets where you want a static, auditable, certificate-based trust model with no control plane at all, or where the hosts are servers rather than laptops and phones and enrolment happens through configuration management anyway. At Slack's scale that was thousands of servers; in a homelab it is the person who already runs a CA for other things. The remote access category has the rest of the field, and the threat modelling guide is a useful check on whether you need this level of independence.

What I'd do

If your overlay is mostly servers, you deploy with Ansible, and you want no external dependency, run Nebula with a lighthouse on a small VPS, group-based firewall rules, certificate durations of a year, and a rotation task scheduled at month 11. If your overlay includes phones, family laptops and anything you enrol by hand, run Headscale or Tailscale and keep Nebula as the thing you admire. It is the most principled tool in the category and the least forgiving, and both of those are the same design decision.