Leistungen
Lösungen
Use Cases
Branchen
Tools
Preise
Erstgespräch buchen
Tool im Einsatz

Caddy

Der Webserver, der HTTPS einfach macht. Automatische Let's-Encrypt-Zertifikate, HTTP/3, deklarative Konfiguration — eine konkrete Alternative zu und Traefik für Agenturen und Hoster.

Projekt-Profil

Caddy

Ultimate Server with Automatic HTTPS

Stand: 1. Juni 2026

GitHub-Sterne

73k

Forks

4.8k

Offene Issues

249

Lizenz

Apache-2.0

Aktuelle Version

v2.11.3

Sprache

Go

Erstveröffentlichung
13. Januar 2015
Letzter Commit
29. Mai 2026
→ GitHub-Repository→ Offizielle Website→ Dokumentation

Drittquelle · Wikidata (CC0)

Wikidata-Profil

Caddy

Q24008327

Lizenz

Apache-Lizenz, Version 2.0

→ Wikidata-Eintrag

Was ist Caddy?

Caddy ist ein Webserver und Reverse-Proxy, geschrieben in Go, Open Source unter Apache-2.0. Vergleichbar mit oder Apache — mit einem entscheidenden Unterschied: Let's-Encrypt-Zertifikate werden automatisch geholt, automatisch verlängert, automatisch eingespielt. Kein Certbot, kein Cronjob, kein 90-Tage-Wecker.

Konfiguriert wird über die deklarative Caddyfile-Syntax — drei Zeilen reichen für eine funktionierende HTTPS-Site. Plus: HTTP/3, Brotli, Zstd, Hot-Reload, JSON-API für Automation, Plugin-System via xcaddy. Caddy gibt es seit 2015, Version 2 läuft produktiv bei Cloudflare, Stripe und Mercedes-Benz.

Warum eine Webagentur Caddy nutzt

Eine Webagentur betreut typischerweise 20–50 Kundendomains parallel — WordPress, Statamic, Next.js, Headless-CMS, Online-Shops. Bei bedeutet das: 30 Server-Blocks, 30 Certbot-Pfade, 30 Renewal-Hooks, 30 Möglichkeiten, dass ein Zertifikat unbemerkt abläuft.

Caddy reduziert das auf eine Caddyfile mit Import-Direktive. SSL läuft im Hintergrund, neue Domains gehen mit Hot-Reload live, ohne Service-Restart. Die Agentur tauscht 30 Punkte potenziellen Ausfalls gegen einen Punkt korrekter Automatisierung — eine grobe Vereinfachung der Betriebsverantwortung.

Mandantenfall

Webagentur Pixelhaus

Fünf Mitarbeiter, 30 aktive Kunden-Domains, vor drei Jahren von + Certbot zu Caddy migriert. Vorher: regelmäßig SSL-Ausfälle, weil ein Cronjob lief, ein Hook fehlte oder ein Renewal-Hook das falsche Verzeichnis traf. Jetzt: eine Caddyfile, kein , keine Ausfälle.

Auto-SSL für 30 Kundendomains

Jede neue Kunden-Domain bekommt ein gültiges Let's-Encrypt-Zertifikat ohne manuelles Eingreifen. Verlängerung läuft automatisch, ohne Cron-Jobs, ohne Pre/Post-Hooks, ohne Verzeichnis-Magie.

HTTPS-Erzwingung + www-Redirect

Alle Kunden-Sites müssen konsistent HTTPS erzwingen und www-Subdomain auf Apex umleiten — ohne dass jede Site-Konfiguration den gleichen 8-Zeilen-Boilerplate enthält.

Reverse-Proxy zu Backend-Containern

Hinter den Caddy-Sites laufen PHP-FPM für WordPress, Node-Container für Next.js, Strapi auf eigenen Ports. Caddy soll diese als Reverse-Proxy ansprechen — eine Konfigurationszeile pro Site.

Security-Header zentral

HSTS, X-Frame-Options, X-Content-Type-Options, Referrer-Policy sollen für alle Kunden-Sites mit demselben Default greifen — einzelne Sites dürfen abweichen, der Standard wird einmal gesetzt.

Kompression + HTTP/3

Brotli + Zstd + Gzip-Fallback für moderne Browser, HTTP/3 + QUIC für Mobile. Soll out-of-the-box laufen, ohne separate Module installieren oder kompilieren zu müssen.

Hot-Reload ohne Downtime

Neue Kunden-Domain wird mittags freigeschaltet — kein Service-Restart, keine Sekunde Downtime auf den anderen 29 Sites. Reload muss atomar sein.

Was jetzt im Caddy-Setup läuft

Acht produktive Konfigurations-Muster, die die Agentur seit drei Jahren einsetzt. Jede Vorlage ist ein eigener Caddyfile-Import, kopierfähig für neue Kunden.

