n8n auto-hébergé avec Docker : ce que la production demande

Installer un n8n auto-hébergé avec Docker prend quelques commandes, que la documentation de n8n sur Docker Compose donne pas à pas. Elle s’ouvre pourtant sur une mise en garde : l’éditeur recommande l’auto-hébergement aux utilisateurs expérimentés, car une erreur peut coûter des données, de la sécurité ou du temps d’arrêt. Entre l’instance qui démarre et celle à qui l’on confie de vrais processus, il reste des décisions à prendre.

Nous en avons pris plusieurs pour notre propre serveur, qui fait tourner une douzaine de services en conteneurs Docker pour cinq entreprises clientes, derrière un routeur Traefik. n8n y exécute nos workflows de production, dont un agent de saisie de dépenses sur Telegram et celui qui attribue un identifiant interne à chaque nouveau bien dans le CRM de Palmora, un portail immobilier que nous opérons. Ce guide croise la documentation de l’éditeur et cette exploitation.

En bref

• Docker Compose derrière un proxy HTTPS, avec une version épinglée et un fichier de configuration versionné, sans les secrets.
• La clé de chiffrement protège vos identifiants : fixez-la avant le premier démarrage et gardez-en une copie hors du serveur.
• SQLite suffit pour essayer ; nous recommandons PostgreSQL dès les premiers processus de production.
• La télémétrie est active par défaut et se coupe par des variables d’environnement, pas dans l’interface.
• En auto-hébergement, le RGPD est à votre charge : l’éditeur n’est ni responsable de traitement ni sous-traitant.

Docker ou Docker Compose ?

La page de la documentation qui installe n8n avec Docker seul est signalée comme dépassée par l’éditeur lui-même, qui renvoie vers Docker Compose : un seul fichier décrit les conteneurs, leurs volumes et leurs variables, et il se versionne comme du code.

Le modèle de l’éditeur pose deux conteneurs : n8n, et Traefik, un proxy qui obtient les certificats et redirige tout vers HTTPS. Le port de n8n n’écoute que sur la machine elle-même (127.0.0.1:5678) : seul le proxy est exposé. Les données vivent dans un volume, n8n_data, monté sur /home/node/.n8n ; c’est là que n8n range sa base SQLite et sa clé de chiffrement.

Deux ajouts au modèle : gardez les secrets (mot de passe de la base, clé de chiffrement) dans un fichier d’environnement qui ne part pas dans le dépôt, et remplacez l’image qui suit la dernière version par une version précise.

SQLite ou PostgreSQL ?

Sans réglage, n8n enregistre ses workflows, ses identifiants et l’historique des exécutions dans une base SQLite, un fichier rangé dans son volume. La documentation de l’installation avec Docker explique le passage à PostgreSQL : la variable DB_TYPE=postgresdb et les variables DB_POSTGRESDB_* (hôte, base, utilisateur, mot de passe). Elle recommande de conserver le dossier /home/node/.n8n même avec PostgreSQL : il contient d’autres données importantes, dont les clés de chiffrement et les journaux de l’instance.

SQLite suffit pour essayer n8n sur une instance seule. Dès que le travail se répartit sur plusieurs processus, la documentation du mode file d’attente déconseille SQLite, et ne prend pas en charge un système distribué qui reposerait dessus. Nous recommandons PostgreSQL dès qu’une instance porte des processus de production : la base se sauvegarde avec ses propres outils, comme nous le détaillons dans notre guide de la sauvegarde d’un serveur à soi, et le passage au mode file d’attente, s’il vient un jour, ne demandera pas de changer de base.

La clé de chiffrement, le secret à ne jamais perdre

n8n chiffre les identifiants que vous lui confiez (clés d’API, mots de passe des services connectés) avant de les enregistrer en base. Selon la documentation sur la clé de chiffrement, il crée une clé aléatoire au premier démarrage et la range dans son dossier de données ; on peut fixer la sienne avec la variable N8N_ENCRYPTION_KEY, tant que la clé ne figure pas déjà dans le fichier de réglages. Deux conséquences :

• Fixez-la avant le premier démarrage, et gardez-en une copie dans un gestionnaire de secrets, hors du serveur.
• Une restauration demande les deux, la base et la clé : sans la clé, les identifiants enregistrés ne peuvent plus être déchiffrés, et il faudrait les recréer un par un.

Quelles variables régler avant la mise en production ?

Le modèle de l’éditeur en règle une partie. Voici celles à vérifier avant le premier processus réel, d’après la documentation de n8n sur les webhooks derrière un proxy, le fuseau horaire et les données d’exécution.

Comment mettre à jour n8n sans casser la production ?

Selon sa documentation Docker Compose, n8n publie une nouvelle version mineure la plupart des semaines : la stable sert la production, la bêta est plus récente et peut être instable. Une image qui suit la dernière version peut vous faire monter de plusieurs versions d’un coup, sans l’avoir décidé. Nous recommandons :

1. Épingler une version précise dans le fichier Compose, plutôt que la dernière.
2. Lire les notes de version, surtout au passage d’une version majeure : la 2.0 a par exemple désactivé par défaut le nœud Execute Command.
3. Sauvegarder la base et vérifier la clé juste avant.
4. Monter, puis vérifier : docker compose pull, docker compose down, puis docker compose up -d, comme l’indique la documentation. Ouvrez ensuite un workflow critique et regardez sa prochaine exécution.

Et jamais de nettoyage global du serveur à cette occasion : c’est une commande de ce genre qui a supprimé chez nous les conteneurs de dix services en juillet 2026.

Faut-il passer au mode file d’attente ?

Le mode file d’attente répartit les exécutions entre plusieurs workers, par une file tenue par Redis. Selon sa documentation, il demande EXECUTIONS_MODE=queue et la même clé de chiffrement sur chaque processus et, si vos workflows doivent conserver des fichiers, un stockage externe de type S3 : ce mode ne prend pas en charge leur stockage sur le disque du serveur.

Commencez par une instance seule bien réglée, et ne découpez qu’après avoir mesuré ce qui ralentit.

Qu’est-ce qui n’a pas sa place dans n8n ?

Avec Docker, le nœud Execute Command lance ses commandes dans le conteneur de n8n, pas sur le serveur, et il est désactivé par défaut depuis la version 2.0. Le conteneur ne voit que les dossiers qu’on lui a montés. Lui ouvrir l’accès au serveur, par exemple au moteur Docker, donnerait ce pouvoir à chaque workflow et à chaque personne qui peut en modifier un.

D’où la règle que nous recommandons : les tâches qui ont besoin des outils du serveur (sauvegardes, nettoyages, scripts qui publient un site) vont dans le planificateur du serveur ou dans l’intégration continue, pas dans n8n. La synchronisation quotidienne des biens de Palmora tourne ainsi dans le planificateur d’un serveur, avec une reprise manuelle depuis l’intégration continue. n8n garde ce qu’il fait le mieux : relier des services par leurs API.

La télémétrie : ce qui part chez l’éditeur

Selon sa page sur la confidentialité, n8n ne reçoit jamais les données de vos workflows quand vous l’hébergez. Sa télémétrie, active par défaut et présentée comme anonyme, comprend notamment une adresse IP tronquée, le domaine principal des adresses appelées par les nœuds HTTP Request et des appels de webhooks, sans sous-domaine ni chemin, et des informations sur l’instance, l’usage et les erreurs. La page sur la télémétrie y ajoute le nombre d’exécutions et un signal de l’instance toutes les six heures.

Il n’y a pas d’interrupteur dans l’interface : tout se coupe par des variables d’environnement, réunies dans le guide pour isoler une instance. Avec une licence payante, l’instance continue de déclarer ses volumes d’usage et son identifiant de licence, et cela ne se désactive pas. Suivre ce guide coupe aussi l’annonce des nouvelles versions dans l’interface : surveiller les notes de version devient votre travail.

Le RGPD, à votre charge

