n8n sous Docker : le tutoriel complet, du docker-compose.yml aux sauvegardes

Pour installer n8n avec Docker de façon durable, utilisez Docker Compose : un fichier docker-compose.yml décrit n8n, une base PostgreSQL et un reverse proxy HTTPS, avec des volumes pour conserver les données et une clé de chiffrement définie une fois pour toutes. Ce tutoriel donne une configuration complète et commentée, puis la routine de mise à jour, la méthode de sauvegarde et la checklist de sécurité avant la mise en production.

Il s’adresse à ceux qui veulent gérer leur propre serveur. Si vous préférez une instance prête à l’emploi, maintenue et sauvegardée, l’installation de n8n clé en main vous évite cette partie technique.

01Pourquoi déployer n8n avec Docker

Docker est la méthode d’auto-hébergement recommandée par n8n pour la plupart des cas. Le conteneur embarque la bonne version de Node.js et toutes les dépendances : vous n’installez rien d’autre sur le serveur, et la mise à jour se résume à changer d’image.

• Installation reproductible : le même fichier fonctionne sur un VPS, un serveur dédié ou un poste local.
• Isolation : n8n, la base de données et le proxy tournent dans des conteneurs séparés.
• Retour arrière simple : en cas de problème, vous relancez l’image précédente.
• Sauvegarde ciblée : les données vivent dans des volumes identifiés.

La documentation de n8n rappelle toutefois que l’auto-hébergement demande des compétences en administration de serveur et en sécurité. Une erreur de configuration peut entraîner une perte de données ou une interruption de service.

Docker seul ou Docker Compose

Une simple commande docker run suffit pour tester n8n en local. Pour un usage réel, Docker Compose s’impose : la page de documentation consacrée à docker run est d’ailleurs signalée comme obsolète par n8n, qui renvoie vers Docker Compose.

Prérequis : serveur, nom de domaine et ports

• Un serveur Linux (Ubuntu ou Debian par exemple) avec un accès SSH. La documentation de n8n indique au moins 4 Go de RAM et 2 vCPU pour sa pile Compose complète, qui inclut le service de sandbox de l’assistant IA. Une instance simple demande moins, mais prévoyez de la marge si vous traitez des fichiers ou de gros volumes d’exécutions.
• Docker Engine et le plugin Docker Compose v2, installés depuis le dépôt officiel de Docker. Vérifiez avec docker compose version.
• Un sous-domaine, par exemple n8n.example.com, avec un enregistrement DNS de type A pointant vers l’adresse IP du serveur.
• Les ports 80 et 443 ouverts pour le proxy. Le port 5678 de n8n ne doit pas être exposé sur Internet.

02Préparer le fichier docker-compose.yml de n8n

Créez un dossier dédié, par exemple /opt/n8n, qui contiendra trois fichiers : .env pour les secrets, docker-compose.yml pour les services et Caddyfile pour le proxy. Voici le fichier .env :

N8N_VERSION=2.43.7
N8N_DOMAIN=n8n.example.com
POSTGRES_USER=n8n
POSTGRES_PASSWORD=remplacez-par-un-mot-de-passe-long-et-aleatoire
POSTGRES_DB=n8n
N8N_ENCRYPTION_KEY=remplacez-par-la-sortie-de-openssl-rand-hex-32

Puis le fichier docker-compose.yml :

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

  n8n:
    image: n8nio/n8n:${N8N_VERSION}
    restart: unless-stopped
    environment:
      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}
      N8N_ENCRYPTION_KEY: ${N8N_ENCRYPTION_KEY}
      N8N_HOST: ${N8N_DOMAIN}
      N8N_PORT: 5678
      N8N_PROTOCOL: https
      N8N_WEBHOOK_URL: https://${N8N_DOMAIN}/
      N8N_PROXY_HOPS: 1
      NODE_ENV: production
      GENERIC_TIMEZONE: Europe/Paris
      TZ: Europe/Paris
      N8N_ENFORCE_SETTINGS_FILE_PERMISSIONS: "true"
    volumes:
      - n8n_data:/home/node/.n8n
    depends_on:
      postgres:
        condition: service_healthy

  caddy:
    image: caddy:2
    restart: unless-stopped
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./Caddyfile:/etc/caddy/Caddyfile:ro
      - caddy_data:/data
      - caddy_config:/config

volumes:
  db_data:
  n8n_data:
  caddy_data:
  caddy_config:

Le service n8n ne publie aucun port : seul le proxy Caddy l’atteint, par le réseau interne créé par Compose. Lancez ensuite la pile avec docker compose up -d, suivez le démarrage avec docker compose logs -f n8n, puis ouvrez https://n8n.example.com.

Volumes et persistance des données

Un conteneur est jetable : tout ce qui n’est pas dans un volume disparaît quand il est recréé. Dans l’image officielle, n8n stocke ses données dans /home/node/.n8n. Ce dossier contient le fichier config, qui conserve la clé de chiffrement des identifiants, et, avec SQLite, la base de données elle-même.

• n8n_data : le dossier .n8n de n8n, à conserver même avec PostgreSQL.
• db_data : les fichiers de la base PostgreSQL.
• caddy_data : les certificats TLS obtenus par Caddy.

Depuis la version 1.0, le processus n8n tourne avec l’utilisateur node et non plus root. Si vous montez un dossier de l’hôte à la place d’un volume nommé, vérifiez qu’il appartient bien à cet utilisateur, sinon n8n ne pourra pas y écrire.

Base de données : SQLite ou PostgreSQL

Par défaut, n8n enregistre workflows, identifiants et historique d’exécutions dans une base SQLite. C’est suffisant pour un test ou un usage léger. Pour une instance de production, PostgreSQL apporte de meilleures performances sous charge, des sauvegardes à chaud avec pg_dump et la possibilité de passer plus tard au mode file d’attente.

Attention, la documentation de n8n précise que les données SQLite existantes ne sont pas transférées automatiquement vers une nouvelle base PostgreSQL. Choisissez PostgreSQL dès le départ, ou prévoyez une migration par export et import des workflows et identifiants.

Clé de chiffrement N8N_ENCRYPTION_KEY

n8n chiffre les identifiants enregistrés (clés API, mots de passe, jetons OAuth) avec une clé. Sans variable N8N_ENCRYPTION_KEY, n8n génère une clé aléatoire au premier lancement et la stocke dans le fichier config du dossier .n8n. Si ce dossier est perdu, les identifiants deviennent illisibles, même avec une sauvegarde complète de la base.

1. Générez une clé avant le premier démarrage avec la commande openssl rand -hex 32.
2. Copiez-la dans le fichier .env, puis restreignez ses droits avec chmod 600 .env.
3. Conservez une copie dans un gestionnaire de mots de passe, hors du serveur.
4. Sur une instance déjà lancée, ne créez pas de nouvelle clé : récupérez celle du fichier config existant.

Variables d’environnement essentielles

Réglez GENERIC_TIMEZONE sur Europe/Paris si vos déclencheurs planifiés doivent suivre l’heure française : c’est cette variable qu’utilise le nœud Schedule Trigger.

03Exposer n8n Docker en HTTPS avec un reverse proxy

Le reverse proxy reçoit le trafic sur les ports 80 et 443, obtient et renouvelle le certificat TLS, puis transmet les requêtes à n8n. HTTPS n’est pas optionnel : les identifiants, les jetons OAuth et les données des webhooks transitent par cette connexion.

Traefik, Caddy ou Nginx : lequel choisir

Avec Caddy, le fichier Caddyfile tient en trois lignes. Caddy obtient le certificat Let’s Encrypt et le renouvelle seul :

n8n.example.com {
    reverse_proxy n8n:5678
}

Si vous utilisez Nginx, n’oubliez pas les en-têtes de mise à niveau des connexions (Upgrade et Connection) : l’éditeur de n8n utilise une connexion persistante pour afficher les exécutions en direct.

Configurer l’URL des webhooks

Derrière un proxy, n8n ne connaît pas son adresse publique : il construit les URL de webhooks à partir de N8N_PROTOCOL, N8N_HOST et N8N_PORT, ce qui donne une adresse interne inutilisable. La variable N8N_WEBHOOK_URL fixe l’URL publique de base, ici https://n8n.example.com/.

Les anciens tutoriels utilisent WEBHOOK_URL. Selon la documentation des variables d’endpoints de n8n, cette variable est désormais un alias déprécié de N8N_WEBHOOK_URL : elle fonctionne encore, mais n8n affiche un avertissement au démarrage. Vérifiez dans un nœud Webhook que l’URL affichée commence bien par votre domaine en https.

04Mettre à jour n8n sous Docker sans casser vos workflows

n8n publie des versions très fréquemment, dont des correctifs de sécurité. Sa documentation recommande de mettre à jour au moins une fois par mois, pour éviter de sauter plusieurs versions d’un coup. Le bulletin du 1er octobre 2026, détaillé dans l’article sur les failles de sécurité n8n d’octobre 2026, montre pourquoi cette routine compte.

Fixer une version plutôt que latest

Le tag latest change à chaque publication : un simple redémarrage du serveur ou un docker compose pull peut installer une version majeure sans que vous l’ayez décidé. Fixez la version dans le fichier .env (N8N_VERSION), et ne la changez qu’après avoir lu les notes de version.

• Version stable : celle à utiliser en production.
• Version bêta ou next : pour tester les nouveautés sur une instance de recette uniquement.
• Fixez aussi la version majeure de PostgreSQL : un changement de version majeure demande une migration des données.

Routine de mise à jour en quatre étapes

1. Lisez les notes de version entre votre version et la cible, en cherchant les changements incompatibles.
2. Sauvegardez la base, le volume n8n_data et le fichier .env (voir la section suivante).
3. Modifiez N8N_VERSION dans .env, puis lancez docker compose pull et docker compose up -d.
4. Contrôlez les logs avec docker compose logs -f n8n, puis testez vos workflows critiques et vos webhooks.

Au démarrage, n8n applique parfois des migrations à la base de données. Revenir à l’ancienne image après une migration peut donc exiger de restaurer aussi la sauvegarde de la base : c’est la raison d’être de l’étape 2.

05Sauvegarder et sécuriser votre instance n8n Docker

Une instance n8n concentre des accès à vos outils : CRM, messagerie, Google Sheets, API d’IA. Elle mérite le même soin qu’un serveur de production.

Sauvegarder la base, les volumes et la clé de chiffrement

Selon la page de sauvegarde et restauration de n8n, une sauvegarde complète comprend le dossier .n8n (qui contient la clé de chiffrement) et la base PostgreSQL, sauvegardée avec ses propres outils. Exemple de commandes à lancer depuis le dossier du projet :

mkdir -p backup
docker compose exec -T postgres pg_dump -U n8n -d n8n -F c > backup/n8n-$(date +%F).dump
docker run --rm -v n8n_n8n_data:/data -v "$(pwd)/backup:/backup" alpine \
  tar czf /backup/n8n_data-$(date +%F).tar.gz -C /data .
cp .env backup/env-$(date +%F)

Le nom réel du volume dépend du nom du dossier du projet : vérifiez-le avec docker volume ls. Automatisez ces commandes avec une tâche cron, copiez les archives hors du serveur (stockage objet, autre machine) et testez une restauration au moins une fois.

En complément, la commande n8n export:workflow –backup exporte les workflows en fichiers JSON séparés, pratique pour un historique dans Git. Évitez l’option –decrypted pour les identifiants : la documentation prévient que toutes les données sensibles apparaissent alors en clair.

Authentification, accès et exposition réseau

• Activez la double authentification sur tous les comptes de l’instance.
• Oubliez les variables N8N_BASIC_AUTH des anciens tutoriels : depuis la version 1.0, n8n a supprimé l’authentification basique, et la gestion des utilisateurs est obligatoire.
• Ne publiez pas le port 5678. Docker contourne les règles du pare-feu ufw pour les ports publiés, comme l’explique la documentation de Docker sur le filtrage réseau : un port ouvert dans le fichier Compose reste joignable même si ufw le bloque.
• Limitez les accès SSH (clés uniquement) et n’ouvrez que les ports 22, 80 et 443.
• Désactivez les nœuds inutiles avec la variable NODES_EXCLUDE et limitez les webhooks publics au strict nécessaire.
• Donnez à chaque membre de l’équipe les droits minimaux nécessaires.

06Erreurs fréquentes et checklist avant la mise en production

Ces erreurs reviennent dans la plupart des installations faites à partir de tutoriels incomplets :

• Image en latest : mise à jour majeure subie au redémarrage.
• Aucun volume monté sur /home/node/.n8n : clé de chiffrement perdue à la recréation du conteneur.
• Port 5678 publié en plus du proxy : l’instance reste accessible en HTTP, en contournant HTTPS.
• N8N_SECURE_COOKIE=false conservé d’un test local : à retirer une fois HTTPS en place.
• Webhooks qui affichent localhost : N8N_WEBHOOK_URL absente.
• Déclencheurs planifiés décalés d’une ou deux heures : GENERIC_TIMEZONE non renseignée.
• Sauvegarde jamais restaurée : on découvre trop tard qu’elle était incomplète.

Avant d’ouvrir l’instance à l’équipe, vérifiez cette checklist :

1. Le domaine répond en HTTPS avec un certificat valide.
2. Le compte propriétaire est créé et la double authentification activée.
3. La version de n8n et celle de PostgreSQL sont fixées.
4. La clé de chiffrement est sauvegardée hors du serveur.
5. Une sauvegarde automatique tourne et une restauration a été testée.
6. Seuls les ports 22, 80 et 443 sont accessibles depuis Internet.
7. L’URL d’un webhook de test pointe bien vers votre domaine.

Pour prendre en main l’outil au-delà de l’installation, le guide complet de n8n présente les concepts clés, et la formation n8n permet d’apprendre à construire et maintenir vos propres workflows.

07Questions fréquentes

Comment mettre à jour n8n sous Docker ?

Lisez d’abord les notes de version, puis sauvegardez la base de données, le volume du dossier .n8n et le fichier .env. Modifiez ensuite le tag de version de l’image dans votre configuration, lancez docker compose pull puis docker compose up -d. Contrôlez les logs du conteneur et testez vos workflows critiques. n8n recommande de mettre à jour au moins une fois par mois.

Où sont stockées les données de n8n dans Docker ?

Dans le conteneur, n8n utilise le dossier /home/node/.n8n. Il contient le fichier config avec la clé de chiffrement et, si vous restez sur SQLite, la base de données. Ce dossier doit être monté sur un volume Docker pour survivre à la recréation du conteneur. Avec PostgreSQL, workflows et exécutions sont dans la base, mais le dossier .n8n reste indispensable.

Faut-il PostgreSQL pour n8n ?

Non, n8n fonctionne par défaut avec SQLite, sans configuration. PostgreSQL est recommandé pour une instance de production : il tient mieux la charge, se sauvegarde sans arrêter le service et permet de passer au mode file d’attente. Choisissez-le dès l’installation, car les données SQLite ne sont pas transférées automatiquement vers une nouvelle base PostgreSQL.

Peut-on faire tourner n8n en local avec Docker ?

Oui. Une commande docker run avec un volume monté sur /home/node/.n8n et le port 5678 suffit pour tester n8n sur votre poste, à l’adresse http://localhost:5678. Les webhooks ne seront en revanche pas joignables depuis Internet. Pour des workflows déclenchés par des services externes, un serveur avec nom de domaine et HTTPS reste nécessaire.

Comment sauvegarder une instance n8n ?

Sauvegardez trois éléments : la base de données (pg_dump pour PostgreSQL, copie du dossier .n8n n8n arrêté pour SQLite), le volume du dossier .n8n qui contient la clé de chiffrement, et le fichier .env. Automatisez ces sauvegardes, stockez-les hors du serveur et testez une restauration. Sans la clé de chiffrement, les identifiants restaurés restent illisibles.