Déployer n8n avec Docker et HTTPS en 2026 : tutoriel complet (Postgres, reverse proxy, persistance)

Vous enchaînez des tâches répétitives entre plusieurs applications et vous payez Zapier ou Make au volume d’opérations ? n8n change la donne. C’est une plateforme d’automatisation de workflows, open source et auto-hébergeable, qui relie des centaines de services (API, bases de données, webhooks, IA) dans des scénarios visuels. Auto-hébergé, vous n’avez plus aucune limite d’exécutions, vos données ne transitent par aucun cloud tiers, et le coût se résume à votre serveur.

Mais n8n manipule vos identifiants d’API les plus sensibles (clés Stripe, tokens Google, accès bases de données…). Il doit donc être déployé en HTTPS obligatoire, avec une base PostgreSQL fiable plutôt que SQLite, une clé de chiffrement persistante et des sauvegardes sérieuses. Dans ce tutoriel, on déploie n8n via Docker Compose avec PostgreSQL, derrière un reverse proxy Caddy qui gère le HTTPS et Let’s Encrypt automatiquement.

Prérequis

Un VPS sécurisé sous Ubuntu 24.04 (ou Debian 12), 2 Go de RAM suffisent pour démarrer. Si ce n’est pas fait, suivez d’abord installer et sécuriser un VPS Ubuntu. Un petit VPS chez Hetzner ou Infomaniak fait largement l’affaire.
Docker et Docker Compose installés (commande à l’étape 1).
Un nom de domaine dont vous contrôlez le DNS. On utilisera n8n.exemple.fr. Un domaine est indispensable : de nombreux services tiers refusent d’enregistrer des webhooks vers une simple adresse IP.
Les ports 80 et 443 ouverts pour Let’s Encrypt et le trafic HTTPS.

Étape 1 : Installer Docker et Docker Compose

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
sudo usermod -aG docker $USER

Déconnectez-vous/reconnectez-vous, puis vérifiez :

docker --version && docker compose version

Étape 2 : Configurer le DNS

Chez votre fournisseur DNS, créez un enregistrement A (et AAAA si IPv6) :

Type	Nom	Valeur
A	`n8n.exemple.fr`	`203.0.113.10`

Vérifiez la propagation :

dig +short n8n.exemple.fr

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

docker network create web

Si vous suivez déjà notre tutoriel reverse proxy Caddy, ce réseau existe peut-être déjà : ignorez l’erreur éventuelle.

Étape 4 : Préparer le dossier et le fichier .env

n8n a impérativement besoin d’une clé de chiffrement persistante : c’est elle qui chiffre vos identifiants stockés. Si elle change, tous vos identifiants enregistrés deviennent illisibles. On la génère une fois et on la fige dans .env.

mkdir -p ~/n8n && cd ~/n8n
nano .env

# --- Domaine ---
N8N_HOST=n8n.exemple.fr
N8N_PROTOCOL=https
# URL publique complète des webhooks (sans slash final)
WEBHOOK_URL=https://n8n.exemple.fr/

# --- Clé de chiffrement (NE JAMAIS la changer après le premier démarrage) ---
N8N_ENCRYPTION_KEY=remplacez_par_la_cle_generee

# --- Base PostgreSQL ---
POSTGRES_USER=n8n
POSTGRES_PASSWORD=remplacez_par_un_mot_de_passe_long
POSTGRES_DB=n8n

# --- Divers ---
GENERIC_TIMEZONE=Europe/Paris
TZ=Europe/Paris

Générez la clé de chiffrement et un mot de passe de base :

echo "N8N_ENCRYPTION_KEY : $(openssl rand -hex 24)"
echo "POSTGRES_PASSWORD : $(openssl rand -base64 32)"

Reportez ces valeurs dans .env. Notez la clé de chiffrement dans votre gestionnaire de mots de passe : vous en aurez besoin pour restaurer une sauvegarde sur un autre serveur.

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

nano docker-compose.yml

services:
  postgres:
    image: postgres:16-alpine
    container_name: n8n_postgres
    restart: unless-stopped
    environment:
      POSTGRES_USER: ${POSTGRES_USER}
      POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
      POSTGRES_DB: ${POSTGRES_DB}
    volumes:
      - n8n_pgdata:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U ${POSTGRES_USER} -d ${POSTGRES_DB}"]
      interval: 10s
      timeout: 5s
      retries: 5
    networks:
      - n8n-internal

  n8n:
    image: docker.n8n.io/n8nio/n8n:latest
    container_name: n8n
    restart: unless-stopped
    environment:
      # --- Connexion à PostgreSQL ---
      DB_TYPE: postgresdb
      DB_POSTGRESDB_HOST: postgres
      DB_POSTGRESDB_PORT: 5432
      DB_POSTGRESDB_DATABASE: ${POSTGRES_DB}
      DB_POSTGRESDB_USER: ${POSTGRES_USER}
      DB_POSTGRESDB_PASSWORD: ${POSTGRES_PASSWORD}
      # --- Domaine et webhooks ---
      N8N_HOST: ${N8N_HOST}
      N8N_PROTOCOL: ${N8N_PROTOCOL}
      N8N_PORT: 5678
      WEBHOOK_URL: ${WEBHOOK_URL}
      N8N_EDITOR_BASE_URL: ${WEBHOOK_URL}
      # --- Sécurité ---
      N8N_ENCRYPTION_KEY: ${N8N_ENCRYPTION_KEY}
      N8N_SECURE_COOKIE: "true"
      # Indispensable derrière un reverse proxy : fait confiance au header X-Forwarded
      N8N_PROXY_HOPS: 1
      # --- Divers ---
      GENERIC_TIMEZONE: ${GENERIC_TIMEZONE}
      TZ: ${TZ}
    volumes:
      - n8n_data:/home/node/.n8n
    depends_on:
      postgres:
        condition: service_healthy
    networks:
      - web
      - n8n-internal

volumes:
  n8n_pgdata:
  n8n_data:

networks:
  web:
    external: true
  n8n-internal:

Le service n8n est sur deux réseaux : n8n-internal pour joindre PostgreSQL, web pour être joint par Caddy. PostgreSQL n’est que sur le réseau interne. Aucune section ports: : n8n n’est jamais exposé directement. Le paramètre N8N_PROXY_HOPS: 1 est crucial derrière un reverse proxy, sinon n8n se plaint de l’en-tête X-Forwarded-For.

Étape 6 : Le Caddyfile pour le HTTPS automatique

Si vous avez déjà un Caddy, ajoutez le bloc de site. Sinon, créez un dossier Caddy :

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

{
    email admin@exemple.fr
}

n8n.exemple.fr {
    encode gzip zstd

    header {
        Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
        X-Content-Type-Options "nosniff"
        Referrer-Policy "strict-origin-when-cross-origin"
        -Server
    }

    reverse_proxy n8n:5678
}

Le port interne de n8n est 5678. Caddy gère nativement les WebSockets utilisés par l’éditeur de workflows.

Puis le docker-compose.yml de Caddy :

nano docker-compose.yml

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

volumes:
  caddy_data:
  caddy_config:

networks:
  web:
    external: true

Étape 7 : Lancer les services

cd ~/n8n && docker compose up -d
cd ~/caddy && docker compose up -d

Suivez les logs pour vérifier la connexion à la base et l’émission du certificat :

cd ~/n8n && docker compose logs -f n8n

Quand n8n affiche Editor is now accessible via ..., visitez https://n8n.exemple.fr. L’écran de création du compte propriétaire s’affiche.

Étape 8 : Créer le compte propriétaire et premier workflow

