Sommaire
En bref
- En 2026, Docker Compose constitue le point de départ actuel pour une instance neuve sur votre poste.
- npm reste utile pour comprendre un essai ponctuel, mais n8n le déprécie à partir de la version 3.0.
- Installer n8n en local valide un workflow, ses données et ses erreurs, sans valider à lui seul la future production.
- Chaque test doit laisser une trace d’exécution, prévoir une reprise sur erreur et signaler un échec identifiable.
Une équipe veut souvent automatiser un processus parce qu’une personne recopie les mêmes données plusieurs fois par semaine, consulte plusieurs outils et relance manuellement les éléments oubliés. Avant de connecter les données réelles et d’activer un déclencheur, installer n8n en local donne un environnement de test concret. Vous vérifiez ce qui entre, ce que chaque noeud transforme, ce qui sort et ce qui se passe lorsqu’un appel échoue.
L’interface qui s’ouvre ne suffit pas. Le test doit aussi éclairer une décision : le processus mérite-t-il une automatisation de processus durable, ou la variabilité des données et le faible volume rendent-ils la maintenance disproportionnée ?
Docker Compose ou npm ?
| Test ponctuel, découverte rapide | Node.js installé, aucun conteneur requis | Aucune par défaut, tout est perdu à la suppression | Manuelle, via npm | Environnement non isolé, dépendances système fragiles | npm, pour un premier contact rapide |
|---|---|---|---|---|---|
| Validation répétée de workflows | Docker et Docker Compose maîtrisés | Volume persistant défini dans le fichier compose | Image officielle à remplacer, commande simple | Nécessite d'apprendre les bases de Docker | Docker Compose, choix par défaut |
| Besoin de conserver les données | Volume Docker monté sur le conteneur | Disque local sauvegardé en dehors du conteneur | Idem, sans perte de données | Sauvegardes à planifier soi-même | Docker Compose avec volume nommé |
| Proximité avec une future instance auto-hébergée | Docker sur un serveur local ou VPS | Même mécanique de volumes qu'en production | Migration quasi identique à la production | Configuration réseau à reproduire fidèlement | Docker Compose, pour réutiliser la configuration en production |
Docker Compose reste le choix par défaut pour une validation locale reproductible avant une migration en production ; npm convient surtout à un test ponctuel sans enjeu de données.
En bref
Une installation locale convient lorsque vous devez cadrer un flux limité, travailler sur des données de recette et garder la main sur les essais. Elle ne remplace ni les sauvegardes, ni la supervision, ni le choix d’une instance auto-hébergée ou d’une version infogérée pour l’exploitation régulière.
Pour un essai, gardez le périmètre étroit :
- une donnée d’entrée identifiable ;
- une règle de transformation déterministe ;
- une sortie que vous pouvez contrôler ;
- un journal d’exécution à relire ;
- une action définie lorsque le workflow échoue.
Un processus instable, peu fréquent ou dépendant d’arbitrages humains difficiles à formaliser ne justifie pas toujours un workflow. Dans ce cas, documenter la procédure existante peut coûter moins cher à maintenir qu’une automatisation fragile.
Installer n8n en local : choisir Docker Compose ou npm
Le choix commence par les prérequis techniques. Pour Docker, votre poste doit disposer d’un démon Docker actif et du plugin Docker Compose v2. Docker Desktop couvre macOS, Windows et Linux ; sous Linux, Docker Engine et Docker Compose peuvent aussi être installés séparément. Sous Windows, la procédure actuelle de n8n s’appuie sur WSL avec l’intégration WSL2 de Docker Desktop activée.
Pour npm, vérifiez d’abord la présence de Node.js :
node --versionLa documentation n8n indique une compatibilité entre Node.js 20.19 et 24.x inclus. Cette méthode est toutefois dépréciée à partir de n8n 3.0. Elle sert à examiner rapidement l’outil, pas à poser une base durable sans assumer la maintenance de l’environnement Node.js.
Ce que valide réellement une installation sur un poste
Un serveur sur votre poste vérifie l’éditeur, la logique des noeuds, les expressions, l’authentification avec des jetons de recette et le comportement d’une exécution manuelle. Il ne prouve pas qu’un webhook recevra correctement des appels depuis l’extérieur, qu’une file d’attente absorbera une charge variable ou qu’une équipe exploitera les alertes.
Ce périmètre garde sa valeur. Il évite de construire trop tôt un déploiement Docker complet autour d’un workflow dont les règles métier restent floues.
Docker Compose pour une instance locale à conserver
n8n recommande Docker pour la plupart des besoins d’auto-hébergement. Le conteneur isole l’application de votre système, limite les incompatibilités avec les outils locaux et rend plus lisibles les variables d’environnement, les volumes et la montée de version.
Docker Compose convient lorsque le test doit durer, être repris par un technicien interne ou évoluer vers un environnement de préproduction. Vous conservez alors explicitement les données et vous recréez le conteneur sans effacer le contenu utile.
npm ou npx : un essai ponctuel avec une méthode dépréciée
Pour lancer n8n sans installation globale, utilisez :
npx n8nPour une installation globale :
npm install n8n -g
n8nVous pouvez aussi démarrer l’instance avec :
n8n startn8n écoute alors sur http://localhost:5678. Les données locales résident par défaut dans ~/.n8n. Arrêtez le processus depuis le terminal, puis relancez la même commande lorsque vous reprenez le test.
Quand renoncer au test local et préparer directement un environnement de préproduction
Préparez directement un environnement de préproduction si le workflow doit recevoir des webhooks externes, manipuler des identifiants sensibles, tourner régulièrement ou alimenter un processus opérationnel. Le cadrage doit alors fixer les accès, les responsabilités, la supervision, les sauvegardes et la reprise sur erreur.
Une instance locale reste un bon atelier de recette. Elle ne doit pas devenir par inertie un serveur de production.
Installer n8n en local avec Docker et conserver les données
Vérifier Docker, Docker Compose et le démon Docker
Avant de lancer n8n, vérifiez que Docker répond et que Compose est disponible :
docker --version
docker compose versionLe démon doit tourner. Si ces commandes échouent, corrigez d’abord l’installation Docker : n8n ne peut pas démarrer dans un conteneur tant que le moteur reste arrêté.
Lancer une instance neuve et ouvrir localhost:5678
La documentation actuelle de n8n propose une installation neuve avec Docker Compose en une ligne :
curl -fsSL https://get.n8n.io | shCette procédure vérifie Docker et Compose, crée les fichiers nécessaires puis démarre n8n. Ouvrez ensuite http://localhost:5678.
Pour comprendre explicitement la persistance, voici la commande Docker documentée :
docker volume create n8n_data
docker run -it --rm \
-p 5678:5678 \
-v n8n_data:/home/node/.n8n \
n8nio/n8nComprendre le volume n8n_data et les données conservées
Le volume monté sur /home/node/.n8n conserve les données entre les redémarrages du conteneur. Avec la base SQLite par défaut, ce dossier contient notamment la base de données et la clé de chiffrement des identifiants.
C’est un point qui engage l’exploitation. Supprimer le conteneur ne supprime pas nécessairement le volume ; supprimer le volume, en revanche, retire les données qu’il contient. Gardez ce volume dans votre stratégie de sauvegarde dès que vous utilisez des identifiants ou des workflows utiles.
Arrêter, relancer ou recréer le conteneur sans supprimer le volume
Listez les conteneurs, arrêtez celui concerné puis supprimez-le si vous devez le recréer :
docker ps -a
docker stop <container_id>
docker rm <container_id>Relancez ensuite un nouveau conteneur en montant le même volume n8n_data. Les workflows et les identifiants restent accessibles parce que le volume survit au conteneur.
Tester un workflow local avant de le confier à la production
Créer le propriétaire de l’instance sans présumer des champs affichés
Au premier accès, n8n affiche le parcours de création du compte propriétaire. Suivez les étapes proposées par l’interface et conservez les accès dans votre procédure interne. Les écrans peuvent évoluer avec les montées de version, il est donc plus fiable de valider le parcours dans votre instance que de recopier des champs supposés fixes.
Construire un workflow minimal et lancer une exécution manuelle
Créez un workflow avec une entrée maîtrisée, un noeud qui transforme une valeur selon une règle déterministe, puis une sortie vérifiable. Évitez d’introduire dès le départ une IA, une API métier ou un webhook : vous perdriez la capacité à isoler l’origine d’une erreur.
Lancez ensuite Execute Workflow. L’éditeur affiche la progression de chaque étape et vous donne accès au résultat produit par les noeuds. La documentation officielle décrit ce premier parcours de recette dans son guide de création de workflow.
Vérifier la sortie et le journal d’exécution
Contrôlez la donnée de sortie, mais aussi le chemin suivi par l’exécution. Une sortie juste obtenue par hasard, avec une donnée mal formée ou un identifiant absent, prépare une panne future.
Un workflow solide laisse un journal exploitable : quelle donnée est entrée, quel noeud a échoué, quelle réponse a renvoyé le service appelé, et quel identifiant de corrélation permet de retrouver l’événement. Cette lecture devient essentielle lorsque le flux passe du poste d’essai à une instance utilisée par plusieurs personnes.
Prévoir une reprise sur erreur et une alerte avant d’activer un déclencheur
Ajoutez une branche de reprise sur erreur adaptée au processus. Elle peut conserver l’élément en échec, empêcher une duplication ou transmettre une alerte à la personne chargée de le traiter. La supervision doit signaler un échec, pas seulement montrer une exécution réussie.
Activez le déclencheur uniquement après cette recette. Un webhook exposé ou un appel automatique lancé trop tôt peut amplifier une erreur de mapping sur plusieurs éléments.
Sauvegarde, supervision et montée de version d’une instance locale
Sauvegarder le dossier .n8n et la base avant toute mise à jour
Avant une montée de version, arrêtez n8n puis sauvegardez le dossier ~/.n8n ou, avec Docker, le volume n8n_data. Si vous utilisez une base externe, sauvegardez-la aussi. Avec SQLite, l’arrêt préalable évite de copier une base incohérente.
Les exports CLI peuvent compléter cette sauvegarde :
n8n export:workflow --backup
n8n export:credentials --backupIls n’emportent toutefois ni les réglages complets de l’instance ni la clé de chiffrement. Ils ne remplacent donc pas une copie du dossier de données. La documentation de sauvegarde n8n détaille cette distinction.
Mettre à jour une installation npm ou un conteneur Docker
Pour npm :
npm update -g n8nPour Docker, récupérez l’image puis recréez le conteneur en remontant le volume existant :
docker pull n8nio/n8n
docker ps -a
docker stop <container_id>
docker rm <container_id>Avec Compose, utilisez docker compose pull, puis docker compose down et docker compose up -d. Faites une recette après chaque montée de version : exécution manuelle, vérification des identifiants et contrôle du journal.
Surveiller les exécutions, les journaux et les échecs
Un test local exige déjà une supervision minimale. Consultez les exécutions après vos essais, relevez les erreurs répétées et vérifiez que la branche de reprise produit l’alerte prévue.
Lorsque l’automatisation devient régulière, définissez qui consulte les échecs, qui corrige une authentification expirée et qui valide une relance. Une alerte sans responsable ne traite rien.
Diagnostiquer un conteneur arrêté ou un problème de permissions sur un volume
Commencez par docker ps -a pour vérifier l’état du conteneur. S’il s’arrête immédiatement, consultez ses journaux avant de le recréer.
Sous Windows avec WSL, vous pouvez entrer dans le conteneur et contrôler l’écriture dans le répertoire monté :
docker exec -it n8n shUne erreur d’écriture oriente vers les permissions ou le montage du volume. Inspectez alors les montages avec :
docker inspect n8n --format '{{json .Mounts}}'installer n8n en local pour valider un workflow avant production
Après avoir lu cet article, choisissez un seul processus réversible et décrivez son entrée, sa sortie attendue, son responsable et son traitement d’erreur. Lancez-le localement avec des données de recette, puis conservez le journal de l’exécution. Si le workflow doit fonctionner hors de votre poste, recevez des webhooks ou devenir une habitude métier, ouvrez un cadrage d’instance auto-hébergée ou de version infogérée avant toute exposition réseau.
FAQ
Docker est-il préférable à npm pour installer n8n en local ?
Pour une installation locale à conserver, Docker constitue le choix cohérent avec la recommandation n8n pour l’auto-hébergement. Il isole l’environnement et conserve les données dans un volume. npm reste une voie de test dépréciée à partir de n8n 3.0.
Où n8n conserve-t-il les workflows et les identifiants en local ?
Avec npm, n8n utilise par défaut le dossier ~/.n8n. Avec Docker, le dossier de données se trouve dans le volume monté sur /home/node/.n8n, par exemple n8n_data. Il contient aussi la clé de chiffrement, à sauvegarder avec les données.
Comment vérifier qu’un workflow local fonctionne ?
Créez un workflow minimal, lancez une exécution manuelle avec Execute Workflow, contrôlez la sortie de chaque noeud et relisez le journal d’exécution. Testez également un échec volontaire afin de vérifier la reprise sur erreur et l’alerte prévue.
Que sauvegarder avant une montée de version de n8n ?
Sauvegardez le dossier .n8n complet et la base externe éventuelle. Arrêtez d’abord l’instance si elle utilise SQLite. Les exports de workflows et d’identifiants complètent la sauvegarde, mais ils ne contiennent pas la clé de chiffrement et ne suffisent pas à restaurer toute l’instance.