⚡ HomelabVergleich

Caddy als Reverse Proxy: HTTPS für alle eigenen Dienste

Jeder, der mehrere Webdienste in seinem Homelab betreibt, stolpert über dasselbe Problem: Jeder Dienst hat seine eigene Adresse, oft mit einem selbst signierten Zertifikat, und der Browser warnt jeden Besucher. Pi-hole auf Port 80, Nextcloud auf 8080, Grafana auf 3000, Vaultwarden auf 8000 – die Liste wächst mit jedem neuen Projekt. Irgendwann ist die Übersicht weg, und der Wunsch nach einer einzigen, sicheren Startseite mit gültigem HTTPS für alle Dienste wird laut.

Genau hier kommt ein Reverse Proxy ins Spiel. Und genau hier entscheidet sich die Frage, welche Software diese Aufgabe übernimmt. Für viele Homelaber ist heute Caddy die naheliegendste Antwort. Dieser Artikel erklärt, warum das so ist, welche Voraussetzungen gehen müssen, wie konkrete Caddyfiles aussehen und was man beachten muss, bevor Dienste wirklich nach außen gehen.

Warum Caddy statt Nginx?

Nginx ist seit Jahren der Standard für Reverse Proxys, und er erledigt seine Aufgabe zuverlässig. Doch Nginx bringt kein automatisches HTTPS mit. Wer einen Nginx-Reverse Proxy mit Let's Encrypt-Zertifikaten versorgt, muss ein eigenes Zertifikats-Wrapper-Tool wie Certbot oder acme.sh neben dem Nginx-Host betreiben, Erneuerungen konfigurieren, Hook-Skripte schreiben und prüfen, ob das Zertifikat tatsächlich erneuert wurde, bevor es abläuft.

Caddy hat diese Integration von Grund auf eingebaut. Das offizielle Caddy-Binary enthält bereits alle Komponenten, die für automatische TLS-Zertifikate nötig sind. Sobald eine Domain in einem Caddyfile auftaucht, prüft Caddy beim Start, ob ein gültiges Zertifikat vorhanden ist oder ob eine ACME-Challenge (HTTP oder DNS) möglich ist. Wenn ja, lädt Caddy das Zertifikat herunter und erneuert es im Hintergrund, ohne dass ein weiterer Daemon oder ein Cron-Job eingerichtet werden muss.

Das macht den Unterschied im Alltag konkret:

Das heißt nicht, dass Caddy immer besser ist. Für Umgebungen, in denen alle Dienste als Docker-Container laufen und automatisch erkannt werden sollen, ist Traefik oft die skalierlichere Wahl. Für Nutzer, die eine grafische Oberfläche bevorzugen, bietet Nginx Proxy Manager die Klick-Oberfläche, die Caddy bewusst nicht mitbringt. Für das klassische Homelab mit einem handvoll statischer Dienste, die man auf einer VM oder in einer LXC-Instanz betreibt, ist Caddy jedoch eine sehr überzeugende Wahl – ganz ohne UI, aber mit minimaler Konfigurationsaufgabe.

Die Caddyfile-Syntax im Überblick

Ein Caddyfile ist nicht secret. Die Grundstruktur sieht immer gleich aus:


domain.tld {
    # Direktiven hier
}

Alles, was innerhalb der geschweiften Klammern steht, gehört zu dieser Domain. Mehrere Domains können auch durch einfaches Aneinanderreihen definiert werden, wenn sie dieselbe Behandlung erhalten. Die wichtigsten Direktiven im Reverse-Proxy-Zusammenhang sind:

Die HTTP-Challenge von Let's Encrypt (die Standard-Methode für einzelne Domains) funktioniert, indem der Caddy-Prozess selbst kurzzeitig über Port 80 antwortet, um den Challenge-Nachweis zu erbringen. Das setzt voraus, dass Port 80 von außen erreichbar ist. Für Wildcard-Zertifikate ist stattdessen die DNS-Challenge nötig, die zusätzlich ein Caddy-Modul für den jeweiligen DNS-Provider erfordert.

Voraussetzungen: DNS und Port-80/443

