Déployer n8n avec Docker est la façon la plus simple et la plus reproductible d'auto-héberger cet outil d'automatisation de flux de travail. Ce guide n8n Docker vous montre comment passer de l'image officielle à une installation prête pour la production, avec une base PostgreSQL, un volume persistant, une clé de chiffrement stable et le mode queue pour la montée en charge. Nous terminons par un déploiement clé en main sur Out Plane, où la base PostgreSQL est gérée pour vous et le HTTPS est automatique.
En bref : Pour exécuter n8n avec Docker en production, utilisez l'image officielle docker.n8n.io/n8nio/n8n, un volume persistant sur /home/node/.n8n, une base PostgreSQL (DB_TYPE=postgresdb) plutôt que SQLite, une N8N_ENCRYPTION_KEY fixe et une WEBHOOK_URL publique. Pour passer à l'échelle, activez le mode queue avec un conteneur Redis et des processus worker séparés.
Pourquoi lancer n8n avec Docker
n8n distribue une image Docker officielle, ce qui en fait le mode d'installation recommandé pour l'auto-hébergement. Vous obtenez un environnement isolé, des mises à jour prévisibles (il suffit de changer le tag d'image) et une configuration entièrement pilotée par des variables d'environnement. Pas de dépendances Node.js à gérer sur l'hôte, pas de conflits de versions.
n8n est un outil d'automatisation de flux de travail open source qui connecte vos applications et vos API sans écrire de code. Auto-hébergé avec Docker, il exécute vos scénarios sur votre propre infrastructure, ce qui vous laisse le contrôle total de vos données et de vos identifiants.
Le piège classique de la première installation : tout garder en configuration par défaut. n8n démarre alors sur une base SQLite locale, sans clé de chiffrement fixe et sans volume déclaré. Le jour où vous supprimez le conteneur, vos workflows et vos identifiants disparaissent. Les trois sections suivantes règlent chacun de ces points.
Démarrer n8n avec Docker en une commande
Pour un test rapide en local, l'image officielle suffit. Le point important est le volume monté sur /home/node/.n8n, le répertoire où n8n stocke sa base SQLite, sa clé de chiffrement générée et ses fichiers.
docker run -it --rm \
--name n8n \
-p 5678:5678 \
-v n8n_data:/home/node/.n8n \
docker.n8n.io/n8nio/n8nL'interface est disponible sur http://localhost:5678. C'est parfait pour découvrir l'outil, mais ce n'est pas une configuration de production : SQLite tient mal la charge et la clé de chiffrement est générée aléatoirement au premier lancement. Passons à une base sérieuse.
Docker Compose avec PostgreSQL
En production, remplacez SQLite par PostgreSQL. n8n bascule de moteur dès que vous définissez DB_TYPE=postgresdb et les variables de connexion associées. Voici un fichier docker-compose.yml complet et commenté.
services:
postgres:
image: postgres:16
restart: always
environment:
- POSTGRES_USER=n8n
- POSTGRES_PASSWORD=mot_de_passe_solide
- POSTGRES_DB=n8n
volumes:
- postgres_data:/var/lib/postgresql/data
healthcheck:
test: ["CMD-SHELL", "pg_isready -U n8n -d n8n"]
interval: 10s
timeout: 5s
retries: 5
n8n:
image: docker.n8n.io/n8nio/n8n
restart: always
ports:
- "5678:5678"
environment:
- DB_TYPE=postgresdb
- DB_POSTGRESDB_HOST=postgres
- DB_POSTGRESDB_PORT=5432
- DB_POSTGRESDB_DATABASE=n8n
- DB_POSTGRESDB_USER=n8n
- DB_POSTGRESDB_PASSWORD=mot_de_passe_solide
- N8N_ENCRYPTION_KEY=une_cle_longue_generee_une_seule_fois
- N8N_HOST=n8n.exemple.com
- N8N_PROTOCOL=https
- WEBHOOK_URL=https://n8n.exemple.com/
- GENERIC_TIMEZONE=Europe/Paris
volumes:
- n8n_data:/home/node/.n8n
depends_on:
postgres:
condition: service_healthy
volumes:
postgres_data:
n8n_data:Trois réglages méritent une attention particulière.
La N8N_ENCRYPTION_KEY chiffre les identifiants stockés (clés d'API, mots de passe des nœuds). Vous devez la fixer vous-même et ne jamais la changer : si la clé varie entre deux redémarrages, n8n ne peut plus déchiffrer vos identifiants existants.
La clé de chiffrement de n8n protège tous les identifiants enregistrés dans vos workflows. Elle doit rester constante pour toute la durée de vie de l'installation. La perdre revient à perdre l'accès à chaque identifiant chiffré ; la changer casse ceux qui existent déjà.
La WEBHOOK_URL indique à n8n l'adresse publique à utiliser pour construire les URL de webhook. Sans elle, n8n devine une URL locale et vos déclencheurs externes (paiements, formulaires, GitHub) ne reçoivent jamais les appels. Elle doit correspondre au domaine HTTPS réellement exposé.
Le healthcheck PostgreSQL, associé à depends_on ... condition: service_healthy, évite que n8n démarre avant que la base soit prête, une source fréquente d'erreurs au premier lancement.
SQLite ou PostgreSQL pour n8n
Faut-il vraiment abandonner SQLite ? Pour tout ce qui dépasse le prototype, oui. Le tableau ci-dessous résume les différences.
| Critère | SQLite (par défaut) | PostgreSQL |
|---|---|---|
| Configuration | Aucune, activé d'office | Variables DB_* à définir |
| Écritures simultanées | Limitées, verrous fréquents | Excellentes, plusieurs processus |
| Mode queue (montée en charge) | Non recommandé | Requis et recommandé |
| Volume d'exécutions | Petits projets, tests | Production, gros volumes |
| Sauvegardes et PITR | Copie de fichier manuelle | Dumps, récupération à un instant T, réplicas |
| Risque de corruption sous charge | Plus élevé | Faible |
| Idéal pour | Démarrage rapide, dev local | Production, usage en équipe |
En clair : SQLite pour essayer, PostgreSQL dès que des workflows tournent pour de vrai. Si vous hésitez encore sur le socle technique sous-jacent, notre comparatif Kubernetes ou Docker remet ces choix en perspective.
Mode queue avec Redis pour passer à l'échelle
Par défaut, n8n exécute chaque workflow dans son processus principal. Sous forte charge, ce processus devient un goulot d'étranglement. Le mode queue règle le problème en confiant l'exécution à des processus worker dédiés, coordonnés par une file Redis.
Le mode queue de n8n sépare l'interface principale des processus worker qui exécutent réellement les workflows. Les tâches transitent par une file Redis, ce qui permet de répartir la charge sur plusieurs conteneurs et d'absorber les pics d'exécution sans bloquer l'interface.
On active ce mode avec EXECUTIONS_MODE=queue et les variables QUEUE_BULL_REDIS_*. Il faut ensuite au moins un conteneur worker, lancé avec la commande worker. Voici l'ajout à votre docker-compose.yml (le service postgres reste identique).
redis:
image: redis:7-alpine
restart: always
volumes:
- redis_data:/data
n8n:
image: docker.n8n.io/n8nio/n8n
restart: always
ports:
- "5678:5678"
environment:
- EXECUTIONS_MODE=queue
- QUEUE_BULL_REDIS_HOST=redis
- QUEUE_BULL_REDIS_PORT=6379
- DB_TYPE=postgresdb
- DB_POSTGRESDB_HOST=postgres
- DB_POSTGRESDB_DATABASE=n8n
- DB_POSTGRESDB_USER=n8n
- DB_POSTGRESDB_PASSWORD=mot_de_passe_solide
- N8N_ENCRYPTION_KEY=une_cle_longue_generee_une_seule_fois
- WEBHOOK_URL=https://n8n.exemple.com/
depends_on:
- postgres
- redis
n8n-worker:
image: docker.n8n.io/n8nio/n8n
restart: always
command: worker
environment:
- EXECUTIONS_MODE=queue
- QUEUE_BULL_REDIS_HOST=redis
- QUEUE_BULL_REDIS_PORT=6379
- DB_TYPE=postgresdb
- DB_POSTGRESDB_HOST=postgres
- DB_POSTGRESDB_DATABASE=n8n
- DB_POSTGRESDB_USER=n8n
- DB_POSTGRESDB_PASSWORD=mot_de_passe_solide
- N8N_ENCRYPTION_KEY=une_cle_longue_generee_une_seule_fois
depends_on:
- n8n
volumes:
postgres_data:
redis_data:Point crucial : chaque worker doit recevoir exactement la même N8N_ENCRYPTION_KEY et la même connexion PostgreSQL que le processus principal. Sinon, les workers ne peuvent ni déchiffrer les identifiants ni lire les workflows. Pour ajouter de la capacité, il suffit de démarrer d'autres conteneurs n8n-worker. La documentation officielle détaille chaque variable dans le guide du mode queue de n8n.
Déployer n8n sur Out Plane
Docker Compose est idéal en local, mais en production il vous reste à gérer le serveur, les certificats TLS, les sauvegardes de la base et les redémarrages. C'est précisément ce qu'une plateforme comme Out Plane prend en charge. Vous poussez votre code ou un Dockerfile, la plateforme construit l'image et exécute votre application, avec HTTPS automatique. Si le concept vous est nouveau, commencez par qu'est-ce qu'un PaaS.
Voici la traduction directe du Compose ci-dessus en services Out Plane.
1. L'application n8n. Créez une application à partir d'un Dockerfile minimal qui s'appuie sur l'image officielle. Out Plane se charge du build et du run.
FROM docker.n8n.io/n8nio/n8n:latest2. La base PostgreSQL gérée. Plutôt qu'un conteneur postgres que vous opérez vous-même, attachez une base PostgreSQL gérée à votre application. Elle arrive avec sauvegardes, récupération à un instant T (PITR), réplicas de lecture, pooling de connexions et l'extension pgvector. Out Plane injecte la connexion ; vous renseignez côté n8n DB_TYPE=postgresdb et les variables DB_POSTGRESDB_* correspondantes.
3. Les variables d'environnement. Ajoutez N8N_ENCRYPTION_KEY (une valeur longue et stable), EXECUTIONS_MODE=queue si vous voulez la montée en charge, et WEBHOOK_URL pointant vers l'URL publique de votre app. Cette URL suit le motif n8n-5678-monequipe.outplane.app, donc WEBHOOK_URL=https://n8n-5678-monequipe.outplane.app/.
4. Redis en auto-hébergement. Out Plane fournit une base PostgreSQL gérée, mais pas de Redis géré. Pour le mode queue, déployez Redis comme une application dédiée à partir d'un Dockerfile (FROM redis:7-alpine) avec un volume persistant monté sur /data. Les services communiquent sur le réseau privé, sans exposer Redis à Internet.
5. Le worker. Déployez une seconde application depuis le même Dockerfile n8n, mais avec la commande de démarrage worker et les mêmes variables (clé de chiffrement, PostgreSQL, Redis). Pour ajouter de la capacité, dupliquez l'application worker.
Vous pouvez choisir la région où résident vos données, par exemple Nuremberg ou Helsinki, ce qui garde vos exécutions et vos identifiants sur des serveurs situés en Europe. Notez qu'il s'agit d'un choix de localisation des données et non d'une juridiction : Out Plane est une société américaine (Delaware). Ce que vous obtenez concrètement, c'est la résidence des données dans une région européenne. Nous détaillons ces nuances dans notre article sur le cloud souverain européen.
Le reste (certificat TLS, renouvellement, redémarrage automatique du conteneur) est pris en charge par la plateforme. Pour d'autres piles applicatives conteneurisées, notre guide sur l'hébergement Docker suit la même logique.
Questions fréquentes
Quelle base de données utiliser avec n8n dans Docker ?
Utilisez PostgreSQL en production en définissant DB_TYPE=postgresdb et les variables DB_POSTGRESDB_*. SQLite, activé par défaut, convient aux tests locaux mais tient mal les écritures simultanées et interdit en pratique le mode queue. PostgreSQL apporte fiabilité, sauvegardes propres et montée en charge multi-worker.
À quoi sert la clé N8N_ENCRYPTION_KEY ?
Elle chiffre tous les identifiants enregistrés dans vos workflows, comme les clés d'API et les mots de passe. Vous devez la fixer vous-même et ne jamais la modifier : si elle change entre deux démarrages, n8n ne peut plus déchiffrer les identifiants existants. Sauvegardez-la comme un secret critique, au même titre qu'un mot de passe de base.
Pourquoi mes webhooks n8n ne fonctionnent-ils pas ?
Le plus souvent, la variable WEBHOOK_URL est absente ou incorrecte. Sans elle, n8n génère des URL locales que les services externes ne peuvent pas joindre. Renseignez-y l'adresse HTTPS publique exacte de votre installation, terminée par une barre oblique, et vérifiez que le domaine correspond bien à celui exposé par votre reverse proxy.
Qu'est-ce que le mode queue de n8n et quand l'activer ?
Le mode queue (EXECUTIONS_MODE=queue) délègue l'exécution des workflows à des processus worker séparés, coordonnés par Redis. Activez-le dès que le volume d'exécutions sature le processus principal ou que vous voulez répartir la charge sur plusieurs conteneurs. En dessous de ce seuil, le mode par défaut reste plus simple à opérer.
Peut-on utiliser n8n sans Redis ?
Oui. Redis n'est nécessaire qu'en mode queue. En mode d'exécution par défaut, n8n traite les workflows dans son processus principal, sans file externe. Pour un usage modéré, une seule instance avec PostgreSQL suffit largement. Ajoutez Redis et des workers uniquement lorsque vous avez besoin de passer à l'échelle horizontalement.
Out Plane propose-t-il un Redis géré pour n8n ?
Non. La base de données gérée d'Out Plane est PostgreSQL uniquement (avec sauvegardes, PITR, réplicas et pgvector). Pour le mode queue de n8n, déployez Redis comme un conteneur applicatif que vous opérez, avec un volume persistant, relié à n8n via le réseau privé. C'est la même démarche que pour tout service auto-hébergé.
n8n est-il gratuit en auto-hébergement ?
L'édition Community de n8n est gratuite et open source ; vous ne payez que l'infrastructure qui l'héberge. Sur Out Plane, un palier Hobby gratuit et un crédit d'essai de 20 $ sans carte permettent de démarrer, avant de passer au paiement à l'usage. Voir aussi notre guide sur l'hébergement gratuit pour développeurs.
Conclusion
Une installation n8n Docker durable tient en quelques principes : image officielle, volume persistant, base PostgreSQL au lieu de SQLite, clé de chiffrement fixe, WEBHOOK_URL correcte, et mode queue avec Redis quand le volume l'exige. Docker Compose couvre tout cela en local ; en production, une plateforme gérée vous décharge du TLS, des sauvegardes et des redémarrages.
Prochaine étape concrète : créez votre application n8n et attachez une base PostgreSQL gérée depuis la console sur console.outplane.com, puis consultez les tarifs pour dimensionner votre usage. Pour approfondir la configuration côté n8n, appuyez-vous sur la documentation Docker officielle de n8n et sur la référence des variables d'environnement.