WordPress hinter PHP-FPM

Fünf Zeilen Caddyfile: root-Verzeichnis, php_fastcgi auf den lokalen Socket, file_server als Fallback. Auto-SSL, HTTPS-Redirect und HTTP/3 sind implizit dabei. Funktioniert für jede der 18 WordPress-Sites der Agentur identisch.

Next.js SSR via Reverse-Proxy

reverse_proxy auf localhost:3000 oder den Container-Namen. Caddy terminiert SSL, Next.js redet HTTP. Mit einer Direktive zusätzlich werden die richtigen X-Forwarded-Header gesetzt — sonst kein Setup-Aufwand.

Statische Site (file_server)

Astro-, Hugo- oder Eleventy-Build wird in ein Verzeichnis geschoben. Site-Block: root + file_server + try_files für SPA-Routing. Sechs Zeilen für eine vollwertige Static-Site mit HTTPS.

Headless Strapi auf Subdomain

.kundeX.de proxied zu strapi:1337 im Docker-Netzwerk. Encode gzip + zstd für JSON-Responses. CORS-Header werden in Strapi gesetzt, Caddy reicht sie nur durch. Klare Trennung von Web und .

Mailcow Web-UI Subdomain

mail.kundeX.de proxied auf den internen von Mailcow. Wichtig: Auto-SSL für die Mail-Domain ist auch der TLS-Cert für die Mailcow-Services. Eine Domain, eine Konfiguration, kein Mailcow-eigener ACME-Client nötig.

Uptime Kuma Status-Page

status.agentur.de proxied auf das Uptime-Kuma-Backend. Public Status-Page für Kundeneinsicht, eigentliches Admin-UI nur über Tailscale-Subdomain erreichbar. Zwei Caddy-Site-Blocks für ein Tool.

Apex + www + Staging

Eine Site-Definition mit drei Hostnamen: kundeX.de, www.kundeX.de, staging.kundeX.de. Matcher für staging schickt zu einem anderen Backend (PR-Preview-Container). Saubere Multi-Environment-Konfiguration ohne zweite Datei.

Wildcard-DNS + DNS-Challenge

*.preview.agentur.de mit einer Wildcard-Cert per DNS-Challenge gegen den Hetzner-DNS-Provider. Jeder PR bekommt eine eindeutige Preview-URL — alle teilen sich ein Zertifikat. Caddy-Plugin: caddy-dns/hetzner via xcaddy.

Kern-Funktionen von Caddy

Was Caddy als Webserver besonders macht — und welche Funktionen in einem Agentur-Setup tatsächlich tragen.

Automatisches HTTPS

Let's-Encrypt-Zertifikate werden beim ersten Request geholt, automatisch verlängert, automatisch gerotiert. ZeroSSL als Fallback, OCSP-Stapling automatisch. Kein Certbot, kein , kein Renewal-Hook — Caddy ist ACME-Client und Webserver in einem.

HTTP/3 + QUIC out-of-the-box

HTTP/3 ist seit Caddy 2.6 standardmäßig aktiv. Keine extra Module, keine separate UDP-Konfiguration nötig — kompatibel mit jeder aktuellen Mobile-Anwendung. ALPN wird automatisch ausgehandelt.

Caddyfile — deklarativ statt prozedural

Eine Site = ein Block. Eine Direktive = eine Zeile. Keine if-Bedingungen, kein Sed-Magic, kein Quoting-Hölle wie in . Caddyfile ist explizit darauf optimiert, für Menschen lesbar zu sein, nicht für Parser-Optimierung.

Hot-Reload ohne Downtime

`caddy reload` lädt die neue Caddyfile atomar — laufende Verbindungen werden weiter bedient, neue gehen an die neue Konfiguration. Kein Connection-Drop, kein Service-Restart. Bei braucht das genau diese Garantie viel Sorgfalt; bei Caddy ist es der Default.

JSON-Config + Admin-API

Caddyfile ist nur Zucker. Intern ist die Konfiguration ein JSON-Objekt, manipulierbar über eine lokale auf Port 2019. n8n-Workflows, Ansible-Playbooks oder Custom-Scripts können Domains per HTTP-PATCH hinzufügen — vollständig automatisierbar.

Plugin-Ökosystem via xcaddy

xcaddy ist der Caddy-Builder: man wählt Plugins aus dem Registry (DNS-Provider, Auth-Backends, Geo-IP, Rate-Limiting), xcaddy baut ein passendes Caddy-Binary in 30 Sekunden. Über 200 offizielle Plugins, alle Apache-2.0.

Alternativen ehrlich verglichen

Wenn Caddy nicht passt — was sonst?

Drei Webserver am Markt, alle drei produktiv tauglich. Jeder hat einen Grund warum man ihn nutzt — und mindestens einen Grund warum man ihn meidet. Hier die Einordnung ohne Verkaufs-Romantik.