Bevor Caddy das erste Mal mit einer Domain startet, müssen zwei Dinge gegeben sein: die DNS-Auflösung und die Port-Erreichbarkeit.

DNS-Voraussetzungen

Jeder Domainname, für den Caddy ein öffentliches Let's Encrypt-Zertifikat anfordern soll, muss von außen auf die öffentliche IP des Servers zeigen. Die praktische Bedeutung: Wenn cloud.beispiel.de auf Caddy zeigt, dann muss der A- oder AAAA-Record für diese Subdomain im DNS Correctly auf die öffentliche IP verweisen.

Für ein einzelnes Homelab mit mehreren Subdomains gibt es zwei gängige Muster:

Wildcard-Zertifikate sind praktisch, aber sie haben eine Relevanz-Trap: Sie funktionieren nur, wenn der DNS-Provider automatisch ein TXT-Record für die ACME-DNS-Challenge setzen kann. Nicht jeder Provider hat ein offiziell unterstütztes Caddy-Plugin; bei kleineren oder älteren Providern kann die Einrichtung mehr Aufwand kosten, als die Wildcard einspart.

Port-80- und Port-443-Voraussetzungen

Caddy muss Port 80 und Port 443 gebunden haben, damit HTTP-Challenge und TLS-Terminierung funktionieren. In der Firewall muss beides nach außen freigegeben sein. Zusätzlich muss nichts anderes diese Ports schon blockieren oder nutzen – ein anderer Webserver, der noch auf Port 80 lauscht, muss vorher geschaltet werden.

In der Praxis bedeutet das: Bevor Caddy gestartet wird, prüft man mit ss -tlnp oder netstat -tlnp, ob Port 80 und 443 frei sind. Wenn ein anderer Dienst dort noch läuft, bekommt Caddy beim Start einen Fehler und startet nicht.

Im Router oder der Firewall des Isenggeräts muss außerdem eine Portweiterleitung (Port Forwarding) für 80/TCP und 443/TCP auf die interne IP des Caddy-Hosts zeigen. Ohne diese Weiterleitung kann Let's Encrypt die HTTP-Challenge nicht erreichen, und Caddy kann kein Zertifikat anfordern. Das ist einer der häufigsten Gründe, warum Caddy zwar lokal läuft, aber kein Zertifikat Holt.

Was, wenn kein Port 80 nach außen geht?

Wenn aus sicherheitstechnischen Gründen kein Port 80 nach außen freigegeben werden soll, gibt es zwei Alternativen:

Zertifikate: Interne Namen und öffentliche Namen

Nicht jeder Dienst in einem Homelab soll öffentlich erreichbar sein, und nicht jede Domäne braucht ein Let's Encrypt-Zertifikat. Caddy unterstützt beide Welten.

Öffentliche Domain-Zertifikate mit Let's Encrypt

Sobald eine Domain von außen erreichbar ist, erstellt Caddy automatisch ein Let's Encrypt-Zertifikat über die HTTP- oder DNS-Challenge. Die Konfiguration dafür ist implizit: Werte einfach die Domain ins Caddyfile, und Caddy kümmert sich um den Rest. Ein explizites tls-Statement ist nur nötig, wenn eine Abweichung vom Standard gewünscht ist, etwa ein anderes Zertifikatsverzeichnis oder ein bestimmter Zertifizierer.

Interne Dienste mit einem eigenen Zertifikat

Für Dienste, die nur im lokalen Netzwerk erreichbar sein sollen, aber trotzdem verschlüsselt sein müssen (z. B. zwischen Proxy und Backend), gibt es das Konzept eines internen Caddy-Zertifikats. Das praktische Muster: Ein Root-Zertifikat erstellen, dieses auf alle Clients importieren, und dann Caddy anweisen, für bestimmte Domänen dieses eigenständige Zertifikat zu verwenden.

Ein Beispiel für ein solches Setup:


pi.bsn.internal {
    tls {
        ca_field common_name "BsN Internal CA"
        # Verweist auf ein internes Zertifikat – genaue Syntax je nach Caddy-Version
    }
    reverse_proxy 192.168.3.11:80
}

dashboard.bsn.internal {
    tls {
        ca_field common_name "BsN Internal CA"
    }
    reverse_proxy 192.168.3.25:8890
}

Die exakte Syntax für interne Zertifikate kann je nach Caddy-Version leicht variieren. Für Caddy 2 mit dem tls.builtin-Backend ist eine Methode, das Vertrauen über den tls-Block zu konfigurieren, wenn kein public-CA-Zertifikat verfügbar ist. Ein kleiner, aber wichtiger Vorteil: Auch interne Dienste werden dann per HTTPS angesprochen, ohne dass Browser-Warnungen auftreten, solange das Root-Zertifikat der eigenen CA vertraut ist.

Für das praktische Homelab ist die häufigste Empfehlung: Öffentliche Dienste über Caddy + Let's Encrypt, interne Dienste mit eigener CA oder klartext hinter Caddy. Letztlich entscheidet die Zugriffsabsicht: Dienste, die von unterwegs genutzt werden, sollten HTTPS von einer vertrauenswürdigen CA haben. Dienste, die nur an einem spezifischen Arbeitsplatz im lokalen Netz erreichbar sind, können oft auch mit einem eigenen Zertifikat Sicherheit haben.

Konkrete Caddyfile-Beispiele

Die folgenden Beispiele zeigen, wie ein Caddyfile für typische Homelab-Dienste aussehen kann. Sie sind bewusst einfach gehalten, weil Caddy mit wenig Zeilen viel erreicht. Jedes Beispiel setzt voraus, dass die jeweiligen Subdomains bereits in der DNS-Konfiguration korrekt aufgelöst werden.

Beispiel 1: Pi-hole hinter Caddy

Pi-hole läuft standardmäßig auf Port 80 und bietet eine Web-Oberfläche für DNS-Statistiken und Blocklisten-Konfiguration. Hinter Caddy wird es über eine Subdomain erreichbar.


pihole.beispiel.de {
    reverse_proxy 192.168.3.62:80
    encode zstd gzip

    header {
        Strict-Transport-Security "max-age=31536000; includeSubDomains"
        X-Content-Type-Options "nosniff"
    }
}

Pi-hole selbst kommend auch über HTTPS – aber im lokalen Netzwerk reicht oft die Klartext-Verbindung zwischen Caddy und Pi-hole, weil beides im vertrauenswürdigen Netzsegment liegen. Caddy terminiert das TLS nach außen und leitet unverschlüsselt weiter. Das spart Pi-hole die Zertifikatsverwaltung.

Soll Pi-hole auch DNS-Over-TLS für Clients im Netzwerk bereitstellen, ist das eine separate Konfiguration im Pi-hole selbst, nicht direkt Caddy-Thema.

Beispiel 2: Nextcloud hinter Caddy

Nextcloud ist eines der anspruchsvollsten Backend-Systeme im Homelab. Es erwartet spezifische Header und korrektes Proxy-Verhalten, um Funktionen wie Kalender, Kontakte und Echtzeit-Benachrichtigungen zuverlässig zu liefern.


nextcloud.beispiel.de {
    reverse_proxy 192.168.3.25:8080 {
        header_up Host {upstream_hostport}
        header_up X-Real-IP {remote}
        header_up X-Forwarded-For {remote}
        header_up X-Forwarded-Proto {scheme}
    }

    encode zstd gzip

    header {
        Strict-Transport-Security "max-age=31536000; includeSubDomains"
        X-Content-Type-Options "nosniff"
        X-Frame-Options "SAMEORIGIN"
        Referrer-Policy "strict-origin-when-cross-origin"
    }

    log {
        output file /var/log/caddy/nextcloud.log
        format console
    }
}

Wichtig bei Nextcloud: Die Header X-Forwarded-Proto und X-Forwarded-For müssen gesetzt sein, sonst erkennt Nextcloud den Verbindungs-Typ nicht korrekt und einige Funktionen verhalten sich anders als erwartet. Das header_up-Block innerhalb von reverse_proxy übergibt diese Werte vom Proxy an das Nextcloud-Backend.

Beispiel 3: Grafana hinter Caddy

Grafana läuft auf Port 3000 und wird häufig für Homelab-Monitoring eingesetzt – ein Thema, das in Homelab-Monitoring: Schöne Grafana-Dashboards bauen genauer behandelt wird.