La page sur la confidentialité le dit sans détour : en auto-hébergement, n8n n’est ni responsable de traitement ni sous-traitant. Quatre points demandent donc une décision de votre part.

• L’historique des exécutions garde des données personnelles. Pour effacer celles d’une personne, n8n indique de supprimer les exécutions qui la concernent et recommande de régler leur purge ; notre guide pour superviser n8n en production détaille ce qu’il garde et combien de temps.
• Le masquage des données d’exécution est réservé à l’édition Enterprise en auto-hébergement, selon sa documentation : sans lui, l’historique reste lisible par qui y a accès.
• Chaque service appelé reçoit des données. Une API de modèle d’IA ou un outil d’emailing est un sous-traitant de plus, avec son contrat.
• Le registre et les contrats. Le traitement entre dans votre registre des activités de traitement, et l’hébergeur de votre serveur est un sous-traitant, à lier par un contrat conforme à l’article 28 du RGPD. La CNIL, dans sa fiche sur la sous-traitance, déconseille d’« avoir recours à des services de cloud sans garantie quant à la localisation géographique effective des données ».

Ce guide dit où regarder ; il ne remplace pas un avis juridique sur votre traitement.

Les limites honnêtes

• L’auto-hébergement déplace le coût, il ne le supprime pas : le serveur, les sauvegardes, des mises à jour fréquentes et quelqu’un qui surveille.
• Aucune garantie de disponibilité d’un éditeur : la nuit, c’est votre alerte qui prévient, ou personne.
• L’édition Community n’inclut ni le SSO ni le partage des workflows : nous détaillons ce que permet la licence de n8n.

Par où commencer

Commencez par un inventaire : les processus que n8n portera, les données qu’ils touchent, et qui reçoit les alertes. Puis, dans l’ordre : le fichier Compose versionné et la clé hors du serveur, la base, les variables, la décision sur la télémétrie, et une première restauration testée avant le premier processus en production.

Si n8n n’est qu’un des outils à installer, notre guide du socle d’infrastructure commun à vos projets pose le cadre ; si vous hésitez encore à l’héberger, lisez notre comparatif de n8n, Make et Zapier. Pour un serveur installé, sauvegardé et suivi, notre sortie du SaaS installe jusqu’à cinq outils, avec l’infogérance en option ; si ce sont les processus eux-mêmes qu’il faut construire, c’est notre offre d’automatisation.

Questions fréquentes

Où se trouve la clé de chiffrement de n8n ?

n8n la crée au premier démarrage et la range dans son dossier de données, le volume n8n_data dans le modèle Docker Compose de l’éditeur. Fixez la vôtre avec la variable N8N_ENCRYPTION_KEY avant ce premier démarrage, et gardez-en une copie hors du serveur : une base restaurée sans sa clé ne permet plus de lire les identifiants enregistrés.

SQLite ou PostgreSQL pour n8n en production ?

SQLite, la base par défaut, suffit pour essayer n8n sur une instance seule. Le mode file d’attente, qui répartit le travail sur plusieurs processus, la déconseille, et n8n ne prend pas en charge un système distribué qui reposerait dessus. Nous recommandons PostgreSQL dès les premiers processus de production, sauvegardé avec ses propres outils.

Comment mettre à jour n8n installé avec Docker ?

La documentation enchaîne trois commandes : docker compose pull, docker compose down, puis docker compose up -d. Avant, lisez les notes de version, sauvegardez la base et vérifiez que la clé de chiffrement est en lieu sûr. Une version épinglée fait de chaque mise à jour un changement décidé, et la sauvegarde permet de revenir en arrière.

Faut-il désactiver la télémétrie de n8n ?

C’est une décision, pas une obligation. n8n la présente comme anonyme : une adresse IP tronquée, le domaine des services appelés, l’usage et les erreurs, jamais les données des workflows. Elle se coupe par des variables d’environnement ; avec une licence payante, la déclaration d’usage liée à la licence reste active. Notez votre choix avec la configuration de l’instance.