Caddy ist der Webserver, den du dir immer gewünscht hast - du wusstest es nur noch nicht. Während Apache und Nginx dich mit ellenlangen Konfigurationsdateien und manueller SSL-Einrichtung quälen, macht Caddy einfach sein Ding: Du gibst eine Domain an, Caddy holt sich automatisch ein SSL-Zertifikat von Let's Encrypt, und deine Website ist sofort per HTTPS erreichbar. Keine Certbot-Installation, keine Cronjobs für Zertifikatserneuerung, kein Kopfzerbrechen.
Die Geschichte von Caddy beginnt 2015, als Matt Holt frustriert von der Komplexität bestehender Webserver einen neuen Ansatz wagte. Seine Vision: Ein Webserver, der sichere Defaults hat und HTTPS zum Standard macht, nicht zur Ausnahme. Geschrieben in Go, kompiliert zu einer einzigen ausführbaren Datei, ohne externe Abhängigkeiten. Was als Hobbyprojekt begann, ist heute ein ernstzunehmender Webserver, der von Unternehmen wie Cloudflare, Dell und Mozilla eingesetzt wird.
Caddy richtet sich an Entwickler, die Einfachheit schätzen. Wenn du keine Lust hast, stundenlang Nginx-Konfigurationen zu debuggen oder dich durch Apache-Module zu wühlen, ist Caddy deine Lösung. Mit nur zwei Zeilen Konfiguration hast du einen produktionsreifen Webserver mit automatischem HTTPS, HTTP/2 und HTTP/3. Das klingt zu gut, um wahr zu sein? Lies weiter.
Technische Übersicht: Was Caddy unter der Haube macht
Architektur: Single Binary, Zero Dependencies
Caddy ist in Go geschrieben und wird zu einer einzigen Binärdatei kompiliert. Das bedeutet: keine Abhängigkeiten, keine Library-Konflikte, keine komplexe Installation. Du lädst eine Datei herunter, machst sie ausführbar, fertig. Diese Einfachheit macht Caddy besonders attraktiv für Container-Deployments und automatisierte Infrastruktur.
Die Architektur basiert auf einem modularen Plugin-System. Alles in Caddy - vom HTTP-Server über TLS bis zum Logging - ist ein Modul. Du kannst Caddy mit zusätzlichen Modulen erweitern oder eigene schreiben. Die Standard-Distribution enthält alle Module, die du für typische Webserver-Aufgaben brauchst.
Protokolle: HTTP/3 standardmäßig
Caddy unterstützt alle modernen Protokolle:
- HTTP/1.1: Der klassische Standard, vollständig unterstützt
- HTTP/2: Standardmäßig aktiviert für alle HTTPS-Verbindungen
- HTTP/3: Seit Caddy v2.6 standardmäßig aktiviert - du musst nichts konfigurieren
- QUIC: Das Transportprotokoll hinter HTTP/3, nativ integriert
Während bei Nginx HTTP/3 erst seit kurzem stabil ist und manuell aktiviert werden muss, liefert Caddy HTTP/3 einfach mit. Deine Besucher profitieren automatisch von schnelleren Ladezeiten, besonders bei schlechter Netzwerkverbindung.
Automatisches HTTPS: Das Killerfeature
Das wichtigste Feature von Caddy ist automatisches HTTPS. Sobald du eine Domain in deiner Konfiguration angibst, passiert Folgendes:
- Caddy erkennt, dass ein Zertifikat benötigt wird
- Caddy stellt eine ACME-Challenge bereit (HTTP-01 oder TLS-ALPN-01)
- Let's Encrypt oder ZeroSSL validiert die Domain
- Caddy lädt das Zertifikat herunter und konfiguriert TLS
- Caddy richtet automatische Erneuerung ein (30 Tage vor Ablauf)
- HTTP wird automatisch auf HTTPS umgeleitet
Das alles passiert ohne eine einzige Zeile Konfiguration. Caddy unterstützt sowohl Let's Encrypt als auch ZeroSSL als Certificate Authorities - und wechselt automatisch, falls eine nicht erreichbar ist.
Das ACME-Protokoll (Automatic Certificate Management Environment) ist der offene Standard, den Caddy für die Zertifikatsverwaltung nutzt. Anders als bei manuellen Lösungen wie Certbot ist ACME in Caddy nativ integriert und erfordert keine externen Tools.
Caddyfile: Die elegante Konfiguration
Die Konfiguration ist der Bereich, in dem Caddy wirklich glänzt. Das Caddyfile ist so intuitiv, dass du es beim ersten Lesen verstehst - ohne Dokumentation.
Caddyfile vs. JSON: Zwei Wege zum Ziel
Caddy bietet zwei Konfigurationsformate:
Caddyfile: Das menschenfreundliche Format. Einfach zu schreiben, einfach zu lesen. Perfekt für die meisten Anwendungsfälle.
JSON: Das maschinenfreundliche Format. Vollständiger Zugriff auf alle Caddy-Features, ideal für automatisierte Deployments und komplexe Konfigurationen.
Das Caddyfile wird intern in JSON konvertiert. Du kannst dir die generierte JSON-Konfiguration jederzeit mit caddy adapt anzeigen lassen. Für diesen Artikel konzentrieren wir uns auf das Caddyfile, weil es das ist, was du in 95% der Fälle verwenden wirst.
Grundstruktur: Einfacher geht's nicht
Die minimale Konfiguration für eine statische Website:
example.com {
root * /var/www/html
file_server
}
Das war's. Drei Zeilen. Caddy holt automatisch ein SSL-Zertifikat, aktiviert HTTP/2 und HTTP/3, leitet HTTP auf HTTPS um und liefert die Dateien aus /var/www/html aus.
Vergleiche das mit der entsprechenden Nginx-Konfiguration: Du bräuchtest mindestens 20-30 Zeilen plus Certbot-Einrichtung.
Reverse Proxy: Eine Zeile
Ein Reverse Proxy vor deiner Node.js-Anwendung:
api.example.com {
reverse_proxy localhost:3000
}
Fertig. HTTPS automatisch, WebSocket-Support automatisch, Header automatisch korrekt gesetzt. Caddy erkennt, dass du einen Upstream-Server hast, und konfiguriert alles Nötige.
Für mehrere Backends mit Load Balancing:
api.example.com {
reverse_proxy localhost:3000 localhost:3001 localhost:3002 {
lb_policy round_robin
health_uri /health
health_interval 10s
}
}
Mehrere Domains, eine Datei
Du kannst mehrere Websites in einem Caddyfile verwalten:
# Hauptwebsite
example.com {
root * /var/www/example
file_server
}
# Blog
blog.example.com {
root * /var/www/blog
file_server
encode gzip
}
# API
api.example.com {
reverse_proxy localhost:3000
}
# Entwicklungsumgebung (lokales HTTPS!)
localhost {
root * /home/dev/projekt
file_server browse
}
Nützliche Direktiven
Hier einige häufig verwendete Direktiven:
example.com {
root * /var/www/html
# Gzip/Brotli-Komprimierung
encode gzip zstd
# Datei-Server
file_server
# PHP-FPM
php_fastcgi unix//run/php/php8.3-fpm.sock
# Weiterleitungen
redir /old-page /new-page permanent
# Rewrite-Regeln
rewrite /api/* /index.php
# Basic Auth
basicauth /admin/* {
admin $2a$14$... # bcrypt-Hash
}
# Headers setzen
header {
X-Frame-Options "SAMEORIGIN"
X-Content-Type-Options "nosniff"
-Server # Server-Header entfernen
}
# Logging
log {
output file /var/log/caddy/example.log
format json
}
}
Matcher: Flexible Pfad-Bedingungen
Caddy verwendet Matcher, um Direktiven auf bestimmte Anfragen anzuwenden:
example.com {
root * /var/www/html
file_server
# Nur für /api/* Pfade
@api path /api/*
reverse_proxy @api localhost:3000
# Statische Dateien cachen
@static path *.css *.js *.png *.jpg *.webp
header @static Cache-Control "public, max-age=31536000, immutable"
# Bestimmte User-Agents blockieren
@bots header User-Agent *bot*
respond @bots 403
}
Installation & Setup
Caddy lässt sich auf verschiedene Arten installieren. Hier die gängigsten Methoden.
Debian / Ubuntu
Die empfohlene Installation über das offizielle Repository:
sudo apt install -y debian-keyring debian-archive-keyring apt-transport-https curl
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/gpg.key' | sudo gpg --dearmor -o /usr/share/keyrings/caddy-stable-archive-keyring.gpg
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/debian.deb.txt' | sudo tee /etc/apt/sources.list.d/caddy-stable.list
sudo apt update
sudo apt install caddy
Nach der Installation läuft Caddy als Systemd-Service und zeigt eine Willkommensseite unter http://localhost.
CentOS / Fedora / RHEL
dnf install 'dnf-command(copr)'
dnf copr enable @caddy/caddy
dnf install caddy
Docker
Für Container-Umgebungen:
docker run -d \
--name caddy \
-p 80:80 \
-p 443:443 \
-p 443:443/udp \
-v caddy_data:/data \
-v caddy_config:/config \
-v /pfad/zu/Caddyfile:/etc/caddy/Caddyfile \
-v /pfad/zu/site:/srv \
caddy
Der Port 443/udp ist wichtig für HTTP/3 (QUIC). Die Volumes caddy_data und caddy_config speichern Zertifikate und Konfiguration persistent.
Ein typisches docker-compose.yml:
version: "3.9"
services:
caddy:
image: caddy:latest
restart: unless-stopped
ports:
- "80:80"
- "443:443"
- "443:443/udp"
volumes:
- ./Caddyfile:/etc/caddy/Caddyfile
- ./site:/srv
- caddy_data:/data
- caddy_config:/config
volumes:
caddy_data:
caddy_config:
Single Binary Download
Für minimale Installationen oder Systeme ohne Paketmanager:
# Download der neuesten Version
curl -OL "https://github.com/caddyserver/caddy/releases/latest/download/caddy_linux_amd64.tar.gz"
tar xzf caddy_linux_amd64.tar.gz
sudo mv caddy /usr/local/bin/
sudo chmod +x /usr/local/bin/caddy
Systemd-Service einrichten
Falls du Caddy manuell installiert hast:
# Benutzer und Gruppe erstellen
sudo groupadd --system caddy
sudo useradd --system --gid caddy --create-home --home-dir /var/lib/caddy --shell /usr/sbin/nologin caddy
# Verzeichnisse erstellen
sudo mkdir -p /etc/caddy
sudo mkdir -p /var/log/caddy
# Systemd-Unit
sudo tee /etc/systemd/system/caddy.service << 'EOF'
[Unit]
Description=Caddy
Documentation=https://caddyserver.com/docs/
After=network.target network-online.target
Requires=network-online.target
[Service]
Type=notify
User=caddy
Group=caddy
ExecStart=/usr/local/bin/caddy run --environ --config /etc/caddy/Caddyfile
ExecReload=/usr/local/bin/caddy reload --config /etc/caddy/Caddyfile
TimeoutStopSec=5s
LimitNOFILE=1048576
PrivateTmp=true
ProtectSystem=full
AmbientCapabilities=CAP_NET_BIND_SERVICE
[Install]
WantedBy=multi-user.target
EOF
sudo systemctl daemon-reload
sudo systemctl enable caddy
sudo systemctl start caddy
Wichtige Befehle
# Status prüfen
sudo systemctl status caddy
# Konfiguration testen
caddy validate --config /etc/caddy/Caddyfile
# Konfiguration neu laden (ohne Neustart)
sudo systemctl reload caddy
# Logs anzeigen
journalctl -u caddy -f
# Als JSON anzeigen (intern verwendet)
caddy adapt --config /etc/caddy/Caddyfile
Typische Einsatzszenarien
Caddy ist vielseitig einsetzbar. Hier sind die häufigsten Anwendungsfälle mit produktionsreifen Konfigurationen.
Reverse Proxy für Node.js, Python, Go
Das klassische Setup: Caddy als Frontend vor deiner Anwendung.
api.example.com {
reverse_proxy localhost:3000 {
# Health Checks
health_uri /health
health_interval 30s
health_timeout 5s
# Header anpassen
header_up X-Real-IP {remote_host}
header_up X-Forwarded-Proto {scheme}
}
}
Für mehrere Services mit Path-basiertem Routing:
example.com {
# Frontend (React/Vue/Svelte)
reverse_proxy /api/* localhost:3000
reverse_proxy /auth/* localhost:4000
# Statisches Frontend
root * /var/www/frontend/dist
try_files {path} /index.html
file_server
}
Statische Websites (Hugo, Jekyll, Next.js Export)
Für statische Site-Generatoren ist Caddy perfekt:
blog.example.com {
root * /var/www/blog/public
encode gzip zstd
# SPA-Fallback für clientseitiges Routing
try_files {path} /index.html
file_server
# Cache-Header für statische Assets
@static path *.css *.js *.woff2 *.png *.jpg *.webp *.svg
header @static Cache-Control "public, max-age=31536000, immutable"
}
Development Server mit lokalem HTTPS
Einer der unterschätzten Vorteile von Caddy: Lokales HTTPS für Entwicklung. Caddy generiert automatisch ein lokales Root-Zertifikat und signiert Zertifikate für localhost.
localhost {
root * /home/dev/projekt
file_server browse
php_fastcgi unix//run/php/php8.3-fpm.sock
}
Beim ersten Start fragt Caddy nach dem Root-Passwort, um das CA-Zertifikat zu installieren. Danach funktioniert HTTPS auf localhost ohne Browser-Warnungen - perfekt für Service Worker, Secure Cookies und APIs, die HTTPS erfordern.
API Gateway mit Load Balancing
api.example.com {
# Load Balancing über mehrere Backend-Instanzen
reverse_proxy localhost:3001 localhost:3002 localhost:3003 {
lb_policy least_conn
lb_try_duration 5s
lb_try_interval 250ms
# Passive Health Checks
fail_duration 30s
max_fails 3
unhealthy_latency 5s
# Active Health Checks
health_uri /health
health_interval 10s
}
# Rate Limiting
rate_limit {remote.ip} 100r/m
# CORS für API
header {
Access-Control-Allow-Origin *
Access-Control-Allow-Methods "GET, POST, PUT, DELETE, OPTIONS"
Access-Control-Allow-Headers "Content-Type, Authorization"
}
}
WordPress mit PHP-FPM
Auch PHP-Anwendungen wie WordPress laufen problemlos:
wordpress.example.com {
root * /var/www/wordpress
encode gzip
# PHP-FPM
php_fastcgi unix//run/php/php8.3-fpm.sock
file_server
# Sicherheit
@forbidden path /wp-config.php /xmlrpc.php /.* /wp-admin/includes/*
respond @forbidden 403
# Statische Assets cachen
@static path *.css *.js *.png *.jpg *.gif *.ico *.woff2
header @static Cache-Control "public, max-age=604800"
}
Sicherheit: Secure by Default
Caddy wurde von Anfang an mit Sicherheit im Fokus entwickelt. Die Defaults sind so sicher, dass du in den meisten Fällen nichts ändern musst.
Automatische TLS-Zertifikate
Das offensichtlichste Sicherheitsfeature: Jede Domain bekommt automatisch ein gültiges TLS-Zertifikat. Keine vergessenen Erneuerungen, keine abgelaufenen Zertifikate, kein manuelles Eingreifen. Caddy erneuert Zertifikate 30 Tage vor Ablauf und versucht es bei Fehlern automatisch erneut.
HSTS: Automatisch aktiviert
Caddy aktiviert automatisch HTTP Strict Transport Security (HSTS) für alle HTTPS-Verbindungen. Browser merken sich, dass deine Domain nur über HTTPS erreichbar ist, und verhindern Man-in-the-Middle-Angriffe.
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
Sichere TLS-Defaults
Caddy verwendet automatisch die sichersten TLS-Einstellungen:
- TLS 1.2 und 1.3 (kein TLS 1.0/1.1)
- Moderne Cipher Suites (nur AEAD-basiert)
- OCSP Stapling automatisch aktiviert
- Forward Secrecy für alle Verbindungen
Im SSL Labs Test erreicht eine Standard-Caddy-Installation ein A+ Rating ohne jegliche Konfiguration.
Automatische HTTP-zu-HTTPS-Umleitung
Alle HTTP-Anfragen werden automatisch auf HTTPS umgeleitet. Du musst dafür keine Regel schreiben - Caddy macht das von selbst.
Zusätzliche Security-Header
Für maximale Sicherheit kannst du weitere Header hinzufügen:
example.com {
header {
X-Frame-Options "SAMEORIGIN"
X-Content-Type-Options "nosniff"
X-XSS-Protection "1; mode=block"
Referrer-Policy "strict-origin-when-cross-origin"
Permissions-Policy "geolocation=(), microphone=(), camera=()"
Content-Security-Policy "default-src 'self'"
-Server # Server-Header komplett entfernen
}
}
Vor- und Nachteile von Caddy
Vorteile
Zero-Config HTTPS Das wichtigste Argument für Caddy. Automatische Zertifikate von Let's Encrypt oder ZeroSSL ohne jede Konfiguration. Keine Certbot-Installation, keine Cronjobs, keine Sorgen um abgelaufene Zertifikate.
Extrem einfache Syntax Das Caddyfile ist so intuitiv, dass du keine Dokumentation brauchst. Ein Reverse Proxy ist eine Zeile, eine statische Website drei Zeilen. Die Lernkurve ist praktisch nicht vorhanden.
Single Binary Eine einzige Datei ohne Abhängigkeiten. Keine Library-Konflikte, keine komplexen Installationen. Perfekt für Container und automatisierte Deployments.
HTTP/3 standardmäßig Während andere Webserver HTTP/3 noch als experimentell behandeln, ist es bei Caddy seit v2.6 der Standard. Deine Besucher profitieren automatisch von schnelleren Verbindungen.
Moderne Defaults Alles, was Caddy tut, ist auf Sicherheit und Performance optimiert. TLS 1.3, HSTS, OCSP Stapling, Gzip - alles standardmäßig aktiviert.
Live Configuration Reload
Konfigurationsänderungen werden ohne Verbindungsabbrüche übernommen. caddy reload ist Zero-Downtime.
Nachteile
Kleinere Community Caddy hat eine aktive, aber kleinere Community als Apache oder Nginx. Es gibt weniger Stack Overflow-Antworten, weniger Tutorials und weniger fertige Konfigurationen zum Kopieren.
Weniger Module als Apache Apache hat tausende Module für jeden erdenklichen Anwendungsfall. Caddy hat weniger, dafür sind die vorhandenen gut gepflegt.
Weniger Hosting-Support Auf Shared Hosting wirst du Caddy selten finden. Die meisten Hoster setzen auf Apache oder Nginx. Für Caddy brauchst du einen eigenen Server oder Container.
Dokumentation teils lückenhaft Die offizielle Dokumentation ist gut, aber nicht so umfangreich wie bei Nginx oder Apache. Für Edge Cases musst du manchmal im Forum oder GitHub suchen.
Geringere Bekanntheit In Vorstellungsgesprächen wird nach Nginx- oder Apache-Erfahrung gefragt, selten nach Caddy. Das ändert sich langsam, aber Caddy ist noch nicht mainstream.
Fazit: Der Webserver für pragmatische Entwickler
Caddy ist der Webserver, den du verwendest, wenn du einfach deine Arbeit erledigen willst. Keine stundenlangen Konfigurationen, keine manuellen SSL-Zertifikate, keine Kopfschmerzen. Du schreibst drei Zeilen, und deine Website ist online - mit HTTPS, HTTP/3 und allen modernen Features.
Für wen ist Caddy die richtige Wahl?
- Entwickler, die schnell produktiv sein wollen
- Kleine bis mittlere Projekte, bei denen Time-to-Market wichtiger ist als Micro-Optimierung
- Reverse-Proxy-Setups vor Node.js, Python oder Go
- Lokale Entwicklung mit echtem HTTPS
- Container-Deployments, bei denen eine Single Binary goldwert ist
Wann solltest du bei Nginx oder Apache bleiben?
- Du brauchst sehr spezifische Module, die Caddy nicht bietet
- Dein Team hat jahrelange Nginx/Apache-Erfahrung und keine Zeit umzulernen
- Du arbeitest in einer Umgebung mit strengen Compliance-Anforderungen, die etablierte Software verlangen
Für die meisten neuen Projekte ist Caddy meine Empfehlung. Die Zeitersparnis durch automatisches HTTPS allein rechtfertigt den Wechsel. Und wenn du einmal mit dem Caddyfile gearbeitet hast, willst du nie wieder zurück zu den verschachtelten Blöcken von Nginx oder den kryptischen Direktiven von Apache.
Zurück zum Webserver-Vergleich 2026
Weiterführende Ressourcen
Hier findest du weitere Informationen zu Caddy und verwandten Themen:
- Offizielle Caddy-Dokumentation - Die umfassende Referenz direkt von Caddy
- Caddy Community Forum - Hilfe und Diskussionen
- Nginx als Alternative - Der Performance-Champion im Detail
- Traefik für Container - Kubernetes-native Alternative
Letzte Aktualisierung: März 2026