grafana.beispiel.de {
    reverse_proxy 192.168.3.25:3000 {
        header_up Host {upstream_hostport}
    }

    encode zstd gzip

    header {
        Strict-Transport-Security "max-age=31536000; includeSubDomains"
    }

    log {
        output file /var/log/caddy/grafana.log
    }
}

Grafana muss konfiguriert werden, dass es weiß, dass es hinter einem Proxy läuft. In der grafana.ini oder über Umgebungsvariablen setzt man protocol = http und domain = grafana.beispiel.de, damit Links und Redirects die externe URL verwenden. Ohne diese Einstellung generiert Grafana interne URLs mit der lokalen IP oder localhost, was von außen nicht funktioniert.

Beispiel 4: Vaultwarden hinter Caddy

Vaultwarden – die schlanke Bitwarden-Variante – gehört zu den sensibelsten Diensten im Homelab. Passwörter sollten niemals unverschlüsselt übertragen werden. Hinter Caddy bekommt Vaultwarden automatisch ein gültiges Zertifikat, das Browser ohne Warnung akzeptieren.


vaultwarden.beispiel.de {
    reverse_proxy 192.168.3.25:8008 {
        header_up Host {upstream_hostport}
        header_up X-Real-IP {remote}
        header_up X-Forwarded-For {remote}
        header_up X-Forwarded-Proto {scheme}
    }

    encode zstd gzip

    header {
        Strict-Transport-Security "max-age=31536000; includeSubDomains"
        X-Content-Type-Options "nosniff"
    }

    log {
        output file /var/log/caddy/vaultwarden.log
    }
}

Für Vaultwarden ist HTTPS nicht nur Komfort – es ist zwingend. Ohne TLS würden Master-Passwort und verschlüsselte Vault-Daten im Klartext über das Netzwerk wandern. Die Dokumentation in Vaultwarden: Passwort-Manager selbst hosten behandelt den Dienst selbst, Caddy übernimmt hier nur die TLS-Terminierung und das Routing.

Beispiel 5: Homelab-Dashboard hinter Caddy

Ein zentrales Dashboard, das alle Dienste auf einen Blick sammelt, ist für viele Homelaber die erste Anlaufstelle. Unabhängig davon, ob Homarr, Homepage oder Heimdall gewählt wird – wie in Homelab Dashboard: Homarr vs Homepage vs Heimdall im Vergleich beschrieben – läuft das Dashboard häufig auf einem eigenen Port und wird dann per Caddy auf eine Domain gehoben.


dashboard.beispiel.de {
    reverse_proxy 192.168.3.25:7575 {
        header_up Host {upstream_hostport}
    }

    encode zstd gzip

    header {
        Strict-Transport-Security "max-age=31536000"
    }

    log {
        output file /var/log/caddy/dashboard.log
    }
}

Die Port-Nummer in reverse_proxy muss je nach gewähltem Dashboard angepasst werden. Homarr läuft meist auf 7575, Homepage auf 3000, Heimdall auf 8080 (oder 80 im Container). Caddy selbst kümmert sich nicht um die interne Port-Zuordnung des Dashboards – es leitet einfach den gesamten Traffic weiter.

Beispiel 6: Pfadbasiertes Routing (single domain, mehrere Dienste)

Manchmal reichen Subdomains nicht aus oder sollen vermieden werden. Dann kann Caddy auch pfadbasiert routeen. Beispiel: Ein Dashboard und ein Monitoring-Tool auf derselben Domain, verschiedene Pfade.


beispiel.de {
    reverse_proxy /monitoring* 192.168.3.25:3000 {
        header_up Host {upstream_hostport}
    }

    reverse_proxy / 192.168.3.25:7575 {
        header_up Host {upstream_hostport}
    }
}

Achtung bei pfadbasierten Setup: Nicht jeder Backend-Dienst verträgt es sauber, wenn die Anfrage mit einem Pfad-Präfix kommt, den er nicht erwartet. Nextcloud beispielsweise erwartet normalerweise den Basis-Pfad /, nicht /nextcloud/. Pfadbasiertes Routing ist also nicht für jeden Dienst geeignet – für Dashboards und Monitoring-Tools hingegen oft ein sauberer Weg.

Stolperfallen: Was Caddy nicht automatisch repariert

Caddy reduziert die Konfigurationsaufgabe drastisch, aber es ist kein Allheilmittel. Einige Probleme bleiben dadurch, dass die Voraussetzungen liegen.

Zertifikatsrate-Limits von Let's Encrypt

Let's Encrypt begrenzt die Anzahl der Zertifikate, die pro Domain und pro Stunde ausgestellt werden können. Wenn Caddy in einer Testphase viele Domains oder Wildcard-Anfragen wiederholt schlägt, kann es sein, dass Let's Encrypt temporär keine neuen Zertifikate mehr ausstellt. Das Ergebnis: Caddy startet, kann aber kein gültiges Zertifikat anfordern, und zeigt im Log eine Fehlermeldung.

Die Rate-Limits betreffen nicht laufende Erneuerungen – sie betreffen nur neue Zertifikat-Anfragen. Wer während der Einrichtung wild viele Domains hinzufügt und wieder entfernt, riskiert eine temporäre Blockade. Die praktische Abhilfe: Vor dem produktiven Einsatz alle Domains in Ruhe konfigurieren und nicht im Trial-and-Error-Verfahren.

Wildcard-Zertifikate und DNS-Provider

Wildcard-Zertifikate (*.beispiel.de) sind praktisch, aber sie erfordern die DNS-Challenge. Für die DNS-Challenge muss Caddy einen Mechanismus haben, der bei dem jeweiligen DNS-Provider die nötigen TXT-Records setzt. Dafür gibt es zahlreiche Plugins, aber nicht jeder Provider ist offiziell unterstützt. Ist kein passendes Plugin verfügbar, muss auf die HTTP-Challenge mit einzelnen Domains ausweichen oder ein manueller Workflow genutzt werden.

Ein weiterer Punkt: Wildcard-Zertifikate decken alle Subdomains ab, aber nicht alle Subdomains sollen auch existieren. Wem ein Wildcard-Zertifikat ausgestellt ist, macht damit implizit alle Subdomains unter der Domäne technisch erreichbar – solange die DNS-Auflösung stimmt. Das ist kein Sicherheitsloch im Zertifikat, aber ein Bewusstseins-Thema für Netzwerkdesign.

Reverse Proxy statt VPN

Eine der häufigsten Verwechslungen: Ein Reverse Proxy macht Dienste erreichbar, er schützt sie aber nicht automatisch. Wenn Caddy Nextcloud nach außen exponiert und kein Authentifizierungsschicht davor steht, ist Nextcloud von überall ohne VPN erreichbar. Für manche Dienste ist das gewollt – für andere ein unnötiges Risiko.

Die Entscheidung sollte bewusst sein: Welche Dienste müssen wirklich öffentlich erreichbar sein? Die meisten Homelab-Dienste brauchen das nicht. Pi-hole zum Beispiel braucht oft nur lokalen Zugriff; ein VPN wie Pi-hole + WireGuard: Werbefrei und sicher von unterwegs reicht aus, um auch unterwegs den Werbeblocker zu nutzen, ohne Pi-hole öffentlich zu machen.

Ein Reverse Proxy ist kein Ersatz für ein VPN. Er macht einen Dienst über eine öffentliche Adresse erreichbar; ein VPN macht das gesamte Netzwerk erreichbar, ohne einzelne Dienste zu exponieren.

Authentifizierungsschicht vor dem Proxy

Wenn Dienste öffentlich erreichbar gemacht werden, sollte überlegt werden, ob eine Authentifizierungsschicht davor sinnvoll ist. Tools wie Authentik oder Authelia können als Reverse-Proxy-Gatekeeper fungieren: Der Proxy leitet die Anfrage zuerst an die Auth-Lösung weiter, und erst wenn der Nutzer authentifiziert ist, geht die Anfrage an das Backend.

Das ist besonders relevant für Admin-Oberflächen, Monitoring-Tools und Passwort-Manager. In Homelab-Sicherheit: Fail2ban & Authentik einrichten wird beschrieben, wie Authentik als SSO mit optionalem Zwei-Faktor-Authentifizierungsschritt vor Dienste gestellt werden kann.

