Reverse proxy HTTPS automatique avec Caddy et Docker en 2026 (certificats Let's Encrypt sans effort)

Vous hébergez plusieurs services sur votre VPS (un Nextcloud, un n8n, un site, un panneau d’admin) et vous vous retrouvez avec des URL en http://ip:8080, http://ip:5678, sans HTTPS, sans noms de domaine propres. C’est le moment d’installer un reverse proxy. Et en 2026, si vous voulez du HTTPS qui « marche tout seul », Caddy est imbattable : il obtient et renouvelle les certificats Let’s Encrypt automatiquement, sans une seule ligne de configuration ACME à écrire.

Là où Nginx demande des dizaines de lignes de config et un cron pour certbot, Caddy fait la même chose en deux ou trois lignes. Dans ce tutoriel, on déploie Caddy via Docker, on l’utilise pour exposer proprement plusieurs services derrière un seul point d’entrée, avec HTTPS automatique, en-têtes de sécurité et redirection HTTP → HTTPS. Tout est dans des fichiers versionnables et reproductibles.

Prérequis

Un VPS sécurisé sous Ubuntu 24.04 (ou Debian 12). Si ce n’est pas encore fait, suivez d’abord notre guide pour installer et sécuriser un VPS Ubuntu.
Docker et Docker Compose installés (la commande d’installation figure à l’étape 1).
Un nom de domaine dont vous contrôlez le DNS (chez votre registrar, ou via Cloudflare). On utilisera exemple.fr comme domaine d’exemple.
Les ports 80 et 443 ouverts sur votre pare-feu UFW : c’est indispensable pour la validation Let’s Encrypt et le trafic HTTPS.
Un ou plusieurs services déjà conteneurisés à exposer (on prendra Nextcloud et un service web de démo en exemple).

Étape 1 : Installer Docker et Docker Compose

Si Docker n’est pas encore présent, installez-le depuis le dépôt officiel (les versions des dépôts Ubuntu sont souvent en retard) :

sudo apt update
sudo apt install -y ca-certificates curl
sudo install -m 0755 -d /etc/apt/keyrings
sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc
sudo chmod a+r /etc/apt/keyrings/docker.asc
echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/ubuntu $(. /etc/os-release && echo "$VERSION_CODENAME") stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null
sudo apt update
sudo apt install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

Ajoutez votre utilisateur au groupe docker pour éviter de taper sudo à chaque commande (déconnectez-vous/reconnectez-vous ensuite pour appliquer) :

sudo usermod -aG docker $USER

Vérifiez l’installation :

docker --version && docker compose version

Étape 2 : Configurer les enregistrements DNS

Caddy a besoin que vos sous-domaines pointent vers l’IP de votre VPS pour valider les certificats. Chez votre fournisseur DNS, créez des enregistrements A (et AAAA si vous avez de l’IPv6) :

Type	Nom	Valeur
A	`cloud.exemple.fr`	`203.0.113.10`
A	`app.exemple.fr`	`203.0.113.10`

Attendez la propagation (souvent quelques minutes, parfois jusqu’à une heure). Vérifiez depuis votre machine :

dig +short cloud.exemple.fr

La commande doit renvoyer l’IP de votre VPS. Tant que ce n’est pas le cas, Let’s Encrypt échouera à émettre le certificat.

Étape 3 : Créer le réseau Docker partagé

Pour que Caddy puisse joindre vos conteneurs par leur nom (et non par une IP qui change), tous les services doivent partager un réseau Docker dédié. Créez-le une seule fois :

docker network create web

C’est ce réseau web qui servira de « bus » entre le reverse proxy et tous vos services. Caddy résoudra nextcloud:80 ou demo:80 automatiquement via le DNS interne de Docker.

Étape 4 : Écrire le Caddyfile

Le cœur de la configuration tient dans un seul fichier : le Caddyfile. Créez un dossier de travail et le fichier :

mkdir -p ~/caddy && cd ~/caddy
nano Caddyfile

Voici un Caddyfile complet qui expose deux services en HTTPS avec en-têtes de sécurité :

{
    # Email pour les notifications Let's Encrypt (expiration, etc.)
    email admin@exemple.fr
}

# Bloc de configuration réutilisable pour les en-têtes de sécurité
(securite) {
    header {
        Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
        X-Content-Type-Options "nosniff"
        X-Frame-Options "SAMEORIGIN"
        Referrer-Policy "strict-origin-when-cross-origin"
        # On masque la signature du serveur
        -Server
    }
}

cloud.exemple.fr {
    import securite
    reverse_proxy nextcloud:80
}

app.exemple.fr {
    import securite
    reverse_proxy demo:80
}

Quelques explications :

Chaque bloc commençant par un nom de domaine déclenche automatiquement l’émission d’un certificat Let’s Encrypt et la redirection HTTP → HTTPS. Vous n’avez rien d’autre à configurer.
reverse_proxy nextcloud:80 redirige le trafic vers le conteneur nommé nextcloud, sur son port interne 80. Docker se charge de la résolution du nom.
Le snippet (securite), importé dans chaque bloc, factorise les en-têtes HTTP recommandés. Pratique pour rester cohérent.

Piège fréquent : N’indiquez jamais http:// ou https:// devant le nom de domaine dans un bloc de site. Caddy gère le protocole tout seul. Écrire https://cloud.exemple.fr désactive l’émission automatique du certificat.

Étape 5 : Le docker-compose.yml de Caddy

Dans le même dossier ~/caddy, créez le fichier de composition :

nano docker-compose.yml

services:
  caddy:
    image: caddy:2-alpine
    container_name: caddy
    restart: unless-stopped
    ports:
      - "80:80"
      - "443:443"
      - "443:443/udp"   # HTTP/3 (QUIC)
    volumes:
      - ./Caddyfile:/etc/caddy/Caddyfile:ro
      - caddy_data:/data
      - caddy_config:/config
    networks:
      - web

volumes:
  caddy_data:
  caddy_config:

networks:
  web:
    external: true

Points importants :

Le volume caddy_data est critique : il stocke vos certificats et les clés ACME. Sans lui, vous redemanderiez un certificat à chaque redémarrage et atteindriez vite les limites de Let’s Encrypt (5 certificats identiques par semaine).
Le réseau est déclaré external: true car on l’a créé manuellement à l’étape 3.
Le port 443/udp active HTTP/3, supporté nativement par Caddy.

Lancez Caddy :

docker compose up -d

Suivez les logs pour voir l’émission des certificats en direct :

docker compose logs -f caddy

Vous devriez voir des lignes du type certificate obtained successfully pour chacun de vos domaines.

Étape 6 : Connecter vos services au réseau de Caddy

Pour qu’un service soit joignable par Caddy, il doit être sur le réseau web et porter le nom utilisé dans le Caddyfile. Voici un exemple de service de démo à exposer. Dans un autre dossier :

services:
  demo:
    image: nginxdemos/hello
    container_name: demo
    restart: unless-stopped
    networks:
      - web

networks:
  web:
    external: true

Notez l’absence de section ports: : c’est tout l’intérêt du reverse proxy. Le service n’est jamais exposé directement sur Internet, il n’est accessible qu’à travers Caddy via le réseau interne web. C’est plus sûr et plus propre.

Lancez-le :

docker compose up -d

Visitez https://app.exemple.fr : vous obtenez le service de démo en HTTPS, avec un cadenas valide. Pour Nextcloud, assurez-vous simplement que son conteneur s’appelle nextcloud et qu’il rejoint le réseau web (voir notre tuto héberger Nextcloud sur un VPS).

Étape 7 : Recharger la configuration sans coupure

Quand vous ajoutez un service, modifiez le Caddyfile puis rechargez sans redémarrer le conteneur (zéro interruption, les certificats existants sont conservés) :

docker compose exec caddy caddy reload --config /etc/caddy/Caddyfile

Validez d’abord la syntaxe pour éviter de casser la prod :

docker compose exec caddy caddy validate --config /etc/caddy/Caddyfile

Vérification finale

Contrôlez que tout est en place :

# Caddy tourne
docker compose ps

# Le HTTP redirige bien vers HTTPS (code 308)
curl -sI http://cloud.exemple.fr | head -1

# Le certificat est valide et la chaîne TLS correcte
curl -sI https://cloud.exemple.fr | head -1

Pour un audit complet de la configuration TLS, testez votre domaine sur SSL Labs : vous devriez viser une note A ou A+ grâce aux en-têtes HSTS et aux protocoles modernes activés par défaut par Caddy.

Bonnes pratiques et options avancées

Validation par DNS challenge. Si vous voulez des certificats wildcard (*.exemple.fr) ou que votre serveur n’est pas joignable sur le port 80, utilisez le challenge DNS. Il faut alors une image Caddy compilée avec le module de votre fournisseur DNS (Cloudflare, OVH…) et un jeton d’API.
Authentification en frontal. Pour protéger un service sensible, Caddy gère le basic_auth (mot de passe haché bcrypt) directement dans le Caddyfile, ou vous pouvez le coupler à un fournisseur SSO comme Authelia.
Compression et cache. Ajoutez encode gzip zstd dans un bloc de site pour compresser les réponses automatiquement.
Logs structurés. La directive log permet d’écrire des journaux JSON exploitables par votre stack de supervision.
Ne mélangez pas les reverse proxies. N’exposez jamais en parallèle un service directement (via ports:) et derrière Caddy : cela crée des chemins d’accès non chiffrés. Tout doit passer par le proxy.

FAQ

Pourquoi choisir Caddy plutôt que Nginx ou Traefik ?

Pour la simplicité du HTTPS automatique. Caddy obtient, installe et renouvelle les certificats Let’s Encrypt sans aucune configuration manuelle ni cron, là où Nginx exige certbot et des blocs de config verbeux. Traefik est excellent pour l’auto-découverte via les labels Docker, mais sa courbe d’apprentissage est plus raide. Pour un comparatif détaillé des trois, voyez Caddy vs Nginx vs Traefik en 2026.

Que se passe-t-il si Let’s Encrypt échoue à émettre le certificat ?

Dans 90 % des cas, c’est un problème de DNS (le domaine ne pointe pas encore vers le VPS) ou de pare-feu (port 80 fermé). Vérifiez dig +short votre-domaine et sudo ufw status. Les logs Caddy (docker compose logs caddy) indiquent précisément la cause du rejet ACME. Tant que vous déboguez, utilisez l’environnement de staging de Let’s Encrypt pour éviter d’atteindre les limites de taux.

Mes certificats sont-ils renouvelés automatiquement ?

Oui, intégralement. Caddy vérifie l’expiration en continu et renouvelle chaque certificat environ 30 jours avant l’échéance, sans aucune intervention. C’est précisément ce qui rend cette solution « set and forget ». La seule condition : que le volume caddy_data soit bien persistant.

Puis-je utiliser Caddy derrière Cloudflare ?

Oui. Activez le mode « Full (strict) » dans Cloudflare pour que le trafic Cloudflare → VPS reste chiffré avec le certificat Let’s Encrypt de Caddy. Si vous activez le proxy orange de Cloudflare, le challenge HTTP-01 peut échouer ; basculez alors sur le challenge DNS de Cloudflare pour l’émission des certificats.

Caddy consomme-t-il beaucoup de ressources ?

Non, c’est l’un de ses atouts. L’image caddy:2-alpine pèse quelques dizaines de Mo et le conteneur tourne tranquillement avec moins de 50 Mo de RAM pour un trafic modéré. Il convient parfaitement à un petit VPS d’entrée de gamme.