Installer n8n en local : le guide complet (Docker et npm)

Bonne nouvelle : pour découvrir n8n, vous n’avez besoin ni de serveur, ni d’abonnement, ni de carte bancaire. En une dizaine de minutes, vous pouvez faire tourner n8n gratuitement sur votre propre ordinateur — Windows, Mac ou Linux — et commencer à construire vos premiers workflows.

Dans ce tutoriel complet, nous voyons les deux méthodes d’installation (Node.js et Docker), comment lancer n8n, créer votre compte local, conserver vos données et mettre à jour l’outil. Avec, en bonus, les solutions aux erreurs les plus fréquentes.

Vous hésitez encore entre cloud et self-host ? Lisez d’abord notre guide n8n Cloud vs self-host.

Avant de commencer : ce qu’il vous faut

• Un ordinateur récent (Windows 10/11, macOS ou Linux) avec environ 1 Go d’espace libre.
• Des droits d’administrateur pour installer un logiciel.
• 10 à 15 minutes devant vous.

Deux chemins s’offrent à vous. Choisissez selon votre profil :

Méthode 1 — Lancer n8n avec Node.js (le plus rapide)

Étape 1 : installer Node.js

Node.js est l’environnement qui fait tourner n8n. Téléchargez la version LTS (Long Term Support) sur le site officiel nodejs.org, puis installez-la en laissant les options par défaut. Pour vérifier l’installation, ouvrez un terminal (Invite de commandes sur Windows, Terminal sur Mac) et tapez :

node --version

Si une version s’affiche (par exemple v20.x.x), c’est gagné.

Étape 2 : lancer n8n

Toujours dans le terminal, une seule commande suffit :

npx n8n

La première fois, le téléchargement prend deux ou trois minutes. Quand vous voyez le message « Editor is now accessible via: http://localhost:5678 », ouvrez votre navigateur à l’adresse :

http://localhost:5678

Et voilà : n8n tourne sur votre machine. 🎉

Méthode 2 — Installer n8n avec Docker (recommandée)

Docker fait tourner n8n dans un conteneur isolé : rien ne s’éparpille dans votre système, les mises à jour sont triviales et vous reproduisez à l’identique ce que vous ferez plus tard sur un serveur. C’est la méthode que nous recommandons dès que vous dépassez le simple essai. Si vous voulez comprendre le fichier de configuration plutôt que le recopier, nous l’avons décortiqué dans n8n avec Docker, le fichier compose expliqué.

Étape 1 : installer Docker Desktop

Téléchargez Docker Desktop depuis le site officiel docker.com et installez-le (sur Windows, il peut vous demander d’activer WSL 2 : acceptez, l’assistant s’occupe de tout). Lancez ensuite Docker Desktop et attendez que son icône indique qu’il est démarré.

Étape 2 : créer un volume pour vos données

Un volume est un espace de stockage persistant : vos workflows et identifiants y survivront aux redémarrages. Dans le terminal :

docker volume create n8n_data

Étape 3 : lancer n8n

docker run -it --rm --name n8n -p 5678:5678 -v n8n_data:/home/node/.n8n docker.n8n.io/n8nio/n8n

Décodons cette commande : -p 5678:5678 ouvre la porte d’accès locale, -v n8n_data:… branche votre volume de données, et l’image officielle n8nio/n8n est téléchargée automatiquement. Ouvrez ensuite http://localhost:5678 dans votre navigateur, comme pour la méthode 1.

Premier démarrage : créer votre compte local

À la première ouverture, n8n vous demande de créer un compte propriétaire (e-mail + mot de passe). Ce compte est purement local — il ne crée rien sur les serveurs de n8n — et protège l’accès à votre instance. Renseignez-le, répondez (ou non) au mini-questionnaire, et vous arrivez sur l’écran d’accueil, prêt à créer votre premier workflow.

Arrêter, relancer et mettre à jour n8n

Arrêter

Dans le terminal où n8n tourne : Ctrl + C. Avec Docker en arrière-plan : docker stop n8n.

Relancer

Méthode Node.js : retapez npx n8n. Méthode Docker : relancez la commande docker run (vos données sont dans le volume, vous retrouvez tout).

Mettre à jour

# Méthode Node.js
npm update -g n8n

# Méthode Docker : récupérer la dernière image
docker pull docker.n8n.io/n8nio/n8n

Les problèmes fréquents (et leurs solutions)

• « node n’est pas reconnu… » → Node.js n’est pas installé ou le terminal n’a pas été rouvert après l’installation. Fermez et rouvrez le terminal.
• « port 5678 already in use » → une autre instance de n8n tourne déjà. Fermez-la, ou changez de porte : -p 5679:5678 (puis ouvrez localhost:5679).
• Docker affiche « Cannot connect to the Docker daemon » → Docker Desktop n’est pas démarré. Lancez-le et attendez l’icône verte.
• Page blanche dans le navigateur → attendez quelques secondes que le démarrage se termine, puis rechargez avec Ctrl + F5.
• J’ai perdu mes workflows après redémarrage (Docker) → le conteneur a été lancé sans le volume -v n8n_data:/home/node/.n8n. Relancez toujours avec cette option.

Docker ou Node : ce qui change vraiment à l’usage

Les deux méthodes vous donnent la même application dans le même navigateur. La différence n’apparaît qu’au bout de quelques semaines, et elle porte sur trois points concrets.

La propreté de votre machine

Avec Node, l’application et ses dépendances s’installent parmi vos autres logiciels. Si vous avez déjà un projet qui exige une version différente de Node, les conflits sont possibles — et ils se manifestent par des messages incompréhensibles. Avec Docker, tout vit dans un conteneur isolé : rien ne touche au reste de votre système, et la désinstallation consiste à supprimer le conteneur.

La reproductibilité

C’est l’argument décisif. Une installation Docker se décrit dans un fichier de quelques lignes. Le jour où vous changez d’ordinateur ou passez sur un serveur, vous reprenez le même fichier et vous obtenez exactement la même chose. Une installation Node dépend de l’état de votre machine : elle n’est pas reproductible à l’identique.

La facilité de mise à jour

Docker : on récupère la nouvelle image, on relance, c’est terminé. Node : on met à jour le paquet, en espérant qu’aucune dépendance ne pose problème. Sur trois mises à jour, la différence est mince ; sur deux ans, elle est nette.

Notre position : pour un essai d’une soirée, Node est plus rapide et suffit parfaitement. Dès que vous pensez garder l’outil, Docker est le bon investissement — et le quart d’heure supplémentaire se rembourse à la première mise à jour.

Où vivent vos données : le point que tout le monde découvre trop tard

Question à se poser avant de construire quoi que ce soit : si votre machine tombe demain, que perdez-vous ?

Une installation locale range trois choses ensemble : vos automatisations, vos identifiants enregistrés vers vos services, et l’historique des exécutions. Le tout dans une base de fichiers unique, stockée dans un dossier de configuration — sur votre disque avec Node, dans un volume Docker avec Docker.

Le fichier qui compte

C’est une base légère, tenue dans un seul fichier. Le sauvegarder revient à sauvegarder l’ensemble de votre travail. Le perdre revient à tout perdre, y compris les identifiants — et donc à devoir reconnecter chaque service un par un.

La clé de chiffrement : à mettre à l’abri dès aujourd’hui

Vos identifiants ne sont pas stockés en clair : ils sont chiffrés avec une clé générée au premier démarrage. Cette clé vit à côté de la base, dans le dossier de configuration.

Conséquence directe, et c’est le piège le plus coûteux de l’installation locale : une sauvegarde de la base sans la clé est une sauvegarde inutilisable pour les identifiants. Vous restaurerez vos automatisations, mais aucune connexion ne fonctionnera, et le message d’erreur ne dira pas pourquoi.

Deux façons de s’en prémunir. Soit vous sauvegardez le dossier de configuration entier, clé comprise. Soit — et c’est la bonne pratique — vous définissez vous-même la clé de chiffrement au lancement, via une variable d’environnement, et vous la conservez dans votre gestionnaire de mots de passe. La seconde méthode a un avantage décisif : le jour où vous passerez sur un serveur, vos identifiants exportés resteront lisibles.

Sauvegarder et restaurer : la routine en cinq minutes

Une installation locale n’a aucune sauvegarde automatique. C’est à vous de la mettre en place, et cela prend cinq minutes une fois pour toutes.

Ce qu’il faut sauvegarder

Trois éléments, et rien d’autre : la base de données, la clé de chiffrement, et — si vous en avez défini — vos variables d’environnement. Sur une installation Docker, tout cela se trouve dans le volume que vous avez créé au démarrage.

La méthode simple

Copiez le dossier de configuration vers un espace de stockage synchronisé, une fois par semaine. C’est rudimentaire et cela suffit largement pour un usage personnel. Le seul point de vigilance : arrêtez l’application avant la copie, sinon vous risquez de copier une base en cours d’écriture.

La méthode par export

Complémentaire, et nous la recommandons en plus. L’interface permet d’exporter chaque automatisation dans un fichier. Rangez ces fichiers dans un dossier daté, ou mieux, dans un dépôt de versions. Vous obtenez un historique lisible de vos automatisations, indépendant de la base, et transférable vers n’importe quelle autre installation.

Tester la restauration

La partie que personne ne fait, et qui distingue une sauvegarde d’une intention. Une fois par trimestre, restaurez votre sauvegarde ailleurs — sur un second conteneur, dans un dossier temporaire — et vérifiez que les automatisations s’ouvrent et que les identifiants répondent. Un quart d’heure, une fois tous les trois mois : c’est le prix de la certitude.

Les réglages à poser dès le premier lancement

Cinq variables changent réellement le confort d’usage. Elles se passent au lancement, dans la ligne de commande ou dans le fichier de composition.

Le fuseau horaire. Sans réglage, l’application raisonne en temps universel : une automatisation planifiée à 8 h se déclenchera à 9 h ou 10 h selon la saison. C’est le premier réglage à poser, et celui qui provoque le plus de confusion quand on l’oublie.

La clé de chiffrement. Comme expliqué plus haut : définissez-la vous-même et conservez-la ailleurs. Cinq secondes aujourd’hui, une catastrophe évitée plus tard.

Le port d’écoute. Le port par défaut est parfois déjà occupé par un autre outil. Le changer évite un message d’erreur au démarrage dont la cause n’est pas évidente.

L’authentification. Même en local, protégez l’accès si votre machine est partagée. Une instance ouverte donne accès à tous vos identifiants enregistrés.

La durée de conservation de l’historique. Par défaut, tout est conservé. Sur une machine personnelle, la base grossit lentement mais sûrement ; limiter la conservation à quelques semaines suffit dans la pratique et garde l’ensemble léger.

Prenez l’habitude de tout écrire dans un fichier de composition plutôt que dans une longue ligne de commande. Vous relirez ce fichier dans six mois, et vous serez content qu’il existe.

Recevoir des appels extérieurs sur une installation locale

C’est la limite structurelle du local, et il vaut mieux la comprendre avant de construire une automatisation qui en dépend.

Une automatisation déclenchée par un service extérieur suppose que ce service puisse joindre votre instance. Or votre machine n’a pas d’adresse publique : elle est derrière votre box, invisible depuis internet. Les automatisations qui vont chercher l’information fonctionnent parfaitement ; celles qui attendent qu’on les appelle ne fonctionnent pas.

La solution de test

L’application propose un mode tunnel qui crée temporairement une adresse publique redirigée vers votre machine. C’est pratique pour tester, et c’est explicitement réservé au test : l’adresse change, la stabilité n’est pas garantie, et rien de sérieux ne doit en dépendre.

Les alternatives

Un service de tunnel dédié offre une adresse stable, souvent moyennant un petit abonnement. C’est une bonne solution intermédiaire pour un usage régulier depuis chez soi. La solution durable, elle, reste le serveur : adresse fixe, disponibilité permanente, certificat valide.

Le contournement le plus simple

Souvent oublié : remplacez l’attente par une vérification. Au lieu d’attendre qu’un service vous prévienne, allez lui demander toutes les heures s’il y a du nouveau. C’est moins élégant, cela consomme un peu plus, mais cela fonctionne sans aucune exposition de votre machine. Pour un usage personnel, c’est très souvent la bonne réponse.

Faire tourner l’application en permanence

Une installation lancée depuis un terminal s’arrête quand vous fermez la fenêtre. Vos automatisations planifiées ne tournent donc que lorsque vous y pensez — ce qui annule une bonne partie de l’intérêt.

Avec Docker, une option de redémarrage automatique règle le problème : le conteneur se relance au démarrage de la machine, et après un plantage. C’est le réglage à poser dès la première commande.

Avec Node, il faut passer par un gestionnaire de processus, ou déclarer un service dans le système. C’est faisable, c’est un peu plus manuel, et c’est un argument de plus en faveur de Docker.

Reste la limite qu’aucun réglage ne franchit : votre machine doit être allumée. Un ordinateur portable fermé la nuit n’exécutera rien. Si vos automatisations doivent tourner à heures fixes, l’installation locale montre ici sa frontière — et c’est en général le moment où l’on envisage un petit serveur.

Les huit messages d’erreur les plus fréquents

Classés par ordre d’apparition, avec la cause réelle derrière le message.

« Le port est déjà utilisé. » Un autre programme occupe le port, ou une instance précédente tourne encore. Changez de port, ou arrêtez l’instance qui traîne.

« Commande introuvable. » Node ou Docker n’est pas installé, ou le terminal a été ouvert avant l’installation. Fermez-le et rouvrez-en un nouveau : neuf fois sur dix, cela suffit.

Une erreur de permissions au démarrage. Le dossier de données appartient à un autre utilisateur. C’est fréquent sur les systèmes de type Unix après avoir lancé une première fois en administrateur : corrigez le propriétaire du dossier plutôt que de relancer en administrateur.

« Les identifiants ne peuvent pas être déchiffrés. » La clé de chiffrement a changé. Vous avez restauré une base sans sa clé, ou modifié la variable. Remettez la clé d’origine ; sans elle, les identifiants sont définitivement illisibles.

Une automatisation planifiée se déclenche à la mauvaise heure. Le fuseau horaire n’est pas réglé. Posez-le et redémarrez.

Un appel extérieur n’arrive jamais. Comportement normal en local : votre machine n’est pas joignable. Utilisez un tunnel pour tester, ou remplacez l’attente par une vérification.

L’interface ne s’ouvre pas dans le navigateur. Vérifiez le port dans l’adresse, et regardez la sortie du terminal : le message d’erreur réel y est presque toujours, quelques lignes plus haut que là où vous regardez.

L’application est lente ou se ferme seule. Manque de mémoire, en général sur une machine modeste ou avec une limite Docker trop basse. Augmentez la mémoire allouée, et réduisez la conservation de l’historique.

Ce que cela consomme réellement

Question légitime avant d’installer quoi que ce soit sur sa machine de travail.

Au repos, l’application occupe quelques centaines de mégaoctets de mémoire et une part négligeable du processeur : elle attend. Pendant l’exécution d’une automatisation, la consommation monte le temps du traitement, puis redescend. Sur une machine moderne, vous ne le remarquerez pas.

Les deux cas où cela devient sensible : le traitement de gros fichiers, qui charge les données en mémoire, et un très grand nombre d’automatisations simultanées, ce qui ne se rencontre pas sur un poste personnel.

Côté disque, comptez quelques centaines de mégaoctets pour l’application, puis une croissance lente de la base au fil des exécutions. C’est l’historique qui grossit ; en limiter la conservation garde l’ensemble stable pendant des années.

En résumé : une installation locale se fait oublier sur une machine correcte. Si la vôtre est ancienne ou déjà chargée, préférez Docker avec une limite de mémoire explicite : vous garderez la main sur ce que l’application peut prendre.

Emporter son installation vers un serveur

Beaucoup commencent en local puis basculent. Voici ce qui se transfère, et ce qui ne se transfère pas.

Les automatisations. Elles s’exportent une par une, ou toutes ensemble, dans des fichiers réimportables tels quels. Aucune reconstruction : c’est la même application des deux côtés.

Les identifiants. Ils s’exportent aussi, mais ils restent chiffrés avec votre clé. Si vous avez défini la clé vous-même et que vous la reportez sur le serveur, ils fonctionneront directement. Si vous avez laissé la clé générée automatiquement et que vous ne l’avez pas conservée, il faudra tout reconnecter à la main.

Les adresses de réception. Elles changent forcément. Faites la liste des services extérieurs qui appellent votre instance avant de basculer, et mettez-les à jour un par un après.

L’historique. Il ne se transfère pas simplement, et ce n’est en général pas gênant. Si vous y tenez, copiez la base entière plutôt que d’exporter les automatisations une par une.

La bonne méthode reste la même que pour tout déménagement : montez la nouvelle instance à côté, importez, testez sur une destination de test, puis basculez. Gardez le local en veille une semaine — un retour arrière gratuit vaut mieux qu’une nuit blanche.

Le montage côté serveur — Docker Compose, nom de domaine, certificat et sauvegardes — est détaillé pas à pas dans notre guide installer n8n sur un VPS avec Docker. C’est le prolongement direct de cette page : ici on installe pour essayer, là-bas pour tenir 24 h/24.

Votre première heure après l’installation

L’application tourne, l’interface s’ouvre, et beaucoup de gens s’arrêtent là — puis n’y reviennent pas. Voici comment employer utilement les soixante minutes qui suivent, pour transformer une installation en outil de travail.

Minutes 1 à 10 : poser les réglages

Fuseau horaire, clé de chiffrement conservée dans votre gestionnaire de mots de passe, durée de conservation de l’historique. Trois réglages, une seule fois. Les faire maintenant vous évitera de les découvrir dans trois semaines, en cherchant pourquoi une automatisation se déclenche avec une heure de décalage.

Minutes 10 à 25 : une automatisation sans enjeu

Pas votre besoin réel : quelque chose de volontairement inutile. Une planification qui vous envoie un message chaque heure, par exemple. L’objectif est de voir la mécanique complète fonctionner — déclenchement, exécution, historique — sans que le résultat ait la moindre importance. C’est ce qui vous donnera la confiance nécessaire pour la suite.

Minutes 25 à 45 : une vraie connexion

Connectez un service que vous utilisez tous les jours et lisez-en quelque chose : les fichiers d’un dossier, les lignes d’un tableur, les derniers messages d’une boîte. Uniquement de la lecture : rien qui écrive, rien qui envoie. Vous découvrez ainsi la structure réelle de vos données, ce qui est la moitié du travail de toute automatisation.

Minutes 45 à 60 : la sauvegarde

La partie la moins gratifiante, et celle qui protège tout le reste. Copiez le dossier de données vers un espace synchronisé, notez la procédure en trois lignes, et posez un rappel hebdomadaire dans votre agenda. Quinze minutes aujourd’hui contre un travail entier perdu un jour de panne : le calcul n’est pas discutable.

Ce qu’il ne faut pas faire pendant cette heure

Ne construisez pas votre automatisation la plus importante. Ne connectez pas encore ce qui touche à vos factures ou à vos clients. Ne cherchez pas non plus à tout comprendre : la moitié des menus ne vous servira jamais, et vouloir en faire le tour est le meilleur moyen de refermer la fenêtre découragé.

Une installation réussie n’est pas une installation dont vous maîtrisez tous les réglages : c’est une installation qui tourne, qui est sauvegardée, et sur laquelle vous avez déjà fait fonctionner quelque chose. Le reste s’apprend en construisant, pas en explorant.

FAQ — vos questions fréquentes

Mon n8n local est-il accessible depuis Internet ?

Non, et c’est volontaire : localhost n’est visible que depuis votre ordinateur. C’est idéal pour apprendre. Pour des webhooks publics (recevoir des événements de services externes), il faudra plus tard héberger n8n sur un VPS avec un nom de domaine — c’est l’objet de notre module Expert.

Mes workflows sont-ils sauvegardés automatiquement ?

Oui : n8n stocke tout dans son dossier de données (le volume n8n_data avec Docker, le dossier ~/.n8n avec Node.js). Pensez quand même à exporter régulièrement vos workflows importants (menu du workflow → Download) : un fichier JSON = une sauvegarde portable.

Puis-je connecter Gmail, Notion ou Slack depuis une installation locale ?

Oui pour la plupart des services : les connexions sortantes fonctionnent normalement. Seule limite : les déclencheurs par webhook entrant (recevoir des notifications en temps réel), qui nécessitent une instance accessible en ligne. En local, utilisez plutôt des déclencheurs planifiés (Schedule).

Quelle est la différence entre npx n8n et npm install -g n8n ?

npx télécharge et exécute n8n à la demande (idéal pour un essai ponctuel) ; npm install -g l’installe durablement sur votre machine, ce qui accélère les lancements suivants. Pour un usage régulier, préférez l’installation globale… ou mieux : Docker.

Puis-je installer sur une clé USB ou un disque externe ?

Techniquement oui, en pointant le dossier de données vers le disque externe. En pratique, c’est déconseillé : une base de données supporte mal les déconnexions à chaud, et un débranchement pendant une écriture peut la corrompre. Si votre objectif est la portabilité, exportez plutôt vos automatisations dans des fichiers : ils se transportent sans risque.

Deux personnes peuvent-elles utiliser la même installation locale ?

Sur le même réseau, oui : il suffit d’ouvrir l’accès depuis l’adresse locale de la machine. Mais une installation locale n’est pas conçue pour le travail à plusieurs : pas de gestion des droits, et un risque réel d’écrasement si deux personnes modifient la même automatisation. Dès que vous êtes deux à y toucher, l’instance mérite de vivre sur un serveur.

Que se passe-t-il si je mets à jour et que la nouvelle version pose problème ?

Avec Docker, vous relancez l’image précédente en indiquant son numéro de version : le retour arrière prend deux minutes, à condition d’avoir noté quelle version fonctionnait. Avec Node, réinstallez la version antérieure du paquet. Dans les deux cas, sauvegardez avant de mettre à jour : c’est ce qui transforme un incident en simple contretemps.

Une installation locale peut-elle appeler des services payants ou des API privées ?

Oui, sans aucune restriction : votre machine sort sur internet normalement. La seule limite est l’entrée — recevoir des appels — pas la sortie. Vous pouvez donc interroger n’importe quelle interface de programmation, envoyer des e-mails, écrire dans vos outils en ligne. C’est ce qui rend l’installation locale parfaitement viable pour apprendre et pour la majorité des automatisations personnelles.

Puis-je passer d’une méthode d’installation à l’autre ?

Oui, et sans rien reconstruire : vos automatisations s’exportent dans des fichiers réimportables. Le seul point de vigilance est la clé de chiffrement — reportez-la sur la nouvelle installation et vos identifiants continueront de fonctionner ; oubliez-la et il faudra tout reconnecter à la main. Montez la nouvelle installation à côté de l’ancienne, testez, puis supprimez seulement quand tout tourne depuis quelques jours.

En résumé

Installer n8n en local, c’est : Node.js + npx n8n pour l’essai express, ou Docker + un volume pour une installation propre et durable. Dans les deux cas : gratuit, illimité, et vos données restent chez vous.

Votre instance tourne ? Parfait. Place au concret : créons ensemble votre premier workflow n8n, pas à pas.