Installer n8n, c'est une commande. Faire vivre une installation n8n, c'est un rôle — et c'est la différence que la plupart des tutoriels passent sous silence. Dans ce guide, je reprends les trois méthodes officielles telles que la documentation n8n les présente à la date de cet article (relevé du 17 septembre 2026), avec les commandes exactes — puis la question que personne ne pose avant d'avoir le problème : qui administre ensuite.
Les trois méthodes officielles, en résumé
La documentation n8n présente trois chemins, et chacun répond à un usage différent :
| Méthode | Pour quoi | Ce qu'il faut savoir |
|---|---|---|
| npx (sans installation) | Essayer sur sa machine, évaluer l'interface | Rien ne persiste — pour tester, pas pour produire |
| Docker | Auto-héberger durablement | Un volume pour les données, le port 5678, et un serveur à administrer |
| n8n Cloud | Ne rien installer ni administrer | Abonnement — « Deploy on your infrastructure or ours » |
Il existait une quatrième voie — l'installation globale par npm — mais la doc officielle est sans ambiguïté : « npm-based installs are deprecated from n8n 3.0 ». Si un tutoriel vous fait faire un `npm install n8n -g` aujourd'hui, il date. C'est le premier piège de « installer n8n » sur un moteur de recherche : les résultats mélangent des méthodes dont certaines ne sont plus recommandées.
Audit de faisabilité gratuit, réponse sous 48-72 h ouvrées.
Méthode 1 — Essayer sans installer : npx
La doc officielle le dit en une ligne : « You can try n8n without installing it using npx ». Une commande, et l'interface tourne en local :
npx n8nPrérequis : Node.js — la documentation demande « a Node.js version between 20.19 and 24.x, inclusive ». Au-delà ou en deçà, l'installation peut échouer sans raison évidente.
C'est le bon choix pour juger l'interface et construire un premier workflow de test sur ses propres données. Ce n'est pas un environnement de production : rien ne survit proprement à une coupure de machine, personne ne surveille le processus, et il n'y a ni HTTPS ni accès distant.
Méthode 2 — Installer pour durer : Docker
C'est la méthode que la documentation traite en premier pour l'auto-hébergement, et elle tient en deux commandes officielles.
D'abord le volume nommé — c'est lui qui garde vos workflows et vos identifiants quand le conteneur est recréé :
docker volume create n8n_dataPuis le conteneur, avec ce volume monté et le port 5678 publié — celui où l'interface écoute :
docker run -it --rm --name n8n -p 5678:5678 -v n8n_data:/home/node/.n8n docker.n8n.io/n8nio/n8nSans le volume, chaque mise à jour du conteneur repart d'une installation vierge. Avec lui, vos données survivent — c'est la différence entre un jouet et un déploiement.
Ce que Docker apporte : un environnement reproductible, la même image du poste au serveur, un arrêt-relance propre. Ce qu'il n'apporte pas : l'administration — personne ne met à jour l'image pour vous, ne surveille la machine, ne gère le certificat HTTPS si l'interface est exposée. C'est votre serveur.
Méthode 3 — Ne rien installer : n8n Cloud
La troisième voie tient en une phrase du site officiel : « Deploy on your infrastructure or ours ». Chez eux, l'installation disparaît et l'administration aussi : l'interface est disponible, les workflows tournent, et le sujet « qui maintient » est réglé par l'abonnement.
C'est la voie la plus rapide vers un n8n utilisé, et celle qui échange une compétence interne contre un coût récurrent. Les deux modèles se défendent — ce qui ne se défend pas, c'est de choisir sans poser la question.
La question que les tutoriels oublient : qui administre ?
Installer n8n prend une commande. Le faire vivre prend un rôle, et ce rôle a des tâches précises :
- Les mises à jour de sécurité — une instance n8n exposée et jamais mise à jour est une porte d'entrée ;
- Les sauvegardes du volume — la panne la plus douloureuse est celle où on découvre leur absence ;
- La surveillance — un workflow qui échoue en silence pendant trois semaines, c'est une automatisation qui n'existe pas ;
- L'exposition propre — HTTPS, accès, authentification, si l'interface sort de votre réseau.
Un n8n installé puis abandonné est, de ce que j'en vois, le cas le plus courant après un premier essai enthousiaste. Ce n'est pas une raison de ne pas auto-héberger — c'est une raison de décider avant l'installation qui fera vivre l'instance : quelqu'un en interne, un contrat de maintenance, ou l'éditeur via le Cloud.
Comment choisir entre npx, Docker et Cloud
Trois questions tranchent, et elles n'ont rien de technique :
- Où doivent vivre vos données ? Si vos workflows manipulent des données clients sensibles et que votre métier exige de les garder chez vous, l'auto-hébergement pèse plus fort.
- Qui peut administrer un conteneur chez vous ? Si la réponse est « personne », l'auto-hébergé devient un engagement à prendre — ou un faux choix.
- Comment le coût doit-il arriver ? Un abonnement prévisible (Cloud) ou du temps de maintenance (auto-hébergé) — les deux se chiffrent, différemment.
La mauvaise réponse n'est aucune des trois options : c'est l'entre-deux, un auto-hébergé que personne ne maintient.
Un outil à brancher ? Décrivez-le, réponse sous 48-72 h ouvrées.
Et si l'installation est déjà là mais plus maintenue ?
C'est le cas le plus fréquent que je rencontre : une instance qui tourne, plus personne pour la mettre à jour, et des sauvegardes découvertes absentes le jour de la panne. On peut reprendre une installation existante — état des lieux, mise à niveau, mise en place des garde-fous — en intervention ponctuelle, sans abonnement obligatoire.
Si vous hésitez entre auto-hébergé et Cloud, ou si votre n8n a besoin d'être remis d'aplomb, décrivez votre situation dans l'audit de faisabilité — gratuit, réponse sous 48-72 h ouvrées, verdict écrit avec la raison. Et pour la vue d'ensemble de l'outil (licence, pièges, comparaison avec les autres plateformes), c'est sur la page n8n du site.
Sources et vérifications
Informations vérifiées à partir des ressources suivantes, consultées lors de la rédaction.