Caddy: der Go-Webserver, bei dem TLS die Voreinstellung ist

Caddy: automatisches HTTPS als Voreinstellung, nicht als Zusatzmodul

Caddy beschreibt sich als erweiterbare Serverplattform, die TLS standardmäßig verwendet, die README-Überschrift heißt Every site on HTTPS. Automatisches HTTPS ist damit kein nachträgliches Werkzeug, sondern Teil des Grundvertrags: ZeroSSL und Let's Encrypt bedienen öffentliche Namen, eine vollständig verwaltete lokale CA deckt interne Namen und IP-Adressen ab. Dazu kommen Multi-Issuer-Fallback, Koordination mit anderen Caddy-Instanzen im Cluster und Unterstützung für Encrypted ClientHello.

HTTP/1.1, HTTP/2 und HTTP/3 sind standardmäßig an. Der Server läuft laut README überall ohne externe Abhängigkeiten, nicht einmal libc wird gebraucht, was statische Deployments auf beliebigen Basisimages erlaubt. 75284 Sterne und 4920 Forks machen das Projekt zu einer der meistbeobachteten Go-Server-Codebasen, die Zahl von 266 offenen Issues ist für diese Größe unauffällig. Die Aussage, Caddy bleibe betriebsbereit, wenn andere Server an TLS-, OCSP- oder Zertifikatsproblemen kranken, ist eine Selbstbehauptung ohne verlinkte Messwerte im README, sie erklärt aber den Entwurf: Zertifikatspfade gelten als eigene Fehlerquelle und werden entsprechend abgesichert.

Caddyfile, JSON und die API für dynamische Konfigurationswechsel

Die Konfiguration folgt einem klaren Schichtmodell. Native Sprache ist JSON, die JSON-API erlaubt dynamische Änderungen im laufenden Betrieb. Die Caddyfile ist die menschenlesbare Kurzfassung für die üblichen Fälle, und Config-Adapter übersetzen Fremdformate, das README nennt JSON5, YAML, TOML und sogar NGINX-Konfigurationen als mögliche Eingänge, in Caddy-JSON.

Bemerkenswert ist der Grundsatz, den die Übersicht hervorhebt: Fast die gesamte Konfiguration liegt in einem einzigen Konfigurationsdokument statt verteilt über CLI-Flags, Umgebungsvariablen und separate Dateien. Das vereinfacht Verwaltung und Audit, weil der Zustand des Servers an einer Stelle lesbar ist. Für die vollständige Struktur verweist die README auf die Doku unter caddyserver.com/docs/, deren Quelltext ihrerseits im Repository caddyserver/website liegt. Wer von NGINX kommt, sollte den Adapter als Brücke nutzen und nicht als Dauerzustand, denn die JSON-Semantik, etwa bei Header-Manipulation oder Retry-Verhalten, weicht an Stellen ab, die ein Übersetzer nur mühsam verdeckt.

Build aus dem Quellcode: go build in cmd/caddy und setcap für niedrige Ports

Wer selbst baut, braucht Go 1.25.0 oder neuer. Für die Entwicklung genügt git clone "https://github.com/caddyserver/caddy.git", dann cd caddy/cmd/caddy/ und go build. Die README warnt, dass dieser Weg keine korrekten Versionsinformationen einbettet, und verweist für das echte Build auf xcaddy.

Ein Betriebsdetail verdient Aufmerksamkeit: Ohne Konfiguration versucht Caddy, an niedrige Ports zu binden, was auf Linux erhöhte Rechte verlangt. Die README schlägt sudo setcap cap_net_bind_service=+ep ./caddy vor, für go run mit temporären Binaries gibt es das mitgelieferte setcap.sh, aufgerufen als go run -exec ./setcap.sh main.go. Wer das Passwort-Tippen loswerden will, kann per sudo visudo eine NOPASSWD-Regel für /usr/sbin/setcap setzen, das README räumt selbst ein, dass man das nur tun sollte, wenn man weiß, was man tut. Tests laufen über go test ./... oder modulweise, etwa go test ./modules/caddyhttp/tracing/.

xcaddy build: Plugin-Imports, Version-Pins und -tags=nobadger,nomysql,nopgx

Mit dem Builder-Werkzeug xcaddy automatisiert xcaddy build die Schritte, die von Hand mühsam wären: einen neuen Ordner anlegen, Caddys main.go aus cmd/caddy hineinkopieren, Plugin-Imports hinzufügen, mit go mod init caddy ein Modul initialisieren und kompilieren. Optional lässt sich die Version pinnen, go get github.com/caddyserver/caddy/v2@version mit einem Git-Tag, Commit oder Branch-Namen.

Plugins kommen über den blinden Import _ "import/path/here" in die Binary, das ist der dokumentierte Weg, um Caddy um eigene Module zu erweitern, ohne den Hauptquelltext zu forken. Beim Kompilieren stehen Build-Tags bereit, go build -tags=nobadger,nomysql,nopgx schließt bestimmte Standardmodule aus. Diese Kontrolle ist der Preis und der Vorteil der Go-Modul-Architektur: Die fertige Binary enthält genau das, was der Betreiber hineingibt. Einfacherer Einstieg bleibt der Download aus den GitHub Releases, das Binary wandert in den PATH, fertig.

CertMagic und die tls-App: Cluster-Koordination und OCSP-Absicherung

Die Zertifikatsautomatik ruht auf CertMagic, das als eigenständiges Projekt auf github.com/caddyserver/certmagic geführt wird und im README als treibende Kraft verlinkt ist. Als Apps sind standardmäßig tls und http enthalten, Go-Programme, die als Caddy-Module implementiert sind, profitieren sofort von automatisierter Dokumentation, Online-Konfigurationsänderungen über die API und der Vereinheitlichung mit anderen Caddy-Apps.

Für Clusterbetrieb koordinieren mehrere Caddy-Instanzen ihre Zertifikate, so dass keine zwei Knoten dieselbe Bestellung doppelt stellen. Der Multi-Issuer-Fallback springt aus, wenn ein CA-Weg klemmt, und die OCSP-Verwaltung gehört zum selben Pfad, über den die README die Robustheitsbehauptung begründet. Genau hier liegt der praktische Unterschied zu manuell betriebenem nginx oder Apache: Die Fehlerklasse ausgelaufener Zertifikate, übersehener Erneuerungen und inkonsistenter Cluster-Zustände ist in Caddy Teil des Runtime-Vertrags, nicht ein Cronjob-Verhalten, das man separat beweisen muss.

Geschichte seit 2014, Marke Stack Holdings und Support über Ardan Labs

Matthew Holt begann 2014 mit der Entwicklung von Caddy während des Informatikstudiums an der Brigham Young University, laut README war Caddy der erste Webserver, der HTTPS automatisch und standardmäßig verwendete. Heute sind es Hunderte Mitwirkende, und die README zählt verarbeitete Anfragen in Billionen sowie verwaltete TLS-Zertifikate in Millionen, beide Zahlen sind Selbstauskunft.

Organisatorisch ist Caddy ein Projekt von ZeroSSL, das zu HID Global gehört, der Name Caddy ist eine eingetragene Marke der Stack Holdings GmbH. Die Apache-2.0-Lizenz erlaubt Nutzung und Ableitung ohne Copyleft-Verpflichtung. Beim Support ist das Modell dreistufig: Unternehmen, die Caddy produktiv einsetzen, empfiehlt die README vorab einen Supportvertrag über Ardan Labs, Einzelpersonen finden im Forum caddy.community kostenlose Hilfe, ausdrücklich als Freizeit- und Wohlwollen-Arbeit gekennzeichnet, Sponsoren bekommen private Hilfe. Der Issue-Tracker bleibt Bugs und Feature-Wünschen vorbehalten, Supportfragen wandern ins Forum. Wer das akzeptiert und den Zertifikatsbetrieb über die tls-App abwickelt, bekommt eine konsequent durchdachte Serverplattform, deren Stärke in genau dem Bereich liegt, in dem klassische Webserver Handarbeit verlangen.

Redaktionelles Fazit

Caddy passt zu Betreibern, die Zertifikatsverwaltung auslagern wollen und kleine bis mittlere Site-Zahlen über Caddyfile oder JSON-API abdecken. Ungeeignet ist es dort, wo ein Umbau auf Go-Module oder Plugin-Builds das Team überfordert oder bestehende NGINX-Konfigurationskulturen ohnehin weitergetragen werden sollen. Vor dem Umstieg sollte man eine Testinstanz über die JSON-API laden, den Zertifikatsfluss im Log verfolgen und prüfen, ob Port 443 im eigenen Setup über setcap oder Systemd-Lösungen bedient werden kann.

Offizielle Quellen

1. Official documentation
2. Official README
3. Project repository
4. Release notes