Caddy Reverse Proxy

Caddy est un serveur web open source qui fait aussi office de reverse proxy. Sa particularité : il demande lui-même ses certificats HTTPS, sans étape de resolver séparée à configurer. On écrit un nom de domaine et une ligne reverse_proxy dans un Caddyfile de quelques lignes, on démarre le processus, et le site tourne en HTTPS valide en quelques secondes à peine. jellyfin.votredomaine.com devient joignable depuis n’importe où, avec un vrai certificat devant, pas une IP nue suivie d’un port.

Pourquoi Caddy plutôt que Nginx Proxy Manager ou Traefik ?

Les trois reverse proxies couverts sur ce site règlent le même problème : router un domaine vers un conteneur avec un certificat valide. Mais chacun demande autre chose à la personne qui l’installe. Nginx Proxy Manager échange un fichier de config contre un formulaire ; Traefik échange ce formulaire contre des labels Docker qu’il découvre tout seul. Caddy garde lui aussi un fichier texte, mais laisse tomber entièrement le socket Docker et la syntaxe des labels : un Caddyfile posé sur le disque prend effet au reload, sans lien avec les conteneurs et sans dashboard à verrouiller. La contrepartie : Caddy ne repère pas un nouveau conteneur tout seul. Chaque site block s’ajoute encore à la main, juste un peu plus court qu’un bloc Nginx ou qu’une page entière de labels Traefik.

Installer Caddy avec Docker

Cette configuration suit le modèle de l’image Docker officielle de Caddy et de son guide de démarrage rapide pour reverse proxy : un Caddyfile monté depuis l’hôte, plus deux volumes nommés pour que les certificats survivent aux redémarrages du conteneur.

services:
  caddy:
    image: caddy:2.11-alpine
    container_name: caddy
    restart: unless-stopped
    ports:
      - "80:80"
      - "443:443"
      - "443:443/udp"
    volumes:
      - ./conf:/etc/caddy
      - caddy_data:/data
      - caddy_config:/config

volumes:
  caddy_data:
  caddy_config:

1. Installez Docker s’il n’est pas déjà présent sur la machine, créez un dossier conf à côté de docker-compose.yml, et enregistrez-y un Caddyfile, détaillé juste après.
2. Enregistrez le fichier ci-dessus et lancez docker compose up -d.
3. Redirigez les ports 80 et 443 de votre routeur vers cette machine ; le mapping UDP 443 sert au HTTP/3, facultatif mais utile à garder.
4. Montez le dossier conf entier, pas un seul fichier Caddyfile : certains éditeurs changent l’inode du fichier à la sauvegarde, ce qui casse le reload de Caddy.

docker compose up -d
docker compose logs -f caddy

Router le trafic avec le Caddyfile

Ça remplace le formulaire Add Proxy Host de Nginx Proxy Manager et les labels de conteneur de Traefik : la règle tient en un nom de domaine suivi d’une ligne reverse_proxy.

jellyfin.votredomaine.com {
    reverse_proxy jellyfin:8096
}

Enregistrez ça dans ./conf/Caddyfile et redémarrez le conteneur. Caddy demande un certificat pour jellyfin.votredomaine.com dès qu’il voit le DNS correctement pointé dessus, sans commande séparée et sans bloc resolver, l’étape pour laquelle Traefik a besoin de ses flags certificatesresolvers.

Comment fonctionne vraiment le HTTPS automatique de Caddy

Chaque autre reverse proxy de ce site demande une étape volontaire pour le HTTPS : l’onglet SSL de Nginx Proxy Manager, les flags de resolver de Traefik. Caddy, lui, regarde chaque nom de domaine du Caddyfile et, s’il ressemble à un vrai hostname public, demande un certificat tout de suite, avec un second émetteur en secours si le premier est injoignable. Les hostnames internes et les IP nues reçoivent eux aussi un certificat, émis par une autorité privée gérée localement, si bien qu’un service purement LAN se retrouve derrière une vraie TLS plutôt que derrière un avertissement auto-signé.

Caddy face à Traefik et Nginx Proxy Manager