Renseignez un email et un mot de passe fort : ce compte est le propriétaire de l’instance.
Créez un premier workflow simple pour valider le tout, par exemple un trigger « Manual » suivi d’un nœud « HTTP Request » vers une API publique, et exécutez-le.
Testez un webhook : créez un workflow avec un nœud « Webhook », activez-le, et appelez l’URL fournie (elle utilise bien https://n8n.exemple.fr/... grâce à WEBHOOK_URL). C’est le test décisif : si le webhook répond en HTTPS, votre déploiement est correct.

Ajoutez ensuite vos identifiants (clés API des services à automatiser) : ils sont chiffrés avec votre N8N_ENCRYPTION_KEY avant d’être stockés en base.

Étape 9 : Sauvegardes

Tout l’état utile de n8n vit dans PostgreSQL (workflows, identifiants chiffrés, exécutions). La clé de chiffrement, elle, est dans .env et le volume n8n_data. Sauvegardez les deux.

nano ~/n8n/backup.sh

#!/bin/bash
set -euo pipefail
cd "$HOME/n8n"
BACKUP_DIR="$HOME/n8n/backups"
STAMP=$(date +%Y%m%d-%H%M%S)
mkdir -p "$BACKUP_DIR"

# Dump cohérent de la base PostgreSQL
docker compose exec -T postgres \
  pg_dump -U n8n -d n8n | gzip > "$BACKUP_DIR/n8n-db-$STAMP.sql.gz"

# Sauvegarde du fichier .env (contient la clé de chiffrement — à protéger !)
cp .env "$BACKUP_DIR/.env-$STAMP"

# Conserve 14 jours
find "$BACKUP_DIR" -name 'n8n-db-*.sql.gz' -mtime +14 -delete
find "$BACKUP_DIR" -name '.env-*' -mtime +14 -delete

chmod +x ~/n8n/backup.sh
(crontab -l 2>/dev/null; echo "0 3 * * * $HOME/n8n/backup.sh") | crontab -

Une base sauvegardée sans la clé de chiffrement est inexploitable : vous pourriez restaurer les workflows mais pas déchiffrer les identifiants. Envoyez ces sauvegardes hors-site et chiffrées avec notre guide sauvegarde automatique avec Restic et Backblaze.

Étape 10 : Vérification finale

# Les conteneurs tournent et la base est saine
docker compose -f ~/n8n/docker-compose.yml ps

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

# Le HTTPS répond
curl -sI https://n8n.exemple.fr | head -1

Sécurité et durcissement

Pare-feu UFW strict. N’ouvrez que 80, 443 et SSH. Le port 5678 de n8n et le 5432 de PostgreSQL ne doivent jamais être exposés — la configuration réseau s’en charge déjà.
Mot de passe propriétaire fort et, si vous gérez une équipe, activez l’authentification à deux facteurs et les comptes utilisateurs séparés.
Clé de chiffrement protégée. Le fichier .env contient les secrets : chmod 600 .env et ne le versionnez jamais.
Mises à jour maîtrisées. n8n publie souvent. Sauvegardez avant, puis docker compose pull && docker compose up -d. Surveillez les notes de version pour les changements cassants.
Webhooks publics. Tout workflow exposant un webhook est accessible publiquement : sécurisez-les avec une authentification (header, token) dans le nœud Webhook.

Pour durcir le VPS, suivez installer et sécuriser un VPS Ubuntu.

Pièges courants et dépannage

« Your encryption key has changed ». Vous avez modifié ou perdu N8N_ENCRYPTION_KEY. Restaurez la clé d’origine depuis votre sauvegarde, sinon les identifiants chiffrés sont irrécupérables.
Erreur de proxy / cookie non sécurisé. Il manque N8N_PROXY_HOPS ou N8N_SECURE_COOKIE. Vérifiez ces variables et que N8N_PROTOCOL vaut bien https.
Les webhooks pointent vers localhost ou l’IP. WEBHOOK_URL n’est pas correctement défini. Il doit valoir l’URL publique HTTPS complète.
n8n ne se connecte pas à la base. Vérifiez les identifiants PostgreSQL et que le service postgres est healthy (docker compose ps). Le depends_on … condition: service_healthy évite les démarrages prématurés.

FAQ

n8n auto-hébergé est-il vraiment gratuit ?

La version Community de n8n est libre et sans limite d’exécutions : vous ne payez que votre serveur. Certaines fonctions avancées (SSO d’entreprise, environnements, certaines options de collaboration) relèvent d’une offre Enterprise payante, mais pour automatiser ses workflows personnels ou d’une petite équipe, la version Community couvre l’immense majorité des besoins.

Pourquoi utiliser PostgreSQL plutôt que la base SQLite par défaut ?

SQLite fonctionne pour tester, mais montre vite ses limites sur les exécutions concurrentes et les gros volumes d’historique. PostgreSQL gère bien mieux la charge, les sauvegardes à chaud et la croissance des données. Pour une instance que vous comptez utiliser sérieusement, PostgreSQL est le bon choix dès le départ.

Que se passe-t-il si je perds ma clé de chiffrement ?

Vos workflows restent récupérables, mais tous les identifiants enregistrés deviennent illisibles : il faudra les ressaisir un par un. C’est pourquoi la clé doit être notée dans votre gestionnaire de mots de passe et sauvegardée avec la base. Ne la régénérez jamais sur une instance existante.

Pourquoi mes webhooks ne fonctionnent-ils pas avec des services externes ?

Le plus souvent, c’est que WEBHOOK_URL ne reflète pas l’URL publique HTTPS, ou que le domaine n’est pas joignable depuis Internet. Beaucoup de services (Stripe, GitHub…) refusent d’enregistrer un webhook vers une IP nue ou en HTTP. Le reverse proxy HTTPS de ce tutoriel règle le problème.

Puis-je faire tourner de l’IA dans mes workflows n8n ?

Oui. n8n intègre des nœuds pour les LLM (OpenAI, modèles locaux via Ollama, agents IA). Auto-hébergé, vous pouvez même connecter n8n à un modèle local pour garder toutes les données chez vous. Attention toutefois à la RAM : les workflows IA et les exécutions parallèles consomment davantage.

n8n, Activepieces ou Node-RED : lequel choisir ?

n8n offre le meilleur équilibre entre puissance, nombre d’intégrations et facilité ; Activepieces vise la simplicité ; Node-RED est roi pour la domotique et l’IoT. Pour automatiser des applications web et des API, n8n est généralement le plus polyvalent. Notre comparatif n8n vs Activepieces vs Node-RED détaille chaque profil.