Marktführer

nginx

F5 (vorher NGINX Inc.), BSD-2

  • + Etablierter Marktführer, riesige Community
  • + Extrem performant, gut dokumentiert
  • − Auto-SSL nur via Certbot + Cronjob
  • − Viel Config-Boilerplate, Sed-Magie üblich

Docker-fokussiert

Traefik

Traefik Labs, MIT-Lizenz

  • + Auto-Discovery von Docker-Containern via Labels
  • + Auto-SSL ähnlich wie Caddy
  • − Höhere Konfigurations-Komplexität
  • − Weniger geeignet ohne Container-Orchestrierung

Klassiker

Apache httpd

Apache Foundation, Apache-2.0

  • + 30+ Jahre etabliert, läuft auf allem
  • + Flexibles .htaccess für Shared Hosting
  • − Auto-SSL nur mit mod_md oder Certbot
  • − Für moderne Stack-Architektur überholt

Faustregel: Wer schon kennt und nur eine Handvoll Domains betreibt, hat keinen Wechsel-Druck. Wer 20+ Domains, Auto-SSL und Hot-Reload braucht oder ohne Cert-Bot-Hampelei leben will, ist mit Caddy nach 30 Minuten produktiv. Traefik ist für Docker-zentrische Setups das andere starke Argument — Auswahl ist Geschmackssache.

Pricing

Apache-2.0. Lupenrein. Ohne Sternchen.

Lizenz

Apache-2.0 — eine OSI-anerkannte Open-Source-Lizenz ohne Branding-Klausel, ohne Anti-Konkurrenz-Klausel, ohne Sustainable-Use-Sternchen. Quellcode lesen, ändern, kommerziell verkaufen, alles erlaubt.

Laufende Kosten

Ein VPS, auf dem ohnehin ein Webserver laufen würde. Caddy ersetzt nginx oder Apache 1:1, keine zusätzlichen Lizenz- oder Cloud-Kosten. Hardware-Bedarf identisch zu nginx.

Aufwand

Erste HTTPS-Site live: 3 Minuten (Binary herunterladen, drei Zeilen Caddyfile, starten). Migration einer 30-Domain-Agentur von nginx zu Caddy: 1 Beratungstag inkl. Snippet-Bibliothek und Hot-Reload-Workflow.

Anders als oder ist Caddy klassisches Open Source — kein 'fair-code', keine Custom-Lizenz, keine Branding-Pflicht. Erfrischend. Eine vollständige Apache-2.0-Software, die zehn Jahre stabil ist und bei Cloudflare, Mercedes-Benz und Stripe in Produktion läuft.

Site-Block mit Security-Headern und Brotli

beispiel-shop.de, www.beispiel-shop.de {
  redir https://beispiel-shop.de{uri} permanent

  encode br zstd gzip

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

  root * /var/www/beispiel-shop
  php_fastcgi unix//run/php/php8.3-fpm.sock
  file_server

  log {
    output file /var/log/caddy/shop-access.log
    format json
  }
}
Eine Shop-Domain mit HSTS, X-Frame-Options, Brotli + Zstd-Kompression und JSON-Logging — alles deklarativ, kein Sed-Magic. Quelle: Eigene Praxis, Apache-2.0.

Beispiel-Caddyfile — 30 Kundendomains in einer Datei

{
  email admin@agentur.de
}

import sites/*.caddy

# sites/kundeA-wordpress.caddy
kundeA.de, www.kundeA.de {
  redir https://kundeA.de{uri} permanent
  root * /var/www/kundeA
  php_fastcgi unix//run/php/php8.3-fpm.sock
  file_server
}

# sites/kundeB-nextjs.caddy
kundeB.com {
  reverse_proxy localhost:3000
  header Strict-Transport-Security "max-age=31536000"
}

# sites/kundeC-strapi-api.caddy
api.kundeC.io {
  reverse_proxy strapi:1337
  encode gzip zstd
}
Webagentur-Setup: Globale Defaults, dann ein Import-Sammler. Jede Kunden-Site hat 3–8 Zeilen Caddyfile. SSL automatisch, HTTPS-Redirect implizit. Quelle: Eigene Praxis, Apache-2.0.

Verwandte Themen

Caddy ist die Tür — was steht dahinter?

Caddy ist der Eingangsserver. Workflows orchestriert , Monitoring läuft auf , der KI-Stack hängt am Backend. Das Gesamtbild:

→ n8n (Workflow-Automatisierung)→ Uptime Kuma (Monitoring)→ Übersicht aller Tools

Bereit für den nächsten Schritt?

Kostenloses Erstgespräch. Unverbindlich. In 30 Minuten wissen Sie, ob und wie KI Ihrem Unternehmen helfen kann.

Erstgespräch buchenFörderfähigkeit prüfen
Erstgespräch buchenBAFA-Förderung