Sommaire
En bref
- Une installation n8n docker compose se justifie lorsque l’équipe peut administrer le serveur, suivre les exécutions et restaurer les données.
- Avant de créer un workflow, préparez Docker, le réseau, le stockage persistant et la responsabilité de supervision.
- Le volume
n8n_dataconserve les données locales et la clé de chiffrement : sa perte peut rendre les identifiants inutilisables.- Un proxy inverse, HTTPS et une URL publique correcte conditionnent les webhooks exposés sur Internet.
- Toute montée de version commence par une sauvegarde complète et une recette.
Un processus récurrent finit souvent par s’installer dans les habitudes : une personne copie une donnée, une autre vérifie un statut, puis une boîte mail sert de journal de fait. Avant de choisir n8n docker compose, il faut regarder ce travail tel qu’il se déroule : qui le lance, quelles données circulent, quel déclencheur le nourrit et qui traite l’exception.
En 2026, l’instance auto-hébergée convient lorsque cette responsabilité d’exploitation trouve un propriétaire identifié. Sinon, la version infogérée mérite un examen sérieux. Le serveur d’automatisation ne résout pas un processus mal défini : il rend ses règles, ses erreurs et ses dépendances visibles.
Avant n8n docker compose : vérifier que l’auto-hébergement est justifié
Les prérequis serveur, Docker Engine et Docker Compose à contrôler
Le guide officiel couvre l’exécution sur un serveur Linux. Commencez par vérifier que l’hôte porte Docker Engine et Docker Compose :
docker --version
docker compose versionLa documentation fournie ne fixe pas de ressources matérielles chiffrées. Il faut donc les cadrer à partir des workflows prévus : volume d’exécutions, fichiers manipulés, appels API, concurrence et conservation des journaux. Une instance qui traite quelques échanges déterministes ne sollicite pas le serveur comme un traitement qui attend des réponses externes ou déplace des documents.
Désignez aussi la personne qui lit les alertes, contrôle les sauvegardes et réalise la montée de version. Cette fonction compte autant que le conteneur Docker.
Réseau local, accès distant et sous-domaine dédié
Pour un usage sur Internet ou sur un réseau, la documentation n8n demande un sous-domaine dédié, relié au serveur par un enregistrement A. Cette adresse devient le point d’entrée des utilisateurs et des webhooks.
Un accès local peut rester limité au réseau concerné. Un accès distant impose un nom de domaine, un reverse proxy et un certificat HTTPS valide. Préparez cette chaîne avant de publier un déclencheur webhook : une URL provisoire dans un workflow finit souvent dans la configuration d’un service tiers, puis bloque lors du changement d’adresse.
Les situations où automatiser ou auto-héberger n’est pas rentable
Renoncez ou reportez le projet quand les règles changent chaque semaine, que personne ne peut expliquer la décision prise, ou que l’exception exige systématiquement un jugement humain. Un modèle de langage ne corrige pas ce défaut : une règle déterministe reste plus lisible et plus facile à tester lorsqu’elle couvre le besoin.
L’auto-hébergement perd aussi son intérêt si personne ne peut assurer la supervision, sauvegarder l’instance et intervenir après une erreur. Dans ce cas, une version infogérée réduit la charge d’infrastructure, sans supprimer le cadrage métier ni la recette.
Construire le fichier n8n docker compose et conserver les données
Créez un répertoire dédié, par exemple n8n-compose, qui contient le fichier Compose et le fichier .env. La documentation officielle illustre cette séparation avec le domaine, le sous-domaine, le fuseau horaire et l’adresse utilisée pour le certificat.
Séparer la configuration et les secrets du fichier Compose
Le fichier Compose définit les services et leurs volumes. Le fichier .env porte les valeurs propres à l’environnement, comme le domaine et le fuseau horaire. Ne placez pas les jetons d’API dans un dépôt partagé. n8n accepte aussi un fichier séparé pour une variable en ajoutant le suffixe _FILE à son nom.
Voici le noyau de persistance à conserver dans votre fichier Compose :
services:
n8n:
image: n8nio/n8n:stable
env_file: .env
volumes:
- n8n_data:/home/node/.n8n
volumes:
n8n_data:Cette base doit rejoindre la configuration réseau retenue lors du cadrage. Pour une publication HTTPS, le guide n8n associe notamment Traefik au fichier Compose.
Configurer N8N_HOST, N8N_PORT, N8N_PROTOCOL et le fuseau horaire
Derrière un proxy inverse, le service écoute en interne sur le port 5678, tandis que le proxy reçoit les requêtes publiques. Le guide officiel configure N8N_HOST, N8N_PORT, N8N_PROTOCOL, N8N_WEBHOOK_URL, GENERIC_TIMEZONE et TZ.
Le fuseau horaire mérite une vérification de recette. Un workflow planifié peut envoyer un traitement au mauvais moment si le serveur, n8n et le métier ne parlent pas la même heure. Définissez aussi N8N_RESTRICT_FILE_ACCESS_TO=/files lorsque votre scénario manipule des fichiers dans le cadre prévu.
Pourquoi le volume persistant est indispensable
Le volume n8n_data, monté dans /home/node/.n8n, conserve la base SQLite par défaut et la clé de chiffrement. Ce répertoire garde également d’autres éléments utiles à l’instance, dont des journaux et des actifs liés au contrôle de source.
Un fichier Compose recrée facilement un conteneur. Il ne recrée pas les données qu’un volume absent a effacées. Cette distinction gouverne tout le déploiement n8n : les workflows, les identifiants chiffrés et les réglages doivent survivre au cycle normal d’arrêt et de recréation.
Démarrer n8n docker compose et contrôler la première exécution
Lancez les services depuis le répertoire qui contient le fichier Compose :
sudo docker compose up -d
docker compose psdocker compose ps liste les conteneurs du projet, leur état et les ports exposés. Ajoutez --all pour voir aussi les conteneurs arrêtés.
Lancer les services et vérifier leur état
Dans l’exemple officiel avec domaine et proxy, ouvrez l’adresse formée par le sous-domaine et le domaine configurés. Créez ensuite le premier compte propriétaire depuis l’interface.
La disponibilité du conteneur ne valide pas encore le workflow. Faites une recette avec une donnée de test, vérifiez la donnée reçue par le noeud suivant, puis contrôlez la trace d’exécution. Un webhook accessible qui écrit une information incorrecte reste une panne métier.
Lire les journaux lors d’une erreur de démarrage
Utilisez :
docker compose logs --tail allLes journaux montrent la sortie des services. Commencez par vérifier les variables d’environnement, le montage du volume et l’état du conteneur signalé par docker compose ps. Si le workflow appelle une API, contrôlez aussi l’authentification, la portée du jeton et l’adresse configurée chez ce fournisseur.
Pour arrêter les services sans supprimer le volume persistant :
sudo docker compose stopOrganiser la recette avant de confier un workflow aux équipes
Écrivez les entrées attendues, le résultat attendu, les erreurs probables et la personne qui les reçoit. Un workflow unique suffit pour un enchaînement court et cohérent. Découpez-le quand plusieurs déclencheurs, responsabilités ou reprises sur erreur se croisent. Ce découpage donne un journal plus lisible et évite qu’une erreur secondaire bloque tout le traitement.
Prévoyez une alerte sur les exécutions en erreur. Lorsqu’un appel externe échoue, le workflow doit soit reprendre selon une règle définie, soit enregistrer un identifiant de corrélation et confier l’action à une personne. La supervision transforme une erreur technique en action suivie.
Exposer n8n docker compose derrière un proxy inverse
Avant de publier n8n docker compose, créez le sous-domaine, pointez-le vers le serveur et installez un proxy inverse avec un certificat HTTPS valide. Le proxy reçoit le trafic public ; n8n reste lié à l’interface locale dans l’exemple officiel. Cette architecture évite d’exposer directement le port interne du service.
Publier HTTPS sans exposer directement le port interne de n8n
Le guide Docker Compose officiel publie les entrées web du proxy et associe n8n à 127.0.0.1:5678. Gardez les ports d’administration hors de l’accès public et limitez l’accès au serveur aux personnes chargées de son exploitation.
Configurer l’URL publique des webhooks
Définissez l’hôte, le protocole et l’URL publique des webhooks. Derrière un proxy inverse unique, n8n demande N8N_PROXY_HOPS=1 et N8N_WEBHOOK_URL. Le dernier proxy doit transmettre X-Forwarded-For, X-Forwarded-Host et X-Forwarded-Proto.
Cette cohérence évite que n8n fabrique des URL internes, des liens de webhook inutilisables ou des comportements de cookies incohérents. À partir de n8n 2.30.0, utilisez N8N_WEBHOOK_URL. Les versions antérieures attendent WEBHOOK_URL.
Protéger les jetons, les secrets et les ports
Conservez les secrets hors du fichier Compose partagé et restreignez les accès réseau aux seuls flux nécessaires. Ne confondez pas une authentification réussie avec une exploitation sécurisée : le jeton doit aussi porter une portée adaptée, pouvoir être remplacé et ne jamais apparaître dans un journal ou un export.
Consignez le comportement attendu lors d’une erreur de webhook. L’alerte doit désigner un responsable, et le journal doit permettre de retrouver l’exécution concernée.
Sauvegarder, superviser et mettre à jour l’instance
Une sauvegarde restaurable contient le dossier .n8n, la configuration de déploiement et, si vous utilisez PostgreSQL, la sauvegarde de cette base réalisée avec ses propres outils. Ajoutez les stockages externes et les répertoires d’extensions réellement configurés.
Pour SQLite, arrêtez n8n avant de copier les données afin d’éviter une sauvegarde incohérente. Pour restaurer, arrêtez n8n, remettez le dossier .n8n, restaurez PostgreSQL si nécessaire, remettez la configuration de déploiement, puis redémarrez l’instance.
Ce qu’une sauvegarde restaurable doit inclure
La clé de chiffrement figure parmi les éléments critiques. Restaurer des workflows sans cette clé peut laisser les identifiants chiffrés inexploitables. Testez la restauration dans un environnement de préproduction lorsque l’enjeu le justifie.
Restaurer après un incident sans perdre la clé de chiffrement
Une alerte ne suffit pas. Le responsable doit pouvoir retrouver l’exécution, identifier le noeud en erreur, restaurer les données si l’incident les a touchées, puis relancer ou corriger le traitement selon la procédure prévue. Gardez cette procédure avec la configuration, plutôt que dans la mémoire d’une seule personne.
Préparer une montée de version avec le canal stable
n8n présente le canal stable pour la production et avertit que beta peut être instable. Sauvegardez l’instance complète, relisez les changements de version, puis réalisez une recette.
La procédure Docker Compose documentée suit cet ordre :
docker compose pull
docker compose down
docker compose up -dContrôlez ensuite l’état des conteneurs et les journaux. En cas d’échec, la sauvegarde complète et la version d’image précédemment retenue constituent le point de retour à tester, jamais une improvisation pendant une indisponibilité. La procédure de sauvegarde et de restauration décrite par la documentation n8n doit rester accessible à l’équipe d’exploitation.
Ce qu’il faut retenir
Après cette lecture, prenez un processus réel et rédigez son cadrage sur une page : déclencheur, données entrantes, résultat attendu, erreurs probables, responsable de supervision et méthode de reprise. Décidez ensuite si votre équipe peut administrer l’instance auto-hébergée. Construisez le fichier Compose dans un environnement de préproduction, réalisez une recette complète, puis testez une restauration avant la mise en production. Le guide Docker Compose de n8n sert de référence pour l’infrastructure.
FAQ
Quel volume Docker faut-il conserver pour n8n ?
Conservez n8n_data, monté sur /home/node/.n8n. Il contient notamment la base SQLite par défaut et la clé de chiffrement.
Comment vérifier que les conteneurs n8n fonctionnent ?
Exécutez docker compose ps. La commande affiche les conteneurs du projet, leur état et les ports exposés. Utilisez --all pour inclure les conteneurs arrêtés.
Comment consulter les journaux d’une installation Docker Compose ?
Exécutez docker compose logs --tail all depuis le répertoire du fichier Compose. Recherchez ensuite le service concerné, puis vérifiez ses variables, son volume et sa connectivité.
Que faut-il sauvegarder avant une montée de version n8n ?
Sauvegardez le dossier .n8n, la configuration de déploiement, PostgreSQL lorsqu’il est utilisé, ainsi que les stockages externes et extensions configurés. Arrêtez n8n avant de copier SQLite.
Pourquoi configurer une URL publique de webhook derrière un proxy inverse ?
n8n doit connaître l’adresse que les services externes atteignent. Configurez l’URL publique et les en-têtes transférés par le proxy afin que les webhooks et les redirections utilisent la bonne adresse.