Traefik vs. Nginx Proxy Manager – warum ich (nicht) gewechselt bin

22. April 2026

Zwei Jahre NPM, drei Wochen Traefik-Test, eine ehrliche Bilanz.

Nach zwei Jahren mit Nginx Proxy Manager habe ich Traefik im Homelab getestet. Dieser Artikel erklärt pragmatisch, wo Traefik wirklich gewinnt, wo NPM reicht, und warum ich am Ende einen hybriden Setup fahre.

Traefik vs Nginx Proxy Manager Header

Ausgangslage: Warum überhaupt wechseln?

Bei mir läuft der Nginx Proxy Manager (NPM) seit rund zwei Jahren als zentraler Reverse Proxy im Homelab. Er terminiert TLS für knapp 30 interne Services – Home Assistant, Nextcloud, Grafana, Portainer, GitLab, diverse Bastelprojekte. Let's-Encrypt-Zertifikate kommen über die DNS-Challenge (Cloudflare), dazu habe ich bereits einen Artikel geschrieben.

Der Auslöser für den Traefik-Test war nicht Unzufriedenheit, sondern drei konkrete Pain Points:

  • Neue Docker-Container landen zu oft manuell in der NPM-GUI. Jedes Mal Host anlegen, Zertifikat zuweisen, Websockets aktivieren – beim zehnten Mal nervt das.
  • Config-Drift. Die NPM-Konfiguration liegt in einer SQLite-DB, nicht in Git. Ein Restore ist ein Volume-Backup, nichts was man reviewen kann.
  • Middleware. Authentik-ForwardAuth, Rate-Limiting pro Service, custom Header – das ist in NPM entweder umständlich oder gar nicht möglich.

Also: drei Wochen Traefik v3 auf einer zweiten Maschine. Hier die ehrliche Bilanz.

TL;DR für Ungeduldige

Kurzversion

NPM bleibt bei mir der Haupt-Proxy für alles, was auf dedizierter Hardware läuft (Home Assistant auf dem Odroid M1, NAS, Drucker-Pi etc.). Klickbar, schnell, auch der Rest der Familie findet sich im UI zurecht.

Traefik ist neu eingezogen für meine Docker-Compose-Stacks auf dem Homelab-Host. Dort sind Labels schlicht der bessere Weg als eine zweite Admin-Oberfläche.

Ergebnis: Hybrid-Setup. Nicht weil ich unentschlossen bin, sondern weil beide Tools unterschiedliche Probleme lösen.

Was NPM richtig gut macht

Man darf Nginx Proxy Manager nicht unterschätzen. Er ist nicht das "Einsteiger-Tool, aus dem man rauswächst" – er ist für bestimmte Szenarien schlicht das bessere Werkzeug:

  • Niedrige Einstiegshürde. Installation in 3 Minuten, erstes TLS-Zertifikat in 5 Minuten. Kein YAML, kein TOML, keine Dokumentationslektüre.
  • Let's-Encrypt-DNS-Challenge per Klick. Provider auswählen, API-Token rein, Wildcard-Zertifikat – fertig.
  • Access Lists. IP-basierte Zugriffskontrolle mit HTTP Basic Auth, grafisch anklickbar. Reicht für 90 % der Homelab-Fälle.
  • Übersichtlichkeit für Nicht-DevOps. Man kann auf einen Blick sehen, welche Dienste erreichbar sind. Keine docker inspect-Outputs lesen müssen.

Der große Nachteil ist genau die Stärke: Alles lebt in einer SQLite-DB. Keine Config-as-Code, kein Git, kein Review.

Wo Traefik glänzt

Traefik ist fundamental anders gedacht. Es ist kein "Reverse Proxy mit UI", sondern ein dynamischer Edge Router, der seine Konfiguration aus "Providern" zieht – Docker, Kubernetes, File, Consul. Das klingt nach Overhead, spart aber in der Praxis viel Zeit.

Mein minimales Setup für den Homelab-Host sieht so aus:

# docker-compose.yml (Traefik)
services:
  traefik:
    image: traefik:v3.2
    restart: unless-stopped
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock:ro
      - ./traefik.yml:/etc/traefik/traefik.yml:ro
      - ./dynamic:/etc/traefik/dynamic:ro
      - ./letsencrypt:/letsencrypt
    environment:
      - CF_DNS_API_TOKEN=${CF_DNS_API_TOKEN}
    networks:
      - proxy

networks:
  proxy:
    external: true

Die statische Konfiguration (traefik.yml) definiert nur, dass Docker als Provider genutzt wird und Let's Encrypt über die Cloudflare-DNS-Challenge läuft. Jeder neue Dienst kommt danach einfach mit Docker-Labels dazu – keine zweite Stelle, an der ich etwas konfiguriere:

# Beispiel: Uptime Kuma hinter Traefik
services:
  uptime-kuma:
    image: louislam/uptime-kuma:1
    restart: unless-stopped
    volumes:
      - ./data:/app/data
    networks:
      - proxy
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.uptime.rule=Host(`uptime.homelab.example.com`)"
      - "traefik.http.routers.uptime.entrypoints=websecure"
      - "traefik.http.routers.uptime.tls.certresolver=cloudflare"
      - "traefik.http.services.uptime.loadbalancer.server.port=3001"

networks:
  proxy:
    external: true

docker compose up -d – fertig. Traefik erkennt den Container, holt das Wildcard-Zertifikat (falls nicht schon vorhanden), routet den Traffic. Kein Klick in irgendeinem UI.

Und genau das ist der Punkt: Die Config der Services liegt bei den Services. Das Git-Repo des Homelab-Stacks ist zugleich die komplette Proxy-Konfiguration.

Der Knackpunkt: Middleware

Der Bereich, in dem NPM wirklich fühlbar an Grenzen stößt, ist Middleware. Rate Limiting, Custom Headers, Forward-Auth gegen Authentik/Authelia – in NPM geht das nur über das "Advanced"-Feld mit rohem Nginx-Code, und dann gute Nacht mit Backup und Portabilität.

In Traefik ist Authentik-ForwardAuth ein Label:

# Middleware einmal global definiert (dynamic/middlewares.yml)
http:
  middlewares:
    authentik:
      forwardAuth:
        address: "http://authentik-server:9000/outpost.goauthentik.io/auth/traefik"
        trustForwardHeader: true
        authResponseHeaders:
          - X-authentik-username
          - X-authentik-groups
          - X-authentik-email
# ...und pro Service einfach referenzieren:
labels:
  - "traefik.enable=true"
  - "traefik.http.routers.grafana.rule=Host(`grafana.homelab.example.com`)"
  - "traefik.http.routers.grafana.middlewares=authentik@file"
  - "traefik.http.routers.grafana.tls.certresolver=cloudflare"

Einmal definiert, überall wiederverwendbar. Das ist der Moment, in dem Traefik bei mir den Elastizitätstest gewonnen hat.

Der ehrliche Vergleich

Nach drei Wochen Parallelbetrieb hier meine Einschätzung – ohne Marketing, mit Praxisbezug Homelab (nicht Enterprise):

  • Setup-Zeit bis erster funktionierender HTTPS-Host: NPM ~10 min, Traefik ~60 min (weil man einmal die Konzepte verstehen muss).
  • Zeit pro weiterem Service: NPM ~3 min Klicken, Traefik ~30 Sekunden Label kopieren.
  • Config-as-Code: NPM nein (SQLite), Traefik ja (YAML im Git).
  • Middleware / Auth: NPM umständlich, Traefik nativ.
  • Observability: Beide haben ein Dashboard. Traefik's Dashboard ist rein Read-only, NPM lässt dich dort Konfiguration anlegen.
  • Nicht-Docker-Backends: NPM trivial (IP + Port eintragen). Traefik braucht file-Provider mit manueller YAML.
  • Wenn der Proxy selber crashed: Beide kommen automatisch hoch. Bei NPM verliert man im Worst Case die SQLite (Backup!), bei Traefik ist der State in der Config + acme.json.

