Caddy : une plateforme serveur extensible avec HTTPS automatique
Serveur Web HTTP/1-2-3 multiplateforme rapide et extensible avec HTTPS automatique
En bref
- De quoi s’agit-il ?
- Le dépôt Caddy est un serveur web basé sur Go qui active TLS par défaut. Cet article passe en revue ses options de configuration, ses exigences de construction et le contexte du projet à partir du README.
- À qui s’adresse-t-il ?
- Le README présente Caddy comme une plateforme extensible utilisant TLS par défaut, avec un design de document de configuration unique et une architecture de plugins. Son processus de construction nécessite Go 1.25+, et la configuration peut être gérée via JSON, le Caddyfile ou des adaptateurs.
- Puis-je l’utiliser commercialement ?
- Oui. Apache-2.0 est une licence permissive : vous pouvez utiliser, modifier et vendre un logiciel qui en dépend, à condition de conserver les mentions de droit d’auteur et de licence.
- Est-il encore maintenu ?
- Oui. Les derniers commits datent d’il y a 1 jour.
- En quel langage est-il écrit ?
- Principalement Go, d’après les statistiques de langage de GitHub.
Ces réponses reposent sur les données GitHub du projet (dernière synchronisation le 15 septembre 2026) et sur notre analyse. Elles ne constituent pas un avis juridique.
ANALYSE OPEN SOURCE APPROFONDIE
La plateforme serveur avec TLS par défaut : 1
Les premières lignes du dépôt qualifient Caddy de "plateforme serveur extensible qui utilise TLS par défaut". Le titre du README est "Chaque site sur HTTPS". Parmi les fonctionnalités listées figurent le HTTPS automatique avec ZeroSSL et Let's Encrypt pour les noms publics, une autorité de certification locale entièrement gérée pour les noms internes et les IP, la coordination avec d'autres instances Caddy dans un cluster, le repli multi-émetteurs et le support d'Encrypted ClientHello.
La plateforme serveur avec TLS par défaut : 2
Le README affirme que Caddy reste opérationnel lorsque d'autres serveurs tombent en panne en raison de problèmes liés à TLS/OCSP/certificats, et qu'il a servi des milliards de milliards de requêtes et géré des millions de certificats TLS en production. Il indique également que HTTP/1.1, HTTP/2 et HTTP/3 sont pris en charge par défaut, et que le serveur fonctionne partout sans dépendances externes (même pas libc) et est écrit en Go.
La plateforme serveur avec TLS par défaut : 3
Ce sont des affirmations du README, pas des mesures indépendantes ; le README ne fournit pas de liens vers des benchmarks ou des audits de sécurité.
Configuration : Caddyfile, JSON et l'API : 1
Le README présente plusieurs façons de configurer Caddy. Son langage de configuration natif est JSON, et l'API JSON est décrite comme le principal moyen de configuration, permettant des changements dynamiques. Le Caddyfile est une alternative plus simple, et des adaptateurs de configuration peuvent convertir d'autres formats, notamment JSON5, YAML, TOML, et même la configuration NGINX, en JSON. La CLI prend également en charge les fichiers de configuration.
Configuration : Caddyfile, JSON et l'API : 2
Le README souligne que presque toute la configuration se trouve dans un seul document de configuration, plutôt que d'être dispersée entre les drapeaux CLI, les variables d'environnement et des fichiers séparés. Il dit que cela rend la gestion de la configuration du serveur plus directe et réduit les variables cachées. Le site de documentation est la référence pour la structure complète ; le README lui-même ne contient pas d'exemples de configuration.
Construction depuis les sources et exigence Go : 1
Selon le README, la construction depuis les sources nécessite Go 1.25.0 ou plus récent. Pour le développement, les étapes consistent à cloner le dépôt, à se déplacer dans le répertoire `cmd/caddy/` et à exécuter `go build`. Le README prévient que cette méthode n'intègre pas d'informations de version correctes et recommande d'utiliser le constructeur `xcaddy` pour les informations de version et les plugins. La commande `xcaddy build` automatise les étapes de création d'un nouveau module, d'ajout d'imports de plugins et de compilation avec des balises spécifiques.
Construction depuis les sources et exigence Go : 2
Sous Linux, la liaison à des ports bas peut nécessiter des privilèges élevés ; le README suggère `sudo setcap cap_net_bind_service=+ep ./caddy`. Pour ceux qui utilisent `go run`, il y a un script `setcap.sh` qui peut être utilisé avec le drapeau `-exec`. Les tests peuvent être exécutés avec `go test ./...` ou pour un module spécifique comme `./modules/caddyhttp/tracing/`. Le README ne mentionne pas les tailles de binaires ni une liste de systèmes d'exploitation pris en charge ; il affirme seulement que Caddy fonctionne partout sans dépendances externes.
L'architecture décrite dans l'aperçu : 1
La section aperçu décrit Caddy comme étant le plus souvent utilisé comme serveur HTTPS, mais elle dit que Caddy convient à tout programme Go de longue durée. C'est une plateforme pour exécuter des applications Go : les "apps" de Caddy sont des programmes Go implémentés en tant que modules Caddy. Le README dit que deux apps sont fournies par défaut : `tls` et `http`. Ces apps bénéficient immédiatement de la documentation automatisée, de changements de configuration en ligne gracieux via l'API et de l'unification avec d'autres apps Caddy.
Conclusion éditoriale
Le README présente Caddy comme une plateforme extensible utilisant TLS par défaut, avec un design de document de configuration unique et une architecture de plugins. Son processus de construction nécessite Go 1.25+, et la configuration peut être gérée via JSON, le Caddyfile ou des adaptateurs. La licence est Apache-2.0 et le projet est une initiative de ZeroSSL.
Notes de la communauté