Self-Hosted Overlay Networks: ZeroTier vs Nebula vs Netmaker Complete Guide 2026

Connecting servers, laptops, and IoT devices across the internet as if they were on the same local network used to require complex VPN setups, port forwarding, and static IPs. In 2026, overlay network technologies make this trivial — but most people still rely on centralized, proprietary services that can see your network topology, throttle your bandwidth, or shut down without warning.

This guide covers the three leading open-source overlay network platforms you can self-host: ZeroTier (via the open-source controller), Nebula, and Netmaker. Each takes a fundamentally different architectural approach to solving the same problem — creating secure, encrypted, peer-to-peer virtual networks that span the globe.

Why Self-Host Your Overlay Network?

Overlay networks (also called SD-WAN, mesh VPN, or virtual LAN solutions) let you connect devices across the internet as if they share the same subnet. Commercial services like Tailscale and the hosted ZeroTier platform make this easy, but come with trade-offs:

• Centralized control plane — The service provider sees every device on your network, its IP, and when it connects
• Device and user limits — Free tiers cap at 25–100 devices; enterprise plans cost per-user
• Vendor lock-in — Your network identity and configuration live on someone else’s servers
• Potential downtime — If the control plane goes down, new connections can’t be established
• Data sovereignty — For regulated industries, routing metadata through third-party infrastructure is unacceptable

Self-hosting flips the model:

• Full control — You run the control plane. No one else sees your topology
• No limits — Connect thousands of nodes without per-device fees
• Resilience — Your control plane runs on infrastructure you choose and manage
• Compliance — Metadata never leaves your environment
• Customization — Integrate with existing identity providers, set custom routing rules, and build the topology you need

Whether you’re running a homelab across multiple locations, connecting branch offices, managing IoT sensors in the field, or building a zero-trust infrastructure, self-hosted overlay networks give you the connectivity without the compromise.

The Contenders at a Glance

Architecture Deep Dive

ZeroTier: Software-Defined Networking

ZeroTier uses a centralized controller model. When a node joins a network, it authenticates with the controller, receives a virtual IP, and learns about other nodes. The controller facilitates the initial handshake, but data traffic flows directly peer-to-peer using NAT hole-punching. If a direct connection isn’t possible, traffic routes through relay nodes.

The controller assigns virtual IPs from a private range and distributes a network configuration that includes routing rules, DNS settings, and flow rules (a declarative language for traffic filtering). Nodes maintain persistent connections to each other, and the controller only needs to be reachable during initial join and topology changes.

ZeroTier’s root servers (13 publicly operated servers) handle initial bootstrap and act as relays, but you can deploy your own root server or moon for complete independence.

Nebula: Decentralized Mesh with Lighthouses

Nebula takes a fundamentally different approach. There is no central authority. Instead, you define a certificate authority (CA) that signs node certificates. Each node has a certificate that identifies it and declares which groups it belongs to.

Lighthouse nodes are special Nebula nodes with public IP addresses. They act as directory services — nodes register their public IP with lighthouses, and lighthouses help peers discover each other. But lighthouses don’t relay traffic (unless configured to). Once two nodes know each other’s addresses, they communicate directly.

Nebula’s security model is certificate-based: every packet is authenticated against the sender’s certificate, and firewall rules can reference certificate groups rather than IP addresses. This means access control follows identity, not network position.

Slack uses Nebula internally for its global infrastructure, demonstrating its production readiness at scale.

Netmaker: WireGuard Orchestration

Netmaker builds on WireGuard — the modern, kernel-level VPN protocol — and adds a management layer on top. WireGuard itself is intentionally simple: you configure peers by exchanging public keys and endpoint addresses. There’s no built-in discovery, dynamic IP assignment, or user management.

Netmaker fills these gaps with:

• Automatic key and config generation — Nodes get WireGuard configs generated and pushed automatically
• User management with SSO — OAuth/OIDC integration for team-based access
• Web dashboard — Visual network management, monitoring, and troubleshooting
• DNS resolution — Nodes can resolve each other by name
• Ingress/Egress gateways — Route traffic between WireGuard networks and external networks
• Relay servers — Fallback routing when direct peering fails

The trade-off: Netmaker depends on WireGuard, which means it inherits WireGuard’s strengths (simplicity, performance, kernel integration) but also its limitations (static peer configs require regeneration when topology changes, no built-in roaming support without the management layer).

Docker Deployment: ZeroTier Controller

ZeroTier’s controller is straightforward to self-host. The official Docker image includes both the zerotier-one service and the HTTP API controller.

Prerequisites

• A server with a public IP and open UDP port 9993
• Docker and Docker Compose installed

Docker Compose Setup

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

version: "3.8"

services:
  zerotier-controller:
    image: zerotier/zerotier:latest
    container_name: zerotier-controller
    restart: unless-stopped
    network_mode: host
    volumes:
      - zt-controller-data:/var/lib/zerotier-one
    environment:
      - ZT_OVERRIDE_LOCAL_CONF=true
      - ZT_ALLOW_TCP_RELAY_FALLBACK=true

  zerotier-moon:
    image: zerotier/zerotier:latest
    container_name: zerotier-moon
    restart: unless-stopped
    network_mode: host
    volumes:
      - zt-moon-data:/var/lib/zerotier-one
    command: >
      sh -c "
        zerotier-idtool initmoon identity.public > /var/lib/zerotier-one/moon.json &&
        zerotier-idtool genmoon /var/lib/zerotier-one/moon.json > /var/lib/zerotier-one/moon.d/000000.moon &&
        exec zerotier-one
      "

volumes:
  zt-controller-data:
  zt-moon-data:

Creating Your First Network

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

# Get the controller auth token
CONTROLLER_TOKEN=$(docker exec zerotier-controller cat /var/lib/zerotier-one/authtoken.secret)

# Create a new network
curl -s -X POST "http://localhost:9993/controller/network" \
  -H "X-ZT1-AUTH: $CONTROLLER_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"name": "homelab", "ipAssignmentPools": [{"ipRangeStart": "10.147.20.1", "ipRangeEnd": "10.147.20.254"}], "routes": [{"target": "10.147.20.0/24"}]}'

# List your networks to get the network ID
curl -s "http://localhost:9993/controller/network" \
  -H "X-ZT1-AUTH: $CONTROLLER_TOKEN" | jq '.[].id'

Joining a Node

On each client machine:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

# Install ZeroTier
curl -s https://install.zerotier.com | sudo bash

# Join your network
sudo zerotier-cli join <NETWORK_ID>

# Authorize the node on the controller (or use the web UI)
curl -s -X POST "http://localhost:9993/controller/network/<NETWORK_ID>/member/<NODE_ID>" \
  -H "X-ZT1-AUTH: $CONTROLLER_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"authorized": true}'

# Verify connection
sudo zerotier-cli listnetworks

Adding a Moon (Optional but Recommended)

A Moon is a ZeroTier root server you control. It accelerates peer discovery and provides a relay fallback without relying on ZeroTier’s public root servers.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

# On the moon server, generate moon definition
zerotier-idtool initmoon identity.public > moon.json
zerotier-idtool genmoon moon.json

# Move the generated .moon file to the moon.d directory
mkdir -p /var/lib/zerotier-one/moon.d
mv *.moon /var/lib/zerotier-one/moon.d/

# On each client, orbit the moon
sudo zerotier-cli orbit <MOON_WORLD_ID> <MOON_WORLD_ID>

Docker Deployment: Nebula

Nebula’s simplicity is its greatest strength. A single binary handles everything — the CA, the lighthouse, and the client nodes.

Step 1: Generate Your CA

1
2
3
4
5
6

# Download Nebula
curl -Lo nebula-linux-amd64.tar.gz https://github.com/slackhq/nebula/releases/latest/download/nebula-linux-amd64.tar.gz
tar xzf nebula-linux-amd64.tar.gz

# Generate the certificate authority
./nebula-cert ca -name "My Organization"

This creates two files:

• ca.crt — The public certificate (distribute to all nodes)
• ca.key — The private key (keep this secure — it signs all node certificates)

Step 2: Create Lighthouse and Node Certificates

1
2
3
4
5
6
7
8

# Lighthouse certificate (public IP: 203.0.113.10)
./nebula-cert sign -name "lighthouse1" -ip "192.168.100.1/24"

# Server node certificate
./nebula-cert sign -name "server1" -ip "192.168.100.2/24" -groups "servers,production"

# Laptop node certificate
./nebula-cert sign -name "laptop1" -ip "192.168.100.10/24" -groups "laptops"

Step 3: Configure the Lighthouse (Docker)

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

version: "3.8"

services:
  nebula-lighthouse:
    image: slackerdn/nebula:latest
    container_name: nebula-lighthouse
    restart: unless-stopped
    network_mode: host
    cap_add:
      - NET_ADMIN
    volumes:
      - ./lighthouse-config:/etc/nebula
    command: -config /etc/nebula/config.yml

lighthouse-config/config.yml:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

pki:
  ca: /etc/nebula/ca.crt
  cert: /etc/nebula/lighthouse1.crt
  key: /etc/nebula/lighthouse1.key

static_host_map:
  "192.168.100.1": ["203.0.113.10:4242"]

lighthouse:
  am_lighthouse: true

listen:
  host: 0.0.0.0
  port: 4242

firewall:
  outbound:
    - port: any
      proto: any
      host: any
  inbound:
    - port: any
      proto: any
      host: any

Step 4: Configure a Client Node

node-config/config.yml:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

pki:
  ca: /etc/nebula/ca.crt
  cert: /etc/nebula/server1.crt
  key: /etc/nebula/server1.key

static_host_map:
  "192.168.100.1": ["203.0.113.10:4242"]

lighthouse:
  am_lighthouse: false
  hosts:
    - "192.168.100.1"

listen:
  host: 0.0.0.0
  port: 4242

firewall:
  outbound:
    - port: any
      proto: any
      host: any
  inbound:
    - port: 22
      proto: tcp
      host: any
    - port: 443
      proto: tcp
      host: any
    - port: any
      proto: icmp
      host: any

1
2
3
4
5
6
7
8
9

# Start the node
docker run -d --name nebula-node \
  --network host --cap-add NET_ADMIN \
  -v $(pwd)/node-config:/etc/nebula \
  --restart unless-stopped \
  slackerdn/nebula:latest -config /etc/nebula/config.yml

# Verify the tunnel
ping 192.168.100.1  # Should reach the lighthouse

Nebula Firewall Rules in Action

Nebula’s firewall is group-aware. A rule like this on the lighthouse:

1
2
3
4
5
6

firewall:
  inbound:
    - port: 22
      proto: tcp
      groups:
        - servers

Allows SSH access only to nodes with the servers group, regardless of their IP address. This is identity-based access control that follows the node wherever it connects from.

Docker Deployment: Netmaker

Netmaker is the most feature-rich option but also the most complex to deploy. It includes a full web UI, user management, SSO, and DNS — all managed through a unified interface.

Docker Compose Setup

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76

version: "3.8"

services:
  netmaker:
    image: gravitl/netmaker:v0.26.0
    container_name: netmaker
    restart: unless-stopped
    ports:
      - "8081:8081"   # API
      - "51821:51821/udp"  # WireGuard
      - "50051:50051"   # gRPC
      - "8080:8080"     # Dashboard (via proxy)
    environment:
      - SERVER_HTTP_PORT=8081
      - GRPC_SERVER=0.0.0.0:50051
      - MASTER_KEY=your-master-key-here
      - CORS_ALLOWED_ORIGIN=*
      - DATABASE=postgresql
      - DB_HOST=nm-postgres
      - DB_PORT=5432
      - DB_USER=netmaker
      - DB_PASSWORD=nm-postgres-password
      - DB_NAME=netmaker
      - STUN_LIST=stun1.l.google.com:19302,stun2.l.google.com:19302
      - NODE_ID=auto
    volumes:
      - /etc/netclient:/etc/netmaker
      - dnsconfig:/root/config
    depends_on:
      postgres:
        condition: service_healthy
      mq:
        condition: service_started

  postgres:
    image: postgres:16-alpine
    container_name: nm-postgres
    restart: unless-stopped
    environment:
      - POSTGRES_PASSWORD=nm-postgres-password
      - POSTGRES_USER=netmaker
      - POSTGRES_DB=netmaker
    volumes:
      - nm-db-data:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U netmaker"]
      interval: 5s
      timeout: 5s
      retries: 5

  mq:
    image: eclipse-mosquitto:2
    container_name: nm-mq
    restart: unless-stopped
    volumes:
      - ./mosquitto.conf:/mosquitto/config/mosquitto.conf

  caddy:
    image: caddy:2
    container_name: nm-caddy
    restart: unless-stopped
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./Caddyfile:/etc/caddy/Caddyfile
      - caddy-data:/data
      - caddy-config:/config
    depends_on:
      - netmaker

volumes:
  nm-db-data:
  dnsconfig:
  caddy-data:
  caddy-config:

Caddyfile for automatic TLS:

1
2
3
4
5
6

netmaker.example.com {
    reverse_proxy netmaker:8081
}
dashboard.example.com {
    reverse_proxy netmaker:8080
}

Initial Setup

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

# Start the stack
docker compose up -d

# Create the admin user via the web UI at https://dashboard.example.com
# Or via API:
curl -X POST "https://netmaker.example.com/api/users" \
  -H "Content-Type: application/json" \
  -d '{"username": "admin", "password": "secure-password"}'

# Create your first network through the dashboard or API
curl -X POST "https://netmaker.example.com/api/networks" \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer <TOKEN>" \
  -d '{"network": {"netid": "homelab", "address": "10.100.0.0/16"}}'

Joining a Node

Netmaker uses netclient — a lightweight agent that handles WireGuard configuration automatically.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

# Download netclient
curl -Lo /usr/local/bin/netclient https://github.com/gravitl/netmaker/releases/latest/download/netclient-linux-amd64
chmod +x /usr/local/bin/netclient

# Join the network
netclient join -t <INVITE_TOKEN> -s https://netmaker.example.com

# The agent automatically:
# 1. Generates WireGuard keys
# 2. Registers with the Netmaker server
# 3. Receives the WireGuard config
# 4. Brings up the wg0 interface
# 5. Sets up DNS resolution

# Verify
netclient list
ip addr show wg-homelab

Head-to-Head Comparison

Ease of Deployment

ZeroTier wins on simplicity. Nebula requires understanding certificates and groups. Netmaker has the most moving parts but rewards you with a polished management experience.

Performance and Resource Usage

Netmaker’s WireGuard foundation gives it the performance edge — WireGuard runs in kernel space with minimal overhead. ZeroTier and Nebula run in userspace, adding a small penalty but offering more flexibility.

Security Model

Nebula has the strongest zero-trust story — every packet is authenticated against a certificate, and firewall rules follow identity, not IP address. Netmaker’s SSO integration and role-based access make it ideal for teams. ZeroTier’s flow rules are powerful but require learning a custom language.

Multi-Site and Subnet Routing

All three support subnet routing, but the approaches differ:

1
2
3

Office A (192.168.1.0/24) ──┐
                              ├── Overlay Network ── Office B (192.168.2.0/24)
Home Server (10.0.0.0/24) ──┘

ZeroTier: Declare routes in the network config. Nodes with --allow-default can advertise local subnets. The controller distributes routes to all members.

Nebula: Use lighthouse nodes as routers. Configure unsafe_routes in the client config to announce subnets. Firewall rules control which groups can access which subnets.

Netmaker: Designate nodes as “ingress” or “egress” gateways. The UI makes subnet routing a checkbox operation. DNS resolution works across subnets automatically.

Production Readiness

Common Pitfalls and Solutions

NAT Traversal Failures

All three tools use UDP hole-punching to establish direct connections. On symmetric NATs (common in corporate networks), this can fail.

ZeroTier: Deploy a Moon server with a public IP. Nodes will use it as a relay fallback.

1

zerotier-cli orbit <MOON_ID> <MOON_ID>

Nebula: Ensure at least one lighthouse has a public IP. Configure static_host_map with the lighthouse’s public address.

Netmaker: Configure a relay node with a public IP. Netmaker automatically routes through relays when direct peering fails.

Certificate Rotation (Nebula)

Nebula certificates don’t expire by default. When you need to rotate them:

1
2
3
4
5
6
7
8
9

# Generate new certificates with the CA
./nebula-cert sign -name "server1" -ip "192.168.100.2/24" -groups "servers"

# Replace the cert and key on the node
scp server1.crt node:/etc/nebula/
scp server1.key node:/etc/nebula/

# Restart the nebula process (no IP change needed)
systemctl restart nebula

Network Recovery After Controller Downtime

ZeroTier: Nodes maintain peer connections even if the controller goes down. New nodes can’t join, and IP assignments won’t update, but existing connections persist.

Nebula: Fully decentralized after bootstrapping. Lighthouse downtime means new nodes can’t discover peers, but existing connections continue uninterrupted.

Netmaker: If the Netmaker server goes down, existing WireGuard connections persist. The netclient agent caches its configuration locally. New enrollments and config updates are blocked until the server recovers.

Migration Paths

From Tailscale to Self-Hosted

If you’re currently using Tailscale and want to self-host:

1. Netmaker is the closest drop-in replacement — same WireGuard foundation, similar feature set (DNS, subnet routing, user management)
2. Install netclient on each node alongside the Tailscale client
3. Create equivalent networks and subnets in Netmaker
4. Update DNS and routing configurations
5. Decommission Tailscale clients once migration is verified

From OpenVPN/WireGuard Manual Setup

If you’re managing individual WireGuard configs:

1. Netmaker will automate your existing WireGuard setup — import existing keys, let it manage peer discovery and DNS
2. ZeroTier requires a fresh network — you’ll need to reassign IPs and reconfigure services to use the new virtual network
3. Nebula is ideal if you want certificate-based identity — migrate one node at a time, verify connectivity, then switch over

Cost Comparison

Assuming 50 nodes across 3 sites:

Self-hosting saves $480–660 per year for 50 nodes, with the added benefit of full control and no vendor lock-in.

Verdict: Which Should You Choose?

Choose ZeroTier if you want the simplest path to a working overlay network. The controller is easy to deploy, the client is available for every platform, and NAT traversal just works. It’s the best choice for homelab users and small teams who need connectivity without complexity.

Choose Nebula if you need zero-trust, certificate-based security with minimal infrastructure. Nebula’s group-based firewall rules and decentralized architecture make it ideal for security-conscious deployments. The lack of a web UI is its biggest drawback, but the CLI is straightforward and automation-friendly.

Choose Netmaker if you’re replacing Tailscale or need a team-friendly platform with a web dashboard, SSO, DNS, and the performance of WireGuard. It has the steepest initial setup but the most complete feature set for production environments.

All three are production-ready, open-source, and free to run. The best choice depends on your team size, security requirements, and tolerance for operational complexity. For most homelab users starting out, ZeroTier offers the fastest path to a working network. For enterprise deployments, Nebula’s identity-based security or Netmaker’s management features will serve you better.

Frequently Asked Questions (FAQ)

Which one should I choose in 2026?

The best choice depends on your specific requirements:

• For beginners: Start with the simplest option that covers your core use case
• For production: Choose the solution with the most active community and documentation
• For teams: Look for collaboration features and user management
• For privacy: Prefer fully open-source, self-hosted options with no telemetry

Refer to the comparison table above for detailed feature breakdowns.

Can I migrate between these tools?

Most tools support data import/export. Always:

1. Backup your current data
2. Test the migration on a staging environment
3. Check official migration guides in the documentation

Are there free versions available?

All tools in this guide offer free, open-source editions. Some also provide paid plans with additional features, priority support, or managed hosting.

How do I get started?

1. Review the comparison table to identify your requirements
2. Visit the official documentation (links provided above)
3. Start with a Docker Compose setup for easy testing
4. Join the community forums for troubleshooting