Warum ich NPM nicht abgeschaltet habe

Der rationale Schluss wäre "Traefik überall". Warum ich es nicht gemacht habe:

  • Die Hälfte meiner Services läuft nicht in Docker auf dem gleichen Host. Home Assistant auf einem Odroid M1, Nextcloud auf einer separaten VM, der 3D-Drucker-Pi, eine Synology. Für diese Nicht-Docker-Backends bietet Traefik keinen Mehrwert – ich müsste sie per file-Provider statisch in YAML eintragen. Das ist genau das, was NPM grafisch macht, nur eine Abstraktionsebene tiefer.
  • Zweite-Person-Problem. Wenn ich im Urlaub bin und etwas nicht geht, soll meine Familie im NPM-UI sehen können, ob der Proxy den Host überhaupt kennt. YAML debuggen will keiner am Küchentisch.
  • Don't fix what ain't broken. 30 Hosts, 2 Jahre ohne Ausfall – da hat ein Ersatz eine hohe Hürde.

Wo Traefik trotzdem eingezogen ist

Auf dem Docker-Host mit den Bastelprojekten – das Ding mit 12 Compose-Stacks, wo jede Woche was Neues dazukommt. Dort ist Traefik ein klarer Gewinn.

Die Architektur sieht jetzt so aus:

  • Router / OpenWrt: Internes DNS zeigt *.homelab.example.com auf die NPM-IP.
  • NPM: Terminiert TLS für alle Nicht-Docker-Services (Home Assistant auf dem Odroid M1, NAS, Drucker-Pi). Außerdem proxied er einen einzigen Host, *.docker.homelab.example.com, weiter auf den Docker-Host.
  • Traefik (auf dem Docker-Host): Übernimmt dort von NPM und routet per Label in die jeweiligen Container. Eigenes Wildcard-Zertifikat via DNS-Challenge.

Das ist bewusst pragmatisch, nicht überengineered. NPM bleibt die "Einsteigerebene" für Menschen, Traefik die "Maschinenebene" für Container.

Was ich weggelassen habe

Ehrliche Abgrenzung

Ein paar Dinge habe ich bewusst nicht gemacht, obwohl sie in jedem zweiten Blogpost auftauchen:

  • Traefik als einziger Entry Point vom Internet. Meine Homelab-Services sind bewusst nur intern erreichbar (Wireguard für Remote). Dann ist die "Auto-HTTPS vom Internet aus"-Stärke egal.
  • Kubernetes-Ingress. Ich habe keinen K8s-Cluster zu Hause. Für K3s etc. wäre Traefik ohnehin gesetzt – das ist aber eine andere Diskussion.
  • Caddy. Ja, Caddy kann vieles elegant. Für diesen Vergleich habe ich ihn rausgelassen, sonst wird der Artikel endlos. Möglicherweise ein nächster Test.

Fazit & Ausblick

Die Frage "Traefik oder NPM" ist bei mir zur Frage "Traefik und NPM, wer wofür?" geworden. NPM ist ein exzellenter Reverse Proxy für statische Backends und Menschen, die klicken wollen. Traefik ist der natürliche Partner für Docker-Compose-Stacks und alles, was Middleware-Logik braucht.

Was als Nächstes ansteht: ein Folgeartikel zum konkreten Authentik-Setup mit Traefik für die internen Tools – da steckt nochmal genug Stolperpotenzial drin für einen eigenen Beitrag. Und vielleicht irgendwann doch der Caddy-Test.

Wenn du selbst vor der Wahl stehst: Der schnellste Reality-Check ist, drei Services zu zählen, die du in den nächsten sechs Monaten aufsetzen wirst. Sind das drei Docker-Compose-Stacks? Traefik. Sind das ein Odroid, ein Pi und ein NAS? Bleib bei NPM.

Teilen:


Schreibe einen Kommentar

Wird für die Bestätigung benötigt