Héberger n8n en self-hosted avec un nom de domaine et HTTPS (Traefik ou Caddy)

Installer n8n en self-hosted via Docker Compose prend une demi-heure. Le rendre accessible en https://n8n.votredomaine.fr avec un certificat valide, sans avertissement de sécurité ni webhook cassé, est l'étape qui bloque le plus souvent les nouveaux venus — pas parce que c'est compliqué, mais parce que trois pièces doivent s'emboîter exactement : le reverse proxy, le DNS et les variables d'environnement de n8n lui-même. Ce guide couvre les deux options les plus courantes, Traefik et Caddy, et surtout les réglages n8n qu'on oublie systématiquement une fois le certificat obtenu.

Pourquoi HTTPS n'est pas une option cosmétique

Sur une instance n8n exposée sur Internet, HTTPS protège deux choses distinctes. D'abord vos identifiants de connexion et les credentials chiffrés qui transitent lors de chaque session d'édition. Ensuite, et c'est souvent oublié, les callbacks OAuth : Google, Notion, HubSpot ou Slack refusent purement et simplement d'enregistrer une URL de callback en http:// pour une application de production — sans certificat valide, une partie de vos intégrations ne pourra jamais s'authentifier.

Ce n'est plus un chantier réservé aux équipes techniques. Une étude de référence sur l'adoption des certificats gratuits, Aertsen, Korczyński, Moura, Tajalizadehkhoob et van den Berg (ANRW 2017), montre que Let's Encrypt a démocratisé le chiffrement en couvrant en priorité le segment des sites à faible budget — exactement le profil d'un VPS à 10 €/mois qui fait tourner n8n. Le certificat n'est plus le problème ; sa bonne intégration avec le reverse proxy et l'application, elle, reste une source d'erreurs bien réelle : une étude plus récente menée auprès de 96 administrateurs expérimentés, Mai, Schedler, Weippl et Krombholz (HCII 2022), constate que plus de la moitié des sites analysés restent mal configurés malgré la disponibilité d'outils comme Certbot — la difficulté s'est déplacée de l'obtention du certificat vers son raccordement correct à l'application qu'il protège. C'est précisément l'étape détaillée ci-dessous.

Traefik ou Caddy : choisir son reverse proxy

Les deux gèrent le renouvellement automatique des certificats Let's Encrypt sans intervention manuelle, mais avec une philosophie différente :

• Caddy vise la simplicité : un Caddyfile de quelques lignes suffit à exposer n8n en HTTPS. Idéal si votre serveur n'héberge que n8n, ou un ou deux autres services.
• Traefik s'appuie sur la découverte automatique via les labels Docker : chaque conteneur déclare lui-même ses règles de routage dans le docker-compose.yml. La configuration initiale est plus verbeuse, mais elle passe à l'échelle proprement dès que plusieurs applications partagent le même serveur — utile si vous prévoyez d'ajouter un mode queue avec des workers Redis ou d'autres services applicatifs par la suite.

Pour un premier hébergement mono-service, Caddy économise du temps de configuration. Pour un serveur qui doit grandir, Traefik évite d'avoir à tout refaire plus tard.

Configuration avec Traefik

Un docker-compose.yml minimal place n8n derrière Traefik en trois blocs :

services:
  traefik:
    image: "traefik:v3.1"
    command:
      - "--providers.docker=true"
      - "--providers.docker.exposedbydefault=false"
      - "--entrypoints.web.address=:80"
      - "--entrypoints.websecure.address=:443"
      - "--certificatesresolvers.le.acme.httpchallenge=true"
      - "--certificatesresolvers.le.acme.httpchallenge.entrypoint=web"
      - "--certificatesresolvers.le.acme.email=vous@votredomaine.fr"
      - "--certificatesresolvers.le.acme.storage=/letsencrypt/acme.json"
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - "./letsencrypt:/letsencrypt"
      - "/var/run/docker.sock:/var/run/docker.sock:ro"

  n8n:
    image: docker.n8n.io/n8nio/n8n
    restart: unless-stopped
    environment:
      - N8N_HOST=n8n.votredomaine.fr
      - N8N_PROTOCOL=https
      - N8N_PORT=5678
      - WEBHOOK_URL=https://n8n.votredomaine.fr/
      - N8N_SECURE_COOKIE=true
    volumes:
      - n8n_data:/home/node/.n8n
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.n8n.rule=Host(`n8n.votredomaine.fr`)"
      - "traefik.http.routers.n8n.entrypoints=websecure"
      - "traefik.http.routers.n8n.tls.certresolver=le"
      - "traefik.http.services.n8n.loadbalancer.server.port=5678"

volumes:
  n8n_data:

Traefik gère la validation ACME (défi HTTP-01 sur le port 80) puis bascule tout le trafic entrant vers HTTPS. Le point qui échappe le plus souvent : les labels ne suffisent pas seuls, il faut aussi que le DNS de n8n.votredomaine.fr pointe bien, en enregistrement A, vers l'IP publique du serveur avant de lancer docker compose up -d — sinon le défi ACME échoue silencieusement et Traefik retente en boucle sans jamais aboutir.

Configuration avec Caddy

Même résultat, en beaucoup moins de lignes. Un fichier Caddyfile :

n8n.votredomaine.fr {
    reverse_proxy n8n:5678
}

Et le service correspondant dans docker-compose.yml :

services:
  caddy:
    image: caddy:2
    restart: unless-stopped
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./Caddyfile:/etc/caddyfile
      - caddy_data:/data

  n8n:
    image: docker.n8n.io/n8nio/n8n
    restart: unless-stopped
    environment:
      - N8N_HOST=n8n.votredomaine.fr
      - N8N_PROTOCOL=https
      - WEBHOOK_URL=https://n8n.votredomaine.fr/
      - N8N_SECURE_COOKIE=true
    volumes:
      - n8n_data:/home/node/.n8n

volumes:
  caddy_data:
  n8n_data:

Caddy détecte automatiquement qu'un nom de domaine valide est déclaré et déclenche seul l'obtention et le renouvellement du certificat — aucune section ACME à écrire à la main.

Les variables n8n qu'on oublie systématiquement

Le reverse proxy termine le HTTPS côté public, mais n8n, en interne, ne voit que du trafic HTTP brut sur le port 5678. Sans les bonnes variables, l'application continue de raisonner comme si elle était en HTTP :

• N8N_PROTOCOL=https et N8N_HOST : indiquent à n8n le protocole et le domaine publics à utiliser pour générer ses propres URLs (interface, callbacks OAuth).
• WEBHOOK_URL : à définir explicitement dès qu'un reverse proxy est en jeu, sans quoi n8n peut afficher ou enregistrer des URLs de webhook incorrectes auprès des services tiers — le guide sur la sécurisation des webhooks n8n part d'ailleurs du principe que cette URL publique est correcte avant d'ajouter authentification et validation de signature.
• N8N_SECURE_COOKIE=true : force le cookie de session à n'être transmis que sur HTTPS. À laisser sur false uniquement le temps de premiers tests en HTTP pur, jamais en production.

Vérifier que tout fonctionne réellement

Trois contrôles suffisent après le premier démarrage :

1. Ouvrir https://n8n.votredomaine.fr dans le navigateur : le cadenas doit apparaître sans avertissement, et l'autorité du certificat doit être Let's Encrypt.
2. Créer un workflow de test avec un node Webhook et vérifier que l'URL de production affichée par n8n commence bien par https:// et par le bon domaine, pas par une IP ou un http:// résiduel.
3. Tester une connexion OAuth (Google, Notion…) de bout en bout : c'est le test le plus fiable, car un fournisseur OAuth refuse d'aboutir si la moindre incohérence subsiste entre le domaine déclaré et celui réellement servi.

Pièges fréquents

• DNS pas encore propagé : lancer le proxy avant que l'enregistrement A ait propagé (parfois plusieurs minutes à quelques heures) fait échouer la validation ACME. Vérifiez avec dig n8n.votredomaine.fr avant de démarrer les conteneurs.
• Rate limit Let's Encrypt : de multiples tentatives ratées rapprochées peuvent déclencher une limite temporaire par domaine. Corrigez la cause (DNS, pare-feu) avant de relancer plutôt que de réessayer en boucle.
• Ports 80/443 filtrés : un groupe de sécurité cloud (AWS, OVH, Scaleway) qui n'autorise que le SSH par défaut bloque silencieusement le défi HTTP-01. À vérifier en premier si le certificat ne s'obtient jamais.
• WEBHOOK_URL oublié après une migration : changer de domaine ou de serveur sans mettre à jour cette variable laisse les workflows actifs pointer vers l'ancienne URL — les intégrations tierces continuent d'appeler une adresse qui ne répond plus.

Pour aller plus loin

Ce socle HTTPS est le prérequis technique de tout self-hosting sérieux, en particulier quand la localisation des données est l'argument principal — c'est le cas détaillé dans notre comparatif n8n self-hosted vs cloud et dans les workflows de journalisation du Pack Conformité & Audit (149 €), pensés pour un déploiement maîtrisé de bout en bout. Une fois le domaine et le certificat en place, pensez aussi à sauvegarder vos workflows en dehors du conteneur : notre guide sur la sauvegarde et le versionnage des workflows avec Git couvre exactement cette suite logique.