Quand je choisirais encore nginx

nginx se place devant les conteneurs back-end et front-end en production, routant 80/443 vers le bon service interne. Défaut de longue date, extrêmement mature, tournant sur une fraction non négligeable d'internet.

nginx:
  profiles:
    - production

docker compose up en dev normal ne le démarre jamais — chaque service est joint directement sur son propre port pendant le dev, et le proxy n'entre en jeu que pour un déploiement de type production. Un reverse proxy est de la pure friction en local, une chose de plus à garder synchronisée et à mal configurer pendant qu'on teste une fonctionnalité, et il ne gagne son coût qu'une fois que le routage unifié, la terminaison TLS et un point d'entrée public unique sont réellement nécessaires.

La config de nginx est puissante mais verbeuse, et il n'a pas de HTTPS automatique intégré — les certificats ont besoin de Certbot câblé à la main, plus un cron de renouvellement gardé synchro avec la config qui référence les fichiers de certificat. Un vrai travail opérationnel continu comparé à Caddy, qui le fait automatiquement.

Reste un choix tout à fait raisonnable malgré ça. La maturité et l'ubiquité sont des avantages en soi — le comportement et les modes de défaillance de nginx sont abondamment documentés, et presque tout ops a déjà vu une config, ce qui abaisse la barre pour celui qui doit toucher à ce déploiement plus tard. Pour un simple boulot de reverse-proxy-plus-TLS sans exigences inhabituelles, la verbosité de la config est un coût ponctuel — une fois écrite et fonctionnelle, elle tourne surtout toute seule.

volumes:
  - ./nginx/nginx.conf:/etc/nginx/nginx.conf
  - ./nginx/ssl:/etc/nginx/ssl

La config et les certificats vivent hors de l'image, montés à l'exécution — donc mettre à jour le routage ou faire tourner un certificat, c'est éditer un fichier monté et recharger, pas reconstruire l'image. Ça vaut la peine de garder ce pattern pour tout reverse proxy, peu importe l'outil.