Les trois terminent le HTTPS et redirigent le trafic vers le bon conteneur. Ce qui change entre eux, c’est comment chacun apprend où doit aller ce trafic, et la part de ce travail qu’il automatise.

	Caddy	Traefik	Nginx Proxy Manager
Configuration	Caddyfile, quelques lignes par site	Labels Docker, découverts automatiquement	Dashboard web, ajouté à la main
Découverte de service	Aucune, édition manuelle	Automatique via Docker, Kubernetes, Swarm	Aucune, chaque hôte ajouté à la main
HTTPS	Automatique, actif par défaut, sans config resolver	Automatique via resolver Let’s Encrypt	Automatique via l’onglet SSL du dashboard
Difficulté	Simple, basé texte	La plus élevée des trois	La plus simple, pilotée par interface
Idéal pour	Petites installations, préférence texte plutôt qu’UI	Hôtes très Docker avec de nombreux conteneurs	Premier reverse proxy, préférence UI
Licence	Apache 2.0	MIT	MIT

• HTTPS automatique dès qu’un domaine résout, aucun flag de resolver ni onglet SSL requis
• Configuration dans un seul Caddyfile court et lisible, plutôt que des labels éparpillés sur les conteneurs ou une base de dashboard
• HTTP/3 et réglages TLS modernes pris en charge dès l’installation
• Sous licence Apache 2.0, aucune fonctionnalité verrouillée derrière un paywall

• Aucune interface web, aucune découverte automatique de conteneur : chaque site block s’ajoute encore à la main
• Moins de tutoriels homelab et de guides communautaires que pour Traefik ou Nginx Proxy Manager
• Ajouter des plugins ou des fournisseurs DNS demande de compiler un binaire personnalisé avec xcaddy, pas de cocher une case dans une config

Atteindre un service auto-hébergé comme Jellyfin depuis l’extérieur de la maison reste l’une des raisons les plus courantes qui poussent les homelabbeurs vers un reverse proxy. Notre guide d’accès distant à Jellyfin détaille cette configuration de bout en bout, et la compare à Tailscale et WireGuard, qui exposent un réseau privé complet plutôt que de router un sous-domaine HTTPS à la fois.

FAQ

Caddy est-il gratuit et open source ?

Oui. Il est sous licence Apache 2.0, libre pour tout usage y compris commercial, et maintenu comme un projet ZeroSSL plutôt que vendu comme produit payant à part.

Caddy est-il meilleur que Nginx ou Traefik ?

Pour des sites avec de vrais noms de domaine, Caddy demande en général le moins de configuration : pas de dashboard à sécuriser comme Nginx Proxy Manager, pas de flags de resolver ni de socket Docker comme Traefik. Traefik reprend l’avantage dès qu’un hôte fait tourner une douzaine de conteneurs auto-découverts ou plus. Nginx Proxy Manager, lui, reste imbattable pour qui préfère remplir un formulaire plutôt qu’écrire un fichier.

Caddy a-t-il besoin de Docker pour fonctionner ?

Non. Caddy est un binaire unique pour Linux, macOS, Windows et BSD, sans runtime de conteneur nécessaire ; Docker reste juste la façon la plus courante dont les homelabbeurs le font tourner.

Caddy peut-il émettre des certificats pour des hostnames internes uniquement ?

Oui. Pour des noms ou des IP qui ne sont pas résolvables publiquement, Caddy bascule sur une autorité de certification gérée localement plutôt que Let’s Encrypt, si bien qu’un service purement LAN garde quand même une vraie TLS.

L’API d’administration de Caddy est-elle sûre à exposer sur internet ?

Pas sans authentification devant. Elle écoute sur 127.0.0.1:2019 par défaut, déjà plus sûr qu’un port ouvert, et ce réglage doit rester tel quel plutôt que d’être relié à une interface publique.

Pour deux ou trois sites avec de vrais domaines, Caddy reste en général le chemin le plus rapide entre un fichier docker-compose et une adresse HTTPS qui fonctionne, sans jamais toucher à un flag de certificat. Le jour où le homelab réclame un dashboard pour les membres du foyer moins technophiles, ou dépasse la douzaine de conteneurs auto-découverts, c’est là que Nginx Proxy Manager ou Traefik reprend la main.