Pourquoi Server Manager utilise-t-il Caddy ?

Server Manager a un parti pris : chaque recette et chaque assistant écrit des blocs Caddyfile, pas des blocs nginx server { }, des <VirtualHost> Apache ni des labels Docker Traefik. Ce n’est pas parce que les autres moteurs sont mauvais — nginx, en particulier, est un excellent logiciel. C’est parce que Caddy supprime toute la complexité de la partie la plus pénible de l’hébergement d’un site web (HTTPS), contrairement aux autres. Si tu utilises déjà nginx, Apache ou Traefik, Server Manager détecte ta configuration et te laisse choisir : la conserver (avec un petit compromis côté expérience utilisateur) ou lancer la recette en un clic Migrer vers Caddy.

À quoi sert déjà un proxy inverse ?

Le proxy inverse est le serveur exposé au public sur les ports 80 (HTTP) et 443 (HTTPS). Les navigateurs s’y connectent ; il transmet chaque requête à la bonne application interne derrière lui — ton WordPress, ton application web, ton API. Tes applications écoutent sur des ports internes comme 3000 ou 127.0.0.1:8080 ; le proxy inverse est la porte d’entrée qui décide quoi envoyer où.

Tu as besoin d’un proxy inverse pour :

• Servir HTTPS (l’icône de cadenas). Aujourd’hui, les navigateurs refusent d’envoyer des cookies, mots de passe ou paiements en HTTP non chiffré.
• Faire tourner plusieurs sites sur un seul serveur avec des domaines différents.
• Masquer les ports internes — les visiteurs vont sur https://mysite.com, pas sur https://mysite.com:3000.

Les quatre choix courants

La même idée, résumée en une ligne chacun :

• Caddy — « Je veux que HTTPS fonctionne, tout simplement. »
• nginx — « J’ai besoin d’un débit maximal et j’ai le temps de le configurer soigneusement. »
• Apache — « Je fais tourner des applications PHP d’entreprise avec .htaccess. »
• Traefik — « Tout est dans Docker, il suffit de mettre des labels. »

Pourquoi Server Manager a choisi Caddy

Trois raisons, par ordre de priorité :

1. Le HTTPS automatique est la fonctionnalité clé pour les utilisateurs non techniques. La principale source de friction quand on déploie un petit site web, c’est la gestion des certificats TLS. Caddy supprime entièrement cette friction. L’assistant te demande de saisir un domaine ; 30 secondes plus tard, le site est en ligne en HTTPS avec un certificat Let's Encrypt valide. Pas d’installation de certbot, pas de choix de plugin, pas de tâche cron de renouvellement, pas de modification de config. C’est l’avantage le plus net, et nous ne voulons pas faire de compromis dessus.
2. De bons réglages par défaut réduisent les bugs de sites mal configurés. Caddy est fourni avec la compression gzip, HTTP/2, des chiffrements TLS modernes et des délais d’expiration raisonnables, tous activés par défaut. nginx et Apache laissent la plupart de ces options désactivées — ce qui signifie qu’une vraie partie des déploiements nginx finissent avec une configuration subtilement sous-optimale, sans que l’utilisateur sache qu’il faut la corriger. Caddy met le bon choix par défaut.
3. La syntaxe du Caddyfile est accessible. Faro peut écrire des blocs Caddyfile de façon fiable ; toi, tu peux les lire. L’équivalent avec nginx nécessite des blocs server { listen 80; listen 443 ssl; ssl_certificate /etc/letsencrypt/live/...; ... } sur plusieurs lignes, plus difficiles à parcourir et plus difficiles à produire correctement pour un LLM. Une syntaxe avec moins de friction = moins d’erreurs de l’agent + des validations plus lisibles.

Ce que tu perds en choisissant Caddy

Nous essayons d’être honnêtes sur les compromis. Caddy n’est pas strictement meilleur partout.

• Performances maximales sous des millions de requêtes. nginx garde l’avantage côté débit. Pour la plupart des sites web, ça n’a pas d’importance — le goulot d’étranglement est ton backend, pas le proxy — mais si tu sers des centaines de millions de requêtes par jour, nginx utilisera un peu moins de CPU.
• Modules nginx de niche. mod_lua / OpenResty, proxy_cache_path, limit_req_zone, geoip — ce sont de vraies fonctionnalités que Caddy gère différemment ou ne propose pas. Si tu en dépends, la migration ne se fera pas en un clic.
• **Héritage Apache + mod_php.** Certaines anciennes applications PHP supposent Apache avec mod_php (PHP s’exécute dans le processus Apache). Caddy utilise PHP-FPM (processus séparé) ; le résultat fonctionnel est le même, mais si tu as des années de config spécifique à Apache (fichiers .htaccess personnalisés, chaînes mod_rewrite), le portage demande du travail.
• Habitudes de l’équipe. Si ton équipe connaît déjà nginx sur le bout des doigts, changer implique un coût d’apprentissage. Le HTTPS automatique peut le justifier, mais ce n’est pas gratuit.

Pour le public cible de Server Manager (petites équipes, projets perso, déploiements sur un seul serveur), ces limites posent rarement problème. L’avantage du HTTPS automatique est ce qui compte au quotidien.

Et si je garde mon moteur actuel ?

Tu peux. Server Manager détecte nginx, Apache et Traefik, puis te propose deux chemins pris en charge :

• Rester sur ton moteur actuel. Faro le configure nativement dans le chat : /etc/nginx/sites-available/ + certbot --nginx pour nginx, l’équivalent Apache pour Apache, des labels Docker pour Traefik. Le résultat final est le même pour chaque domaine ; la palette de recettes marque les flux réservés à Caddy avec un badge 💬 via le chat — ils fonctionnent quand même, avec simplement un clic de validation en plus par rapport au parcours idéal avec Caddy.
• **Migrer vers Caddy** avec la recette intégrée. Elle traduit ta configuration existante en Caddyfile, la teste sur des ports alternatifs pendant que ton moteur actuel continue de servir le trafic en production, bascule atomiquement en cas de succès et revient automatiquement en arrière au moindre échec. Environ 10 minutes ; compatible avec nginx, Apache et Traefik.

Quel que soit ton choix, tes sites existants continuent de servir du trafic. La migration n’a lieu que si tu la demandes.

Quand NE PAS migrer

Ne migre pas vers Caddy si l’un de ces cas s’applique :

• Tu utilises OpenResty / nginx-lua ou d’autres fonctionnalités nginx reposant fortement sur des modules personnalisés.
• Tu as des règles **Apache .htaccess complexes** avec des chaînes RewriteRule [L,PT,NE] empilées.
• Tu utilises Traefik avec des middlewares personnalisés (authentification basic, limitation de débit, chaînes de réécriture d’en-têtes) — c’est théoriquement traduisible, mais la recette v1 ne le fait pas automatiquement.
• Tu es un hébergeur mutualisé avec des utilisateurs auxquels tu ne fais pas confiance — tu peux dépendre des modèles d’isolation par utilisateur de mod_php dans Apache, que Caddy ne reproduit pas.

Le contrôle de gérabilité de la recette de migration refuse de s’exécuter quand il détecte ces cas. Mais cela concerne uniquement la recette d’auto-migration — toutes les autres actions Server Manager (déployer, installer WordPress, connecter un domaine, gérer les sauvegardes, diagnostiquer un site lent, redémarrer un service) fonctionnent toujours via le chat avec ton moteur existant. Faro s’adapte au proxy présent sur le serveur. Essaie ; si un bouton de l’interface est bloqué, Faro te proposera de faire le même travail avec des commandes shell à la place.

En résumé

Caddy n’est pas supérieur dans tous les domaines. Il est supérieur dans le domaine qui compte le plus pour le type de serveur que la plupart des utilisateurs de Server Manager exploitent : un HTTPS automatique, fiable et sans configuration. Tout le reste (bons réglages par défaut, binaire unique, syntaxe concise, rechargement à chaud) sert cet avantage principal.

Si tu utilises déjà nginx / Apache / Traefik et que ta configuration actuelle fonctionne bien, le parcours par chat est entièrement pris en charge. Si tu veux l’expérience Server Manager complète en un clic, la recette Migrer vers Caddy est disponible dans l’onglet Serveur web de Infos serveur.