Skip to content

Instantly share code, notes, and snippets.

@theseer
Created November 25, 2025 14:42
Show Gist options
  • Select an option

  • Save theseer/ec19f5afd68d278471d651709ba62087 to your computer and use it in GitHub Desktop.

Select an option

Save theseer/ec19f5afd68d278471d651709ba62087 to your computer and use it in GitHub Desktop.
Caddy Server - First Contact - Fragen aus der Session

Caddy Server - First Contact

Offene Fragen nach der Session

  • Wie sieht es bei den Zertifikatserneuerungen aus?

Die werden ebenfalls automatisch durchgeführt, wenn Letsencrypt oder ZeroSSL - bzw eine ACME CA - im Einsatz ist. Kann man aber natürlich auch "klassisch" manuell machen, wenn man das aus irgendwelchen Gründen braucht.

  • Wie sieht das Concurrency-Modell aus? Wird pro Connection / Request ein Go-Routine-Modell verwendet und gibt es bekannte Pitfalls bei enorm vielen gleichzeitigen Verbindungen?

Ja, genau: CaddyServer verwendet Goroutines (epoll + kqueue) und behauptet, problemos hundertausende requests per second verarbeiten zu können. Irgendwann dürften einem vermutlich die File-Descriptoren ausgehen..

  • Wie gut skaliert Caddy mit HTTP/2 und HTTP/3/QUIC in so einem Umfeld – lohnt es sich überhaupt HTTP/3 zu aktivieren?

HTTP/3 ist schon ziemlich anders als HTTP 1.x und 2. Zunächst ist HTTP/3 UDP basiert, d.h. ich habe schon mal grundsätzlich ein deutlich anderes Skalierungsverhalten. Aktuell sind aber noch nicht alle Clients wie Browser in der Lage, auch HTTP/3 basierte Anfragen zu stellen. Ob sich das also lohnt, hängt von der Umgebung ab.

Ich sehe ansonsten gerade nicht, wie genau die verwendete HTTP-Version hier darüberhinaus relevant sein sollte?

  • Welche realistischen Benchmarks gibt es für Caddy bei 10k–50k Requests pro Sekunde mit vielen kleinen Responses?

Habe ich bisher nicht explizit nach geschaut. Es gibt diverse Benchmarks, die Caddy mit anderen Webservern vergleichen und dort schneidet Caddy eigentlich immer ziemlich gut ab. Am Ende des Tages muss man natürlich beachten, dass man nicht an der verfügbaren Bandbreite eine ungewollte Grenze erreicht und die Webserver-Software selbst eigentlich noch schneller sein könnte.

  • Wie war die domain caddy.thephpcc.training eingerichtet und wo lief Caddy? Wie funktioniert HTTPS mit lokalen domains?

*.thephpcc.training und *.demo.thephpcc.training sind Wildcard-DNS-Einträge die auf eine kleine Linux-VM bei Ionos zeigen, die wir für diverse Trainings und Sessions verwenden und in unregelmäßigen Abständen einfach wegwerfen und neu aufsetzen.

Bei lokalen Domains gibt es mehrere Möglichkeiten: Caddy erkennt automatisch "localhost" und erzeugt im default fall ein self signed certificate. Das kann man aber auch massiv aufbohren. Mit DNS Auth z.B. https://github.com/caddy-dns

  • Wie robust ist Caddy beim Reload von Konfigurationen unter Last? Gibt es wirklich Zero-Downtime-Reloads und worauf muss man achten?

Mein Verständnis bei "reload" ist, dass sich Caddy hier identisch verhält wie NGINX: Ein Reload wird für neue Requests sofort verwendet, bereits angenommene Anfragen werden mit der "alten" Konfiguration abgeschlossen. Alles Andere würde für mich auch wenig sinn ergeben.

Spannender Zusatzpunkt vielleicht: Mit der REST-Api und dem PATCHen der Konfiguration ist kein vollständiger Reload notwendig.

  • Gibt es empfohlene Architekturmuster für extrem viele gleichartige Requests? (z. B. mehrere Instanzen hinter einem Load Balancer vs. wenige große Instanzen)

