NetBird mit Docker installieren: Zero-Trust-Overlay-Netzwerk selbst hosten (WireGuard + SSO)

Wer Homeoffice-Zugänge, Standortvernetzung oder Remote-Access ohne klassisches Hub-and-Spoke-VPN braucht, stößt früher oder später auf NetBird. Das Open-Source-Projekt (AGPLv3, über 25.000 GitHub-Stars) baut ein verschlüsseltes Peer-to-Peer-Overlay-Netzwerk auf WireGuard-Basis auf – ergänzt um einen zentralen Kontrollserver für SSO/OIDC-Authentifizierung, MFA, granulare Zugriffsrichtlinien (ACL) und automatische NAT-Traversal. Die selbst gehostete Variante ist eine echte Alternative zu Cloudflare Access, Tailscale oder ZeroTier, ohne dass Verbindungsdaten über fremde Server laufen. KMUs und ambitionierte Selfhoster behalten damit die volle Kontrolle über ihr Netzwerk-Overlay.

Voraussetzungen

1. Linux-Server (x86_64 oder arm64, z. B. Debian 12 / Ubuntu 24.04) mit mindestens 2 vCPU und 2 GB RAM – empfohlen 4 GB RAM für Produktivbetrieb
2. Docker Engine ≥ 24.x mit Docker Compose Plugin v2 installiert – falls noch nicht vorhanden, siehe Docker und Docker Compose auf Linux installieren
3. Öffentliche IP-Adresse und DNS-Kontrolle: ein A-Record für die gewählte Domain (z. B. netbird.example.com) muss auf die Server-IP zeigen, bevor du mit dem Setup beginnst
4. Firewall-Freigaben: Port 80/tcp (HTTP/ACME-Challenge), 443/tcp (HTTPS, alle Dienste via Traefik) und 3478/udp (STUN/TURN, direkt auf Coturn)
5. E-Mail-Adresse für Let's-Encrypt-Zertifikate
6. Optional: einen OIDC-kompatiblen Identity Provider (Zitadel, Keycloak, Authentik, Pocket ID) – oder den eingebauten Dex-basierten embedded IdP für schnellen Einstieg ohne externen IDP

Schritt 1: Projektordner anlegen und Skript ausführen

Wechsle auf deinem Server in das gewünschte Verzeichnis und erstelle einen Projektordner. Der offizielle Einstieg erfolgt über das getting-started.sh-Skript, das management.json, turnserver.conf, eine fertige docker-compose.yml und eine setup.env automatisch erzeugt.

mkdir -p /opt/netbird
cd /opt/netbird
curl -fsSL https://github.com/netbirdio/netbird/releases/latest/download/getting-started.sh -o getting-started.sh
chmod +x getting-started.sh

Schaue dir das Skript kurz an, bevor du es ausführst:

less getting-started.sh

Das Skript fragt interaktiv nach Domain, öffentlicher IP, E-Mail und IDP-Typ. Für den schnellen Einstieg wähle den eingebauten embedded IdP (Option „none" bzw. „built-in"). Nach erfolgreicher Ausführung findest du im Unterordner artifacts/ alle generierten Dateien.

sudo ./getting-started.sh

Verifizieren: Nach dem Skriptlauf sollte der Ordner /opt/netbird/artifacts/ die Dateien docker-compose.yml, management.json und turnserver.conf enthalten:

ls -la /opt/netbird/artifacts/
# Erwartete Ausgabe (gekürzt):
# -rw-r--r-- management.json
# -rw-r--r-- turnserver.conf
# -rw-r--r-- docker-compose.yml
# -rw-r--r-- setup.env

Schritt 2: .env-Datei mit Image-Tags und Secrets befüllen

Das Skript erzeugt eine setup.env. Kopiere sie als .env und ergänze gepinnte Image-Tags – für den Produktivbetrieb solltest du nie :latest verwenden, damit ungewollte Breaking-Change-Upgrades ausbleiben.

cd /opt/netbird/artifacts/
cp setup.env .env

Öffne die .env und passe die Werte an:

# === Pflichtfelder (vom Skript vorausgefüllt) ===
NETBIRD_DOMAIN=netbird.example.com
NETBIRD_TURN_EXTERNAL_IP=203.0.113.42
NETBIRD_LETSENCRYPT_EMAIL=admin@example.com