Caddy selbst bringt keine eingebaute Vorauthentifizierung mit. Es kann mit externen Auth-Tools kombiniert werden, indem die forward_auth-Direktive eingesetzt wird:


dashboard.beispiel.de {
    forward_auth authentik.beispiel.de {
        uri /api/verify
        copy_headers true
    }

    reverse_proxy 192.168.3.25:7575
}

Die genaue Syntax und Konfiguration von forward_auth hängt von der Authentik-Version und dem Authentik-Provider-Setup ab; das Caddy-Plugin für Authentik ist Teil der offiziellen Caddy-Repository-Plugins und muss ggf. separat installiert werden bei selbst gebautem Caddy-Binary.

Sicherheits-Hinweise: Nicht jeden Dienst öffentlich machen

Der sicherste Dienst ist der, der nicht nach außen geht. Bevor ein Dienst hinter Caddy öffentlich gemacht wird, ist die Frage zu stellen: Braucht wirklich jemand von außerhalb Zugriff auf genau diesen Dienst?

Dienste, die nie öffentlich sein sollten

Die offensichtlichen Kandidaten:

Dienste, die öffentlich gemacht werden können – mit Einschränkung

HTTPS ist nötig, aber nicht ausreichend

HTTPS verschlüsselt die Verbindung zwischen Client und Proxy. Das schützt vor Mitlesen im Übertragungsweg. Es schützt aber nicht davor, dass ein kompromittiertes Backend-Konto oder ein Schwachstellens in Nextcloud zu einem Datenleck führt. Die Absicherung eines öffentlichen Diensts besteht aus mehreren Ebenen: HTTPS, starke Passwörter, 2FA, Authentifizierungsschicht vor dem Proxy, Fail2ban, und regelmäßige Updates.

Die grundlegenden Maßnahmen sind in Homelab absichern: Der komplette Sicherheits-Guide 2026 zusammengefasst. Caddy ist ein Baustein in diesem Gesamtkonzept, nicht die gesamte Lösung.

Caddy-Dienst aufsetzen: Der praktische Ablauf

Der Vollständigkeit halber ein kompakter Ablauf, wie Caddy auf einer Linux-Maschine (Debian/Ubuntu) als Dienst eingerichtet wird:

1. Caddy installieren. Das offizielle Installationsskript von Caddys Website bringt die aktuelle Version und legt einen systemd-Dienst an.

2. Caddyfile anlegen. /etc/caddy/Caddyfile ist der Standard-Ort; systemd gibt Caddy diesen Pfad mit.

3. DNS vorbereiten. Subdomains auf die öffentliche IP zeigen lassen; Port 80 und 443 in der Firewall und im Router freigeben.

4. Ersten Start testen. sudo caddy run --config /etc/caddy/Caddyfile testet ohne Dauerhaftigkeit. Im Log werden Zertifikats-Anfragen und etwaige Fehler sichtbar.

5. Als Dauerhaften Dienst. Sobald die Konfiguration gilt, Caddy über systemctl enable --now caddy aktivieren.

Nach dem ersten Start läuft die Zertifikatsanfrage im Hintergrund. Caddy aktualisiert das Zertifikat automatisch, wenn es ansteht. Ein separater Certbot-Cron ist nicht nötig.

Fazit

Caddy vereinfacht die HTTPS-Absicherung eines Homelab-Proxys auf bruchteilhaftes Aufwand im Vergleich zu Nginx-basierten Setups. Die automatische ACME-Integration, die klare Caddyfile-Syntax und die eingebaute Erneuerung von Zertifikaten machen Caddy zu einer sehr wiedererkennbaren Wahl für Homelaber, die nicht jeden Tag am Zertifikats-Lifecycle arbeiten wollen.

Gleichzeitig ist Caddy kein Zauberstab. Ein Reverse Proxy macht Dienste erreichbar, aber er entscheidet nicht darüber, welche Dienste es überhaupt geben soll. Die Entscheidung, welche Dienste öffentlich gemacht werden, welche durch eine Auth-Schicht geschützt werden und welche nur im lokalen Netzwerk bleiben, ist eine bewusste Architektur-Entscheidung. Caddy unterstützt diese Entscheidung, indem er HTTPS ohne viel Aufwand bereitstellt.

Für das nächste Homelab-Projekt lohnt sich ein Blick auf die bestehende Infrastruktur: Welche Dienste laufen schon, welche Subdomains sind sinnvoll, welche DNS-Einträge fehlen, welche Ports sind frei? Mit diesen Voraussetzungen ist Caddy innerhalb einer Stunde produktiv einsatzbereit.

FAQ: Häufige Fragen zu Caddy als Reverse Proxy

Warum sollte ich Caddy statt Nginx Proxy Manager wählen?

Nginx Proxy Manager bietet eine grafische Oberfläche, die ohne CLI-Kenntnisse auskommt. Caddy bietet keine UI, dafür die einfachste Konfiguration für HTTPS überhaupt – ein Caddyfile mit wenigen Zeilen deckt mehrere Dienste ab, und Zertifikats-Erneuerung läuft ohne extra Tool. Wenn du Konfigurationsdateien schreiben kannst und das geringste Setup suchst, ist Caddy die effizientere Wahl. Wenn du eine Klick-Oberfläche bevorzugst, ist NPM besser.

Funktioniert Caddy ohne öffentliche IP?

Nicht mit Let's Encrypt über HTTP-Challenge. Wenn kein Port 80 von außen erreichbar ist, muss entweder die DNS-Challenge mit einem passenden DNS-Provider-Plugin genutzt werden oder ein eigenes Zertifikat (eigene CA) für interne Dienste. Für rein lokale Dienste mit eigener CA ist das ein valides Muster.

Was passiert, wenn das Let's Encrypt-Zertifikat abläuft?

Caddy erneuert Zertifikate automatisch im Hintergrund, solange die Domäne weiterhin korrekt aufgelöst wird und die Challenge-Methode funktioniert. Trotzdem lohnt es sich, einmalig zu prüfen, ob die Erneuerung auch ohne manuelles Eingreifen gelingt – zum Beispiel indem man nach dem ersten Erneuern schaut, ob das alte Zertifikat tatsächlich ersetzt wurde. Ein abgelaufenes Zertifikat zeigt der Browser als Warnung an, der Dienst bleibt aber technisch erreichbar.

Kann ich mehrere Reverse Proxys nebeneinander betreiben?

Ja, aber sie dürfen nicht gleichzeitig auf denselben Port hören. Zwei Proxys auf Port 443 würden sich gegenseitig blockieren. Parallel-Betrieb macht nur Sinn, wenn sie unterschiedliche Ports nutzen oder wenn sie klar getrennte Subdomains bearbeiten – was in kleinen Homelabs selten ein gutes Design ist.

Welche Dienste sollte ich nicht hinter Caddy öffentlich machen?

Admin-Oberflächen von Proxmox, NAS-Systemen und Routern sollten nie öffentlich exponiert werden. Dienste ohne stabile Authentifizierung sollten ebenfalls nicht ohne eine Auth-Schicht nach außen. Für den Rest gilt: Je sensibler der Dienst, desto stärker die Absicherungsschichten davor.

Benötigt Caddy Docker?

Nein. Caddy läuft problemlos als systemd-Dienst auf einer VM oder LXC-Instanz, ohne Container. Docker ist eine mögliche Laufzeitumgebung, aber nicht die einzige oder empfohlene.

Wie vergleicht sich Caddy mit Traefik für Homelab?

Beide bieten automatisches HTTPS. Caddy ist direkter – ein Caddyfile und fertig. Traefik ist stärker im dynamischen Container-Discovery-Bereich: Bei Docker-basierten Setups erkennt Traefik neue Container automatisch über Labels. Wenn alle Dienste in Containern laufen und ständig hinzukommen oder wegfallen, ist Traefik oft die praktischere Wahl. Für statische Dienste auf einer VM oder LXC favorisiert man Caddy.

Hinweis: Dieser Artikel ist redaktioneller Inhalt und enthält keine Affiliate- oder Partner-Links. Alle Angaben entsprechen dem Stand 2026 und können sich ändern.