Ich glaube nicht, dass man hier wirklich eine pauschale Aussage treffen kann. Je nach Hardware und Netzwerk kommt vermutlich ein Server eher an das Ende der verfügbaren Bandbreite als an das Ende sonstiger Resourcen. Mit einem LB kommt man da vermutlich also nicht weit. Im Zweifel würde ich zur echten Last-Verteilung in so einem Fall dann mit mehreren IPs, ggfs. (Geo-)Location basierter Verteilung und so anfangen. Das hat aber alles nichts mit Caddy selbst zu tun ;)

Caddy selbst ist Multi-Threaded und kann viele parallele Requests problemlos verarbeiten. Die Frage ist also eher, welche weiteren Faktoren sind für Euch da relevant? Im zweifel braucht Go jetzt marginal mehr Speicher für einen Thread als C, aber ob das für Euch relevant ist, kann ich so von aussen nicht beurteilen. Ich kann euch da aber natürlich gerne beratend unterstützen.

  • Klärung zum Modulsystem - muss man Caddy neu kompilieren, um bestimmte Module zu nutzen? Oder liest caddy module aus einem Verzeichnis?

Klassich musste man Caddy neu kompilieren, wobei das mit dem Build-Werkzeug "xcaddy" vergleichsweise einfach geht. Seit einiger Zeit kann man Module aber auch dynamisch nachladen. Ich habe allerdings bisher noch keine vorkompilierten Pakete gefunden, die man so einfach nachinstallieren könnte. Kommt aber vielleicht noch ;)

  • Welche Tuning-Parameter sind für Hochlast-Szenarien am wichtigsten? (z. B. Keep-Alive-Settings, Buffergrößen, Max Connections, Listener-Konfiguration)

Das hängt leider viel vom konkreten Szenario ab. Hochlast ist ja nicht gleich Hostlast. Im Zweifel genau die genannten Werte an die Anwendung und deren Verhalten anpassen: Wer z.B. nur GET-Request verarbeiten muss und kleine Antworten verschickt, kann sehr stark einschränken und auch extrem knappe Timeouts vorgeben.

  • Welche Limits / Bottlenecks treten typischerweise zuerst auf (CPU, RAM, File-Deskriptoren, Netzwerk, TLS-Handshake)?

Dazu lässt sich pauschal wenig sagen, denn moderne Anwendungen bestehen ja nur zu einem Bruchteil aus statischen Inhalten. Und jeder I/O-Wait kann hier ein Problem werden. Bei rein statischen und im zweifel größeren Dateien würde ich von Netzwerk ausgehen, gefolgt von File-Deskriptoren, wenn man die eher mageren Defaults nicht anpasst.

  • Kann analog zum on_demand_tls ask (was nur für die Erstellung des Zertifikats verwendet wird?) auch ein PHP-Skript abgefragt werden, um zu prüfen ob eine Subdomain aus dem Wildcard überhaupt aufgerufen werden darf und ansonsten einen 404 o.ä. zurückliefern?

Ja, auch das kann man bauen. Das Google Stichwort hier heisst "forward_auth".

  • Kann Caddy im Kompatibilitätsmodus laufen? Also ist es z.B. möglich ihn mit Nginx-Configs zu füttern?

Einen Kompatibilitätsmodus gibt es meinens wissens nach nicht, aber man kann die Nginx config adaptieren lassen. Mehr dazu gäbe es hier: https://github.com/caddyserver/nginx-adapter

  • Frage an den Chat: Hat jemand 'nen Caddy Config-Snippet bei dem ein spezifisches Verzeichnis ein Directory Listing hat – aber ohne Unterverzeichnisse? :-)

Ohne es ausprobiert zu haben: Ich vermute, man könnte hier ein eigenes Template verwenden, dass schlicht Verzeichnisse nicht mit rendert.

  • Gibt es Caddy für Distributionen wie YunoHost die z.B. auf Debian 12 basieren? Vermutlich nur per manueller Installation.

Kann ich leider nichts zu sagen.


Mehr zum Theme Caddy? => https://thephpcc.academy/de/devops-caddyserver-first-contact

@theseer
Copy link
Author

theseer commented Nov 25, 2025

Noch weitere Fragen? Gerne Melden und Termin vereinbaren: https://zeeg.me/thephpcc-ab

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment