Installer n8n avec Docker : la configuration qu’on fait tourner en production

Cet article fait partie de notre guide Agence n8n : automatiser avec n8n et les outils no code.

On fait tourner n8n en auto-hébergé depuis plus d’un an, sur un VPS où cohabitent une vingtaine de conteneurs. Nos workflows clients passent tous par là : relances de factures, prospection, génération de carrousels, synchronisation de CRM. Autant dire qu’une instance n8n qui tombe un vendredi soir, on l’a vécu, et plus d’une fois.

Cet article n’est pas une traduction de la doc. C’est la configuration Docker qu’on utilise vraiment, variable par variable, avec les trois pannes qui nous ont appris à la régler comme ça. Si vous voulez juste tester n8n sur votre ordinateur, la première partie suffit. Si vous voulez le mettre en production pour de vrai, lisez jusqu’au bout.

Docker ou Docker Compose : lequel choisir

La réponse courte : Docker Compose, dès que vous dépassez le test. C’est d’ailleurs ce que dit n8n lui-même : la page de documentation sur l’installation avec une simple commande docker run est aujourd’hui marquée comme obsolète, au profit de l’installation avec Docker Compose.

La raison est simple. Une instance n8n sérieuse, ce n’est plus un seul conteneur. Il faut au minimum n8n et son conteneur de task runners à côté, souvent une base PostgreSQL, et un reverse proxy pour le HTTPS. Décrire tout ça dans un fichier, c’est pouvoir le relancer à l’identique, le versionner et le relire six mois plus tard.

docker run garde un intérêt : tester n8n sur votre machine en deux minutes, sans rien écrire.

Tester n8n en local en deux minutes

Il vous faut Docker Desktop (Mac, Windows) ou Docker Engine (Linux). Sous Windows, n8n recommande de passer par WSL et de garder vos fichiers dans le système de fichiers Linux, pas dans /mnt/c, sinon les montages sont lents et les droits posent problème.

Ensuite, deux commandes, tirées de la documentation officielle :

docker volume create n8n_data

docker run -it --rm \
  --name n8n \
  -p 5678:5678 \
  -e GENERIC_TIMEZONE="Europe/Paris" \
  -e TZ="Europe/Paris" \
  -e N8N_ENFORCE_SETTINGS_FILE_PERMISSIONS=true \
  -v n8n_data:/home/node/.n8n \
  n8nio/n8n

Ouvrez http://localhost:5678, créez votre compte propriétaire, c’est prêt. Le volume n8n_data garde vos workflows et vos identifiants entre deux redémarrages.

Deux détails qui vous éviteront de chercher. D’abord, les deux variables de fuseau horaire ne font pas la même chose : GENERIC_TIMEZONE règle l’heure des déclencheurs planifiés de n8n, TZ règle l’heure du système du conteneur. Mettez les deux, sinon votre workflow « tous les jours à 9 h » part à 7 h. Ensuite, la variable N8N_RUNNERS_ENABLED=true qu’on voit encore partout dans les tutos est dépréciée depuis n8n 2.0 : les runners sont actifs par défaut, vous n’avez plus besoin de la mettre.

Notre fichier Docker Compose de production

Voici la structure qu’on fait tourner, simplifiée pour être lisible et sans nos secrets. Elle suppose un reverse proxy devant (on utilise Traefik, Caddy ou Nginx font le même travail) qui gère le certificat HTTPS.

services:
  n8n:
    image: n8nio/n8n:2.39.7
    restart: always
    expose:
      - 5678
    environment:
      - N8N_HOST=n8n.votre-domaine.fr
      - N8N_PORT=5678
      - N8N_PROTOCOL=https
      - WEBHOOK_URL=https://n8n.votre-domaine.fr/
      - NODE_ENV=production
      - GENERIC_TIMEZONE=Europe/Paris
      - TZ=Europe/Paris
      - N8N_RUNNERS_MODE=external
      - N8N_RUNNERS_AUTH_TOKEN=${N8N_RUNNERS_AUTH_TOKEN}
      - N8N_RUNNERS_BROKER_LISTEN_ADDRESS=0.0.0.0
      - EXECUTIONS_TIMEOUT=1800
      - EXECUTIONS_TIMEOUT_MAX=3600
      - EXECUTIONS_DATA_PRUNE=true
      - EXECUTIONS_DATA_MAX_AGE=336
      - EXECUTIONS_DATA_PRUNE_MAX_COUNT=30000
      - N8N_DIAGNOSTICS_ENABLED=false
      - N8N_PERSONALIZATION_ENABLED=false
      - NODE_OPTIONS=--max-old-space-size=4096
    volumes:
      - n8n_data:/home/node/.n8n
      - ./fichiers:/files

  n8n-task-runners:
    image: n8nio/runners:2.39.7
    restart: always
    network_mode: "service:n8n"
    environment:
      - N8N_RUNNERS_AUTH_TOKEN=${N8N_RUNNERS_AUTH_TOKEN}
      - N8N_RUNNERS_TASK_BROKER_URI=http://127.0.0.1:5679
    depends_on:
      - n8n

volumes:
  n8n_data:

Le secret N8N_RUNNERS_AUTH_TOKEN va dans un fichier .env à côté, jamais dans le fichier Compose ni dans Git. Générez une vraie chaîne aléatoire, pas l’exemple de la doc.

Vous remarquerez que les deux images portent un numéro de version. Ce n’est pas un détail, on y revient plus bas : c’est la leçon la plus coûteuse qu’on ait apprise.

Les variables qui comptent vraiment

La doc recommande au moins 4 Go de RAM et 2 vCPU pour une installation complète. C’est notre constat aussi : en dessous, ça tourne, mais le premier workflow qui manipule un gros fichier fait tomber l’instance.

Les task runners : le point que tout le monde rate

Quand vous utilisez un nœud Code, en JavaScript ou en Python, n8n n’exécute pas ce code dans son propre processus. Il l’envoie à un « task runner ». Il existe deux modes.

• Le mode interne : n8n lance lui-même le runner comme un sous-processus, avec les mêmes droits. C’est le mode par défaut si vous ne précisez rien. La documentation le dit sans détour : il est « insecure by design », il est déprécié à partir de n8n 3.0, et un code qui sortirait du bac à sable aurait accès à vos identifiants et à votre clé de chiffrement.
• Le mode externe : un conteneur séparé, l’image n8nio/runners, exécute le code à côté de n8n. C’est ce qu’on utilise, et c’est ce que n8n recommande pour toute instance qui contient des données sensibles.

Concrètement, c’est le deuxième service de notre fichier Compose. Trois points à ne pas rater : le même N8N_RUNNERS_AUTH_TOKEN des deux côtés, N8N_RUNNERS_BROKER_LISTEN_ADDRESS=0.0.0.0 côté n8n pour accepter la connexion, et surtout la même version pour les deux images. La doc est explicite : la version de n8nio/runners doit correspondre à celle de n8nio/n8n.

SQLite ou PostgreSQL

Par défaut, n8n stocke tout dans un fichier SQLite à l’intérieur du volume. Pour être transparent : notre instance tourne encore en SQLite, avec la purge des exécutions à 14 jours, et elle tient la charge de nos workflows. Mais si vous démarrez aujourd’hui, prenez PostgreSQL. La doc le recommande dès que l’instance sert plus d’une poignée d’utilisateurs ou tourne en continu, et migrer après coup demande d’exporter et réimporter workflows et identifiants.

Avec PostgreSQL, il faut ajouter un service postgres au fichier Compose et ces variables côté n8n : DB_TYPE=postgresdb, DB_POSTGRESDB_HOST, DB_POSTGRESDB_PORT, DB_POSTGRESDB_DATABASE, DB_POSTGRESDB_USER, DB_POSTGRESDB_PASSWORD. Gardez quand même le volume /home/node/.n8n : il contient la clé de chiffrement de vos identifiants. Sans elle, une base restaurée est illisible.

Mettre à jour sans tout casser

n8n sort une version mineure presque chaque semaine. Au moment où j’écris, la version stable est la 2.39.7. La tentation est de mettre n8nio/n8n sans numéro, pour avoir toujours la dernière. C’est exactement ce qu’on avait fait, et c’est une mauvaise idée pour deux raisons.

• Sans version fixée, un simple redémarrage du serveur peut télécharger une nouvelle version sans que vous l’ayez décidé, avec les changements qui vont avec.
• Pire : l’image des runners et l’image de n8n peuvent se désynchroniser, puisqu’elles sont téléchargées à des moments différents. Et on a vu plus haut qu’elles doivent avoir la même version.

Notre routine maintenant : lire les notes de version, changer le numéro sur les deux images en même temps, faire une sauvegarde du volume, puis relancer.

docker compose pull
docker compose up -d

