Caddy vs Nginx pour un homelab : le reverse proxy qui se debrouille tout seul

Toute l'infra de ce VPS passe par un seul Caddy en frontal : git.geekservers.gg, sso.geekservers.gg, lab.brznet.fr, chacun avec son propre fichier de config dans un dossier sites/ importe par le Caddyfile principal. Ce decoupage en fichiers separes est sous-estime : chaque nouveau service ajoute un fichier, jamais une modification du fichier principal, donc zero risque de casser les vhosts existants en ajoutant le suivant.

La difference concrete avec Nginx, ce n'est pas la performance (les deux tiennent largement la charge d'un homelab), c'est la gestion des certificats. Nginx demande Certbot en parallele, un cron de renouvellement, et une reload manuelle du service. Caddy integre l'ACME client directement : premiere requete sur un nouveau domaine, Caddy demande le certificat Let's Encrypt tout seul via challenge TLS-ALPN-01, et le renouvelle avant expiration sans intervention.

Le point d'attention reel : au demarrage, si le DNS n'est pas encore propage vers le serveur, Caddy tente d'emettre le certificat et echoue, puis part en backoff exponentiel. Un simple caddy reload ne relance pas forcement une tentative immediate si Caddy est deja en attente. Il faut un docker restart caddy pour forcer une nouvelle tentative propre. Vu plusieurs fois en pratique lors de la mise en ligne de nouveaux sous-domaines.

Pour un seul serveur qui heberge plusieurs services distincts, Caddy reduit la charge operationnelle de facon nette. Le jour ou il faut du load balancing complexe multi-noeuds avec des regles de routage avancees, Nginx (ou Traefik) reprend l'avantage.