# === OIDC (embedded IdP: vom Skript gesetzt) ===
NETBIRD_AUTH_OIDC_CONFIGURATION_ENDPOINT=https://netbird.example.com/.well-known/openid-configuration
NETBIRD_AUTH_AUDIENCE=netbird
NETBIRD_AUTH_CLIENT_ID=netbird-client

# === Gepinnte Image-Tags (empfohlen für Produktion) ===
NETBIRD_DASHBOARD_TAG=v2.34.2
NETBIRD_SIGNAL_TAG=v0.66.4
NETBIRD_MANAGEMENT_TAG=v0.66.4
NETBIRD_RELAY_TAG=v0.66.4
COTURN_TAG=4.6.3

# === Optional ===
NETBIRD_STORE_CONFIG_ENGINE=sqlite
NB_LOG_LEVEL=info
NETBIRD_DISABLE_ANONYMOUS_METRICS=false

Der NETBIRD_RELAY_AUTH_SECRET wird vom Skript automatisch generiert und muss in Management und Relay identisch sein – prüfe, dass er in der .env vorhanden ist. Sollte er fehlen, generiere einen sicheren Wert:

openssl rand -hex 32

Verifizieren: Alle Pflichtfelder sind gesetzt und NETBIRD_RELAY_AUTH_SECRET ist vorhanden:

grep -E "NETBIRD_DOMAIN|NETBIRD_TURN_EXTERNAL_IP|NETBIRD_RELAY_AUTH_SECRET" .env
# Jede Zeile sollte einen nicht-leeren Wert enthalten

Schritt 3: compose.yaml überprüfen und anpassen

Das Skript erzeugt bereits eine lauffähige docker-compose.yml. Der folgende Block zeigt die vollständige Produktionskonfiguration mit Traefik v3 als Reverse Proxy – sie entspricht der aus den Recherche-Fakten verifizierten Architektur mit fünf Diensten. Passe sie bei Bedarf an oder verwende die generierte Datei direkt.

---
# NetBird Self-Hosted – compose.yaml
# Alle Variablen kommen aus .env (siehe Schritt 2)

services:

  # Traefik: Reverse Proxy mit Let's Encrypt
  traefik:
    image: traefik:v3.6
    restart: unless-stopped
    command:
      - --api.dashboard=false
      - --entrypoints.web.address=:80
      - --entrypoints.websecure.address=:443
      - --entrypoints.web.http.redirections.entryPoint.to=websecure
      - --entrypoints.web.http.redirections.entryPoint.scheme=https
      - --providers.docker=true
      - --providers.docker.exposedbydefault=false
      - --certificatesresolvers.letsencrypt.acme.email=${NETBIRD_LETSENCRYPT_EMAIL}
      - --certificatesresolvers.letsencrypt.acme.storage=/letsencrypt/acme.json
      - --certificatesresolvers.letsencrypt.acme.httpchallenge.entrypoint=web
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock:ro
      - netbird-letsencrypt:/letsencrypt
    logging:
      driver: "json-file"
      options:
        max-size: "100m"
        max-file: "2"

  # Dashboard: Web-UI
  dashboard:
    image: netbirdio/dashboard:${NETBIRD_DASHBOARD_TAG:-latest}
    restart: unless-stopped
    environment:
      - NETBIRD_MGMT_API_ENDPOINT=https://${NETBIRD_DOMAIN}
      - NETBIRD_MGMT_GRPC_API_ENDPOINT=https://${NETBIRD_DOMAIN}
      - AUTH_AUDIENCE=${NETBIRD_AUTH_AUDIENCE}
      - AUTH_CLIENT_ID=${NETBIRD_AUTH_CLIENT_ID}
      - AUTH_AUTHORITY=${NETBIRD_AUTH_OIDC_CONFIGURATION_ENDPOINT}
      - USE_AUTH0=${NETBIRD_USE_AUTH0:-false}
      - LETSENCRYPT_DOMAIN=none
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.dashboard.rule=Host(`${NETBIRD_DOMAIN}`)"
      - "traefik.http.routers.dashboard.entrypoints=websecure"
      - "traefik.http.routers.dashboard.tls.certresolver=letsencrypt"
      - "traefik.http.services.dashboard.loadbalancer.server.port=80"
    logging:
      driver: "json-file"
      options:
        max-size: "100m"
        max-file: "2"

  # Signal: WebRTC-Peer-Discovery (gRPC)
  signal:
    image: netbirdio/signal:${NETBIRD_SIGNAL_TAG:-latest}
    restart: unless-stopped
    volumes:
      - netbird-letsencrypt:/etc/letsencrypt:ro
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.signal.rule=Host(`${NETBIRD_DOMAIN}`) && PathPrefix(`/signalexchange.SignalExchange`)"
      - "traefik.http.routers.signal.entrypoints=websecure"
      - "traefik.http.routers.signal.tls.certresolver=letsencrypt"
      - "traefik.http.services.signal.loadbalancer.server.port=10000"
      - "traefik.http.services.signal.loadbalancer.server.scheme=h2c"
    logging:
      driver: "json-file"
      options:
        max-size: "100m"
        max-file: "2"

  # Relay: DERP-Fallback
  relay:
    image: netbirdio/relay:${NETBIRD_RELAY_TAG:-latest}
    restart: unless-stopped
    environment:
      - NB_LISTEN_ADDRESS=:33080
      - NB_EXPOSED_ADDRESS=rels://${NETBIRD_DOMAIN}:443
      - NB_AUTH_SECRET=${NETBIRD_RELAY_AUTH_SECRET}
      - NB_LOG_LEVEL=${NB_LOG_LEVEL:-info}
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.relay.rule=Host(`${NETBIRD_DOMAIN}`) && PathPrefix(`/relay`)"
      - "traefik.http.routers.relay.entrypoints=websecure"
      - "traefik.http.routers.relay.tls.certresolver=letsencrypt"
      - "traefik.http.services.relay.loadbalancer.server.port=33080"
    logging:
      driver: "json-file"
      options:
        max-size: "100m"
        max-file: "2"

  # Management: Control-Plane + REST/gRPC API
  management:
    image: netbirdio/management:${NETBIRD_MANAGEMENT_TAG:-latest}
    restart: unless-stopped
    depends_on:
      - signal
    volumes:
      - netbird-mgmt:/var/lib/netbird
      - ./management.json:/etc/netbird/management.json
      - netbird-letsencrypt:/etc/letsencrypt:ro
    command:
      - --config=/etc/netbird/management.json
      - --datadir=/var/lib/netbird
      - --log-level=${NB_LOG_LEVEL:-info}
    environment:
      - NETBIRD_STORE_CONFIG_ENGINE=${NETBIRD_STORE_CONFIG_ENGINE:-sqlite}
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.management-api.rule=Host(`${NETBIRD_DOMAIN}`) && PathPrefix(`/api`)"
      - "traefik.http.routers.management-api.entrypoints=websecure"
      - "traefik.http.routers.management-api.tls.certresolver=letsencrypt"
      - "traefik.http.services.management-api.loadbalancer.server.port=443"
      - "traefik.http.routers.management-grpc.rule=Host(`${NETBIRD_DOMAIN}`) && PathPrefix(`/management.ManagementService`)"
      - "traefik.http.routers.management-grpc.entrypoints=websecure"
      - "traefik.http.routers.management-grpc.tls.certresolver=letsencrypt"
      - "traefik.http.services.management-grpc.loadbalancer.server.port=443"
      - "traefik.http.services.management-grpc.loadbalancer.server.scheme=h2c"
    logging:
      driver: "json-file"
      options:
        max-size: "500m"
        max-file: "2"

  # Coturn: STUN/TURN – MUSS host-Netzwerk nutzen
  coturn:
    image: coturn/coturn:${COTURN_TAG:-latest}
    restart: unless-stopped
    network_mode: host
    volumes:
      - ./turnserver.conf:/etc/coturn/turnserver.conf
    logging:
      driver: "json-file"
      options:
        max-size: "100m"
        max-file: "2"

volumes:
  netbird-mgmt:
  netbird-signal:
  netbird-letsencrypt:

Wichtig für Traefik: Signal und Management sprechen gRPC (HTTP/2). Die Traefik-Labels brauchen daher scheme=h2c für interne Verbindungen. Ohne dieses Schema sehen Clients keine Peers, obwohl die Verbindung scheinbar aufgebaut ist – ein häufiger Fallstrick.

Verifizieren: Prüfe die YAML-Syntax vor dem Start:

docker compose config --quiet && echo "YAML OK"
# Erwartete Ausgabe: YAML OK

Schritt 4: Dienste starten

Jetzt startest du alle fünf Dienste plus Traefik im Hintergrund:

cd /opt/netbird/artifacts/
docker compose up -d

Beim ersten Start lädt Docker alle Images. Das kann je nach Verbindung 2–5 Minuten dauern. Traefik beantragt danach automatisch ein Let's-Encrypt-Zertifikat – dafür muss Port 80 öffentlich erreichbar sein und der DNS-A-Record bereits gesetzt sein.

Verifizieren: Alle sechs Dienste (traefik, dashboard, signal, relay, management, coturn) müssen den Status Up bzw. running haben:

docker compose ps
# Beispiel-Ausgabe:
# NAME          IMAGE                          STATUS
# traefik       traefik:v3.6                   Up
# dashboard     netbirdio/dashboard:v2.34.2    Up
# signal        netbirdio/signal:v0.66.4       Up
# relay         netbirdio/relay:v0.66.4        Up
# management    netbirdio/management:v0.66.4   Up
# coturn        coturn/coturn:4.6.3            Up

Prüfe die Logs auf offensichtliche Fehler:

docker compose logs --tail=30 management
docker compose logs --tail=30 traefik

Prüfe außerdem, dass das TLS-Zertifikat ausgestellt wurde und das Dashboard erreichbar ist:

curl -I https://netbird.example.com
# Erwartete Ausgabe: HTTP/2 200 (oder 302 Redirect auf Login)

Schritt 5: Admin-Account erstellen und Dashboard einrichten

Öffne jetzt sofort im Browser https://netbird.example.com. Beim allerersten Aufruf erscheint die Setup-Seite zur Admin-Account-Erstellung. Diese Seite wird nur angezeigt, solange noch kein Benutzer existiert – wer zu lange wartet oder die URL versehentlich bekannt gibt, riskiert, dass jemand anders den Admin-Account kapern kann. Beschränke daher den Netzwerkzugang bis zur Admin-Erstellung.

Nach dem Login wirst du durch den Setup-Wizard geführt:

1. Admin-Benutzer anlegen (bei embedded IdP direkt im Dashboard)
2. Netzwerk-Name und IP-Range festlegen (Standard: 100.64.0.0/10)
3. Optionale DNS-Domain für Peer-Namen setzen (z. B. netbird.selfhosted)
4. Ersten Setup-Key erzeugen (wird für die Client-Verbindung benötigt)

Verifizieren: Du siehst das NetBird-Dashboard mit einer leeren Peers-Liste und kannst unter „Settings" den Management-Server und die Relay-URL kontrollieren. Unter „Setup Keys" ist mindestens ein aktiver Key vorhanden.

Schritt 6: Ersten Client verbinden

Installiere auf einem Endgerät den NetBird-Client. Für Linux:

# NetBird-Client auf dem Peer-Gerät installieren
curl -fsSL https://pkgs.netbird.io/install.sh | sh

# Mit dem selbst gehosteten Management-Server verbinden
sudo netbird up --management-url https://netbird.example.com

Der Client öffnet automatisch einen Browser für die OIDC-Authentifizierung. Nach erfolgreichem Login taucht das Gerät im Dashboard unter „Peers" auf und erhält eine IP aus dem 100.64.0.0/10-Range.

Für Windows und macOS: Installiere den nativen Client von github.com/netbirdio/netbird/releases und gib beim ersten Start die Management-URL ein.

Verifizieren: Im Dashboard erscheint der neue Peer mit Status „Connected". Auf dem Peer-Gerät zeigt sudo netbird status die zugewiesene IP und den Verbindungsstatus:

sudo netbird status
# Erwartete Ausgabe (gekürzt):
# Management: Connected
# Signal: Connected
# Peers count: 1/1 Connected

Schritt 7: Zugriffsrichtlinien (ACL) konfigurieren

Standardmäßig dürfen alle Peers miteinander kommunizieren. Für ein echtes Zero-Trust-Setup erstellst du im Dashboard unter „Access Control" granulare Regeln:

1. Gruppen anlegen: z. B. „Admins", „Mitarbeiter", „Server"
2. Regeln definieren: Quelle → Ziel → erlaubte Ports/Protokolle
3. Peers zuweisen: Geräte per Setup-Key direkt einer Gruppe zuordnen

Für KMUs empfiehlt sich mindestens eine Segmentierung in Clients (dürfen nur auf dedizierte Server zugreifen) und Server (kein lateraler Zugriff zwischen Maschinen). Die Default-Policy kann über NETBIRD_MGMT_DISABLE_DEFAULT_POLICY=true in der .env deaktiviert werden, wenn du vollständig eigene Regeln definierst.

Verifizieren: Erstelle eine Testregel, die zwei Peers auf Port 22 (SSH) miteinander verbindet. Teste von Peer A: ssh user@<NetBird-IP-von-Peer-B> – die Verbindung sollte aufgebaut werden. Eine explizit verbotene Verbindung schlägt mit „connection refused" oder Timeout fehl.

Eckdaten: Images, Ports, Volumes und Umgebungsvariablen

Docker-Images

Ports (nach außen)

Wichtige Volumes

Schlüssel-Umgebungsvariablen

Backup und Updates

Die kritischsten Daten sind management.json und das Volume netbird-mgmt – insbesondere der NETBIRD_DATASTORE_ENC_KEY. Geht dieser Schlüssel verloren, sind alle gespeicherten Netzwerkkonfigurationen unlesbar. Sichere beide regelmäßig extern. Eine Backup-Strategie für Docker-Volumes findest du in der 3-2-1-Backup-Anleitung.

# Volume sichern (Beispiel mit tar)
docker run --rm \
  -v netbird-mgmt:/data:ro \
  -v /backup:/backup \
  alpine tar czf /backup/netbird-mgmt-$(date +%F).tar.gz /data

# management.json sichern
cp /opt/netbird/artifacts/management.json /backup/management-$(date +%F).json

Updates sind unkompliziert – lies vorher immer die Release Notes, da es bei Major-Versionen Breaking Changes in der management.json-Struktur geben kann:

cd /opt/netbird/artifacts/
# 1. Backup erstellen (s. o.)
# 2. Images aktualisieren
docker compose pull
# 3. Dienste mit neuen Images neu starten
docker compose up -d --force-recreate

Troubleshooting / Typische Fehler

1. Traefik-Logs: acme: error: 403 – DNS-A-Record zeigt noch nicht auf die Server-IP, oder Port 80 ist in der Cloud-Firewall gesperrt. Prüfe mit dig +short netbird.example.com und stelle sicher, dass Port 80 von außen erreichbar ist.
2. Management-API antwortet mit HTTP 500 – Die Datei management.json fehlt oder ist leer. Ursache: getting-started.sh wurde nicht vollständig ausgeführt. Lösung: Skript nochmals ausführen, dann docker compose restart management.
3. Relay-Logs: authentication failed – NETBIRD_RELAY_AUTH_SECRET ist in Management und Relay unterschiedlich gesetzt. Beide Dienste brauchen exakt denselben Wert. Prüfe mit docker compose exec relay env | grep NB_AUTH_SECRET.
4. Peers verbinden sich nicht direkt, immer über Relay – Port 3478/udp ist in der Cloud-Firewall (AWS Security Group, Hetzner Firewall, GCP VPC) nicht freigegeben. UDP wird von vielen Providern standardmäßig geblockt. Öffne den Port explizit.
5. Peers sind verbunden, sehen sich aber nicht – Traefik-Labels für gRPC fehlt scheme=h2c. Signal und Management sprechen HTTP/2-gRPC intern; ohne h2c-Schema leitet Traefik als HTTP/1.1 weiter, was zu Verbindungsabbrüchen führt.
6. SQLite-Daten nach Container-Neustart verloren – Das Volume netbird-mgmt wurde nicht korrekt gemountet. Prüfe mit docker volume ls | grep netbird-mgmt und docker compose config | grep netbird-mgmt.
7. Setup-Seite für Admin-Erstellung nicht mehr sichtbar – Die /setup-Seite erscheint nur, wenn noch kein Benutzer existiert. War die Seite schon von jemand anderem aufgerufen? Prüfe im Management-Log, ob bereits ein Benutzer angelegt wurde: docker compose logs management | grep -i "user created". Im Notfall: Datenbank zurücksetzen (Volume leeren) und neu starten.

Häufige Fragen

Brauche ich zwingend einen externen Identity Provider?

Nein. NetBird bietet einen eingebauten Dex-basierten IdP, der lokale Benutzerverwaltung direkt im Dashboard ermöglicht – ideal für Homelab und kleine Teams ohne bestehende SSO-Infrastruktur. Das getting-started.sh-Skript richtet diesen automatisch ein. Für Produktionsumgebungen in KMUs empfehlen sich externe IdPs wie Zitadel, Keycloak oder Authentik – alle selbst hostbar und per Docker deploybar.

Was ist der Unterschied zu WireGuard, Tailscale und Headscale?

Reines WireGuard ist ein VPN-Protokoll ohne Kontrollplane – du konfigurierst Peers manuell. Tailscale bietet eine komfortable Control-Plane, ist aber an die Tailscale-Cloud gebunden. Headscale ist eine selbst gehostete Alternative zur Tailscale-Control-Plane. NetBird geht einen eigenen Weg: vollständige Self-Hosted-Infrastruktur inklusive STUN/TURN, SSO, MFA und ACL – ohne jede Cloud-Abhängigkeit.

Wie skaliere ich die Installation für größere Teams?

SQLite ist für kleine Teams (bis ca. 50 Peers) ausreichend. Für größere Deployments setzt du NETBIRD_STORE_CONFIG_ENGINE=postgres in der .env und fügst einen PostgreSQL-Container zum Stack hinzu. Signal und Relay können bei Bedarf auf separate Server ausgelagert werden – die NetBird-Dokumentation beschreibt das im Scaling-Guide.

Was passiert, wenn der NetBird-Server nicht erreichbar ist?

Bestehende WireGuard-Verbindungen zwischen Peers bleiben aktiv. Der Kontrollserver ist nur für neue Verbindungsaufbauten, Konfigurationsänderungen und ACL-Updates notwendig. Peers, die bereits verbunden sind, kommunizieren weiter – das Netzwerk ist gegenüber temporären Server-Ausfällen resilient.

Kann ich NetBird ohne öffentliche IP betreiben?

Bedingt: Management, Signal und Dashboard brauchen eine öffentlich erreichbare Domain für TLS und Peer-Registrierung. Coturn benötigt eine öffentliche IP für NAT-Traversal. Reine interne Deployments (z. B. im Firmen-LAN) sind möglich, aber Peers hinter doppeltem NAT können sich ohne erreichbaren TURN-Server möglicherweise nicht direkt verbinden.

Kann ich NetBird mit Traefik kombinieren, der bereits für andere Dienste läuft?

Ja. Wenn du bereits einen Traefik-Stack betreibst – etwa wie in der Traefik-Grundanleitung beschrieben – fügst du den NetBird-Diensten die Traefik-Labels hinzu und bindest sie an das bestehende Traefik-Netzwerk. Der Coturn-Container läuft immer separat mit network_mode: host, das berührt Traefik nicht.

Fazit

NetBird ist eine ausgereifte, produktionstaugliche Alternative zu kommerziellen Zero-Trust-Lösungen. Der fünf-Dienste-Stack klingt zunächst komplex, ist aber nach dem ersten Durchlauf gut handhabbar – insbesondere dank des getting-started.sh-Skripts, das die fehleranfälligen Konfigurationsdateien automatisch generiert. Die Kombination aus WireGuard-Performance, SSO/MFA, granularen ACLs und vollständiger Datenkontrolle macht NetBird besonders interessant für KMUs, die eine Cloudflare-Access-Alternative ohne Vendor-Lock-in suchen. Drei Ports nach außen, automatisches TLS, arm64-Support und ein aktiver Release-Zyklus runden das Bild ab. Wer mehr Kontrolle über sein Netzwerk-Overlay haben will, ist hier genau richtig.

Weiterführende Anleitungen und Quellen

1. WireGuard-VPN für Homeoffice und Standortvernetzung einrichten – die Grundlage, auf der NetBird aufbaut
2. Headscale selbst hosten: Tailscale-Mesh-VPN ohne Cloud-Abhängigkeit für KMU – die Alternative zu NetBird im Vergleich
3. Traefik als Docker-Reverse-Proxy mit automatischem HTTPS – Traefik-Grundkonfiguration für den gemeinsamen Einsatz
4. Docker und Docker Compose auf Linux installieren – Voraussetzung für diese Anleitung
5. Zero-Trust-Netzwerksegmentierung im KMU: VLANs, Firewall-Regeln und Mikrosegmentierung – ergänzendes Konzept-Wissen

Offizielle Quellen: NetBird Self-Hosted Quickstart · Advanced Guide · Environment Variables Reference · GitHub netbirdio/netbird