Et vérifier dans la foulée qu’un workflow avec un nœud Code s’exécute bien. C’est le premier symptôme quand quelque chose ne va pas.

Nos trois pannes, et ce qu’elles nous ont appris

1. Les nœuds Code figés pendant 40 heures

Un matin, tous nos workflows avec un nœud Code tombaient en erreur avec le message « Task request timed out after 600 seconds ». n8n tournait, l’interface répondait, les workflows sans code marchaient. Le coupable : le conteneur des runners s’était arrêté après un redémarrage du serveur et n’était pas reparti, malgré le restart: always. Le correctif prend dix secondes :

docker compose up -d n8n-task-runners

Le vrai problème, c’est qu’on ne s’en est rendu compte qu’au bout de 40 heures. Depuis, on a une surveillance indépendante de n8n (un simple script système, pas un workflow n8n, puisque c’est n8n qu’on surveille) qui vérifie toutes les deux minutes que le conteneur des runners est en vie et nous envoie un mail sinon.

2. Un workflow incapable de joindre notre propre serveur

Un workflow devait envoyer des images vers notre propre service de stockage, hébergé sur le même serveur. Résultat : délai dépassé, sans erreur claire. Le conteneur n8n résolvait notre domaine vers l’adresse de Cloudflare, la requête sortait sur Internet, revenait sur notre serveur, et le pare-feu la bloquait parce qu’elle ne venait pas de Cloudflare. La solution tient en deux lignes dans le fichier Compose :

    extra_hosts:
      - "stockage.votre-domaine.fr:host-gateway"

Le conteneur joint alors directement la machine hôte. Si un de vos workflows appelle un service hébergé sur la même machine, pensez-y avant de passer une journée dessus comme nous.

3. Des journaux Docker qui faisaient tomber tout le serveur

Celle-là est vicieuse. Un ancien script de rotation des journaux tronquait les fichiers de logs des conteneurs pendant que Docker écrivait dedans. Les fichiers se retrouvaient corrompus, et le simple fait de lire les logs de n8n faisait monter le processeur à fond. Toute la machine ralentissait. La règle qu’on applique maintenant : on laisse Docker gérer lui-même la rotation, dans /etc/docker/daemon.json, avec une taille maximale et un nombre de fichiers, et on ne touche jamais aux fichiers de logs à la main.

Auto-hébergé ou n8n Cloud ?

n8n dit lui-même que l’auto-hébergement s’adresse aux utilisateurs expérimentés, et que les erreurs peuvent mener à des pertes de données, des failles de sécurité et des pannes. Après un an, on est d’accord. L’auto-hébergement, c’est des exécutions illimitées, vos données chez vous et la liberté d’installer ce que vous voulez. En échange, les mises à jour, les sauvegardes et les pannes sont pour vous.

Si vous n’avez personne pour s’en occuper, n8n Cloud reste un bon choix pour démarrer. Et si vous voulez l’auto-hébergement sans la maintenance, c’est précisément ce qu’on fait pour nos clients en tant qu’agence n8n. Pour aller plus loin sur l’outil lui-même, notre tutoriel pour créer vos premiers workflows et notre comparatif n8n ou Make sont là.

Questions fréquentes

Quelle configuration minimale pour faire tourner n8n avec Docker ?

La documentation de n8n recommande au moins 4 Go de RAM et 2 vCPU pour une installation complète. Pour un simple test en local, un ordinateur récent suffit.

Faut-il encore mettre N8N_RUNNERS_ENABLED=true ?

Non, depuis n8n 2.0 cette variable est dépréciée et les runners sont actifs par défaut. En revanche, pour la production, il faut passer en mode externe avec N8N_RUNNERS_MODE=external et un conteneur n8nio/runners à côté.

Mes webhooks affichent localhost, pourquoi ?

Il manque la variable WEBHOOK_URL avec votre adresse publique en HTTPS. n8n l’utilise pour construire toutes les URL de webhooks.

Comment sauvegarder une instance n8n sous Docker ?

Sauvegardez le volume monté sur /home/node/.n8n, qui contient la clé de chiffrement, et votre base PostgreSQL si vous en utilisez une. Sans la clé, les identifiants enregistrés sont illisibles après restauration.

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

La version communautaire auto-hébergée est gratuite, sans limite d’exécutions. Vous payez l’hébergement, et le temps de maintenance.

Alexandre Damais, cofondateur d’A2Z Automation. Article écrit à partir de notre instance n8n de production et de la documentation officielle de n8n, consultée le 18 septembre 2026.