Installer n8n sur son propre ordinateur, plutôt que de dépendre d’un service hébergé, change la façon de travailler l’automatisation. Sur un PC Windows ou un Mac, n8n local devient un banc d’essai pour tester des scénarios réels, manipuler des API métier et construire des workflows sans risquer les données de production.
Docker apporte par-dessus une couche de sécurité et de confort : un conteneur propre, que l’on démarre, supprime ou met à jour en quelques commandes, sans polluer le système.
Ce guide se concentre sur trois terrains concrets : l’installation n8n sur Windows avec Docker Desktop, la même chose sur Mac, puis la configuration n8n avec Docker Compose pour disposer d’une base solide, reproductible et partageable dans une équipe.
L’objectif n’est pas de montrer toutes les options possibles, mais de proposer un chemin praticable, assez proche des besoins d’une PME, d’un service IT ou d’un indépendant qui veut vérifier, en conditions réelles, si un workflow d’automatisation tient la route. En filigrane, une idée simple : mieux vaut un n8n local bien câblé qu’une pile d’outils SaaS éparpillés.
En bref
- Installer n8n en local sur Windows ou Mac avec Docker Desktop permet de prototyper des scénarios d’automatisation sérieux sans toucher à la production.
- L’utilisation de Docker et de Docker Compose simplifie la maintenance : un seul fichier de configuration, des mises à jour en deux commandes, un environnement isolé.
- Un workflow n8n bien pensé peut déjà remplacer plusieurs scripts maison éparpillés entre un NAS, un serveur mail et un Google Sheet.
- La même configuration peut être remontée presque à l’identique sur un serveur Linux ou un VPS plus tard, pour passer de n8n local à un service partagé.
- La question clé n’est pas « est-ce que ça marche », mais « est-ce que cette configuration n8n tient un lundi matin quand tout le monde en dépend ».
Installer n8n local sur Windows avec Docker Desktop pour un mini-serveur d’automatisation
Sur Windows 10 ou 11, transformer un PC de bureau en atelier d’automatisation n8n local passe très bien par Docker Desktop. L’idée consiste à encapsuler l’application dans un conteneur Linux, tout en gardant les données dans un volume persistant.
L’utilisateur peut alors tester des intégrations avec un PMS hôtelier, un CRM ou un simple compte Gmail, sans se battre avec les dépendances Node.js ou les mises à jour du système.
Un exemple typique, rencontré chez un responsable marketing d’une PME industrielle : sa machine sous Windows servait à la fois à produire des contenus, suivre les leads et bricoler des macros Excel. Passer à n8n local lui a permis de déclencher automatiquement un workflow dès qu’un formulaire du site web était soumis, alimenter un Google Sheet et pousser l’information dans un CRM. Rien de tout cela ne nécessitait un serveur dédié ; un PC déjà allumé toute la journée suffisait, du moment que la base était stable.
Avant de lancer Docker Desktop, quelques prérequis techniques évitent des heures de diagnostic. Le système doit tourner en 64 bits, avec la virtualisation activée dans le BIOS (Intel VT-x ou AMD-V), et WSL2 installé pour de meilleures performances des conteneurs Linux. Une connexion Internet solide est évidemment nécessaire pour télécharger l’image n8n, surtout dans un atelier où les connexions partagées saturent vite.
Une fois Docker Desktop installé, un premier réflexe consiste à ouvrir un PowerShell et à vérifier la commande docker –version. Ce contrôle très basique évite de dériver ensuite vers des problèmes de réseau imaginaires, alors que le moteur Docker n’a tout simplement pas démarré. Beaucoup de tickets internes partent de là : une installation à moitié finie, un redémarrage oublié, et tout le reste semble « bizarre ».
La préparation du dossier de travail est volontairement simple. Un répertoire C:n8n-docker fait l’affaire, avec à l’intérieur un fichier docker-compose.yml. Ce fichier devient la documentation vivante de l’instance n8n : image utilisée, ports exposés, paramètres d’authentification, fuseau horaire. On peut le versionner dans Git, le partager à un collègue, ou le recopier sur un serveur Linux plus tard, avec une marge d’adaptation limitée.
Dans ce fichier, un service unique suffit pour débuter :
services:
n8n:
image: docker.n8n.io/n8nio/n8n:latest
restart: unless-stopped
ports:
– « 5678:5678 »
environment:
– N8N_BASIC_AUTH_ACTIVE=true
– N8N_BASIC_AUTH_USER=admin
– N8N_BASIC_AUTH_PASSWORD=motdepasseFort123
– N8N_HOST=localhost
– N8N_PORT=5678
– N8N_PROTOCOL=http
– TZ=Europe/Paris
volumes:
– n8n_data:/home/node/.n8n
volumes:
n8n_data:
Cette configuration n’a rien d’exotique, et c’est justement ce qui la rend fiable. L’authentification basique coupe l’accès aux curieux sur un réseau partagé, le volume nommé n8n_data garde les workflows après un redémarrage, et le port 5678 devient le point d’entrée évident dans le navigateur. Tant que ce fichier est propre, on sait exactement ce qui tourne.
Le lancement se fait avec un simple docker compose up -d dans le dossier dédié. Le moteur télécharge l’image, crée le conteneur n8n et le démarre en arrière-plan. Un coup d’œil à docker ps confirme si tout est en place, avec la ligne qui expose 0.0.0.0:5678->5678/tcp. Il reste alors à saisir http://localhost:5678 dans le navigateur, se connecter avec le couple admin / mot de passe robuste, puis commencer à câbler les premiers workflows.
Côté exploitation, trois commandes suffisent pour le quotidien : docker compose down pour arrêter le service, docker compose up -d pour le démarrer, et la séquence docker compose pull puis docker compose up -d pour mettre à jour. Les workflows restent en place grâce au volume. Autrement dit, même si tout est cassé fonctionnellement après un test un peu violent, la remise en état passe rarement par plus de deux ou trois lignes dans le terminal.
Pour ceux qui veulent aller encore plus loin côté environnement, il peut être pertinent de regarder comment installer Docker sur un Debian ou un serveur distant, histoire de garder la même logique d’infrastructure une fois que la phase de prototypage est validée. Sur Windows, l’essentiel tient en une idée simple : un PC du bureau qui tourne déjà peut devenir une rampe de lancement fiable pour n8n local, à condition de traiter Docker comme un composant d’infrastructure et pas comme un gadget.
Installer n8n en local sur Mac avec Docker Desktop et un workflow reproductible
Sur Mac, l’installation n8n suit les mêmes principes que sur Windows, mais avec des outils légèrement différents. Docker Desktop pour macOS encapsule lui aussi n8n dans un conteneur, en s’appuyant sur une couche de virtualisation adaptée aux processeurs Intel ou Apple Silicon. C’est souvent dans les studios de design, les agences ou les équipes produit que cette approche fait mouche : un Mac déjà chargé d’outils graphiques devient aussi un orchestrateur discret d’automatisations.
Un produit manager travaillant sur Mac peut, par exemple, brancher n8n local sur un backlog Jira, un espace Notion et des webhooks internes. Chaque fois qu’une tâche critique est déplacée en « prêt à déployer », un workflow envoie un résumé dans un canal Slack, archive la spécification dans un drive partagé et crée une entrée de suivi dans un tableur. Pas besoin d’ouvrir un compte supplémentaire quelque part : tout tourne sur sa machine, tant qu’elle reste allumée.
Les prérequis sur macOS sont assez clairs : une version récente (Ventura, Sonoma ou équivalent), un compte administrateur et au moins 8 Go de RAM pour absorber Docker Desktop et n8n sans faire souffrir les autres applications. Sur les MacBook d’entrée de gamme, ce point est souvent sous-estimé. Lorsque les conteneurs tournent avec en parallèle plusieurs navigateurs, IDE et outils de visioconférence, la mémoire devient vite un goulot d’étranglement.
L’installation de Docker Desktop passe par le téléchargement du fichier .dmg sur le site officiel, puis par le glisser-déposer de l’icône Docker dans le dossier Applications. Une fois l’app lancée, l’icône en forme de baleine apparaît dans la barre de menus, signe que le moteur est actif. Là encore, un rapide docker –version depuis le Terminal permet de vérifier que l’environnement répond correctement.
La préparation du projet n8n reprend la même logique que sur Windows, mais cette fois dans le répertoire utilisateur. La séquence mkdir -p ~/n8n-docker puis cd ~/n8n-docker crée un espace dédié, à l’abri du ménage manuel que certains font dans les dossiers téléchargements. Un fichier docker-compose.yml y décrit à nouveau le service n8n, avec une configuration très proche :
services:
n8n:
image: docker.n8n.io/n8nio/n8n:latest
restart: unless-stopped
ports:
– « 5678:5678 »
environment:
– N8N_BASIC_AUTH_ACTIVE=true
– N8N_BASIC_AUTH_USER=admin
– N8N_BASIC_AUTH_PASSWORD=motdepasseFort123
– N8N_HOST=localhost
– N8N_PORT=5678
– N8N_PROTOCOL=http
– TZ=Europe/Paris
volumes:
– n8n_data:/home/node/.n8n
volumes:
n8n_data:
Dans les faits, cette similarité entre Mac et Windows simplifie la vie d’une équipe hybride. Le même fichier peut être partagé sur un dépôt Git, chacun l’adapte au chemin de son dossier, mais les paramètres métiers restent identiques. On évite ce travers classique où la version Mac et la version Windows de la stack divergent au bout de six mois, faute de référentiel commun.
Depuis le Terminal, un simple docker compose up -d dans ce dossier déclenche le téléchargement de l’image puis la création du conteneur. La commande docker ps permet ensuite de s’assurer que le port 5678 est bien exposé. Une ouverture de http://localhost:5678 dans Safari ou Chrome donne accès à l’interface n8n, protégée par le couple utilisateur / mot de passe défini plus haut.
Le quotidien sur Mac ressemble ensuite à ce qui se fait sur Windows. On arrête l’instance avec docker compose down, on la redémarre avec docker compose up -d, on met à jour en jouant la séquence docker compose pull puis docker compose up -d. Du coup, l’effort de formation reste raisonnable : une fois ces réflexes acquis, les développeurs, data analysts ou responsables produits peuvent se concentrer sur le dessin de workflows plutôt que sur l’outillage.
Un point mérite toutefois une vigilance particulière sur Mac : la gestion de la batterie. Un MacBook qui héberge n8n local avec Docker, tout en exécutant des workflows qui tournent toutes les minutes, consomme plus qu’un simple poste bureautique. Pour les postes fixes, ce n’est pas un sujet. Pour les machines qui passent leur temps en déplacement, il peut être intéressant de s’inspirer de mesures faites dans d’autres contextes, comme celles réalisées sur la consommation d’un Raspberry Pi 5, afin de raisonner en termes de budget énergétique global quand on multiplie les services locaux.
Au final, sur Mac comme sur Windows, l’important n’est pas le logo sur la machine, mais cette capacité à démarrer un environnement n8n local reproductible en quelques minutes, capable de supporter sans broncher les prototypes d’agents IA, de connecteurs e-mail ou de synchronisations de tableurs.
Configuration n8n avec Docker Compose : SQLite, PostgreSQL et scénarios d’usage
Dès que les premiers workflows prennent forme, la question de la base de données se pose. Par défaut, l’image n8n local utilise SQLite à l’intérieur du volume, ce qui suffit pour un usage individuel ou un petit atelier. Pour des flux plus lourds, une base PostgreSQL externe devient intéressante, quitte à complexifier légèrement le fichier Docker Compose. Le choix ne doit pas se faire au feeling, mais en fonction du volume de données, du nombre d’utilisateurs et du type d’automatisation visé.
Un développeur qui teste un connecteur vers un PMS hôtelier avec un flux de quelques dizaines de réservations par jour n’a pas les mêmes besoins qu’un service IT qui veut centraliser les journaux d’alertes, les tâches d’intégration CRM et les notifications support. Le premier peut rester tranquillement sur SQLite, le second aura vite besoin de la robustesse et des capacités de requêtes d’un PostgreSQL séparé, surtout si les workflows deviennent imbriqués.
Le tableau ci-dessous donne un aperçu synthétique des différences entre ces deux approches dans le contexte d’une installation n8n :
| Configuration | Complexité d’installation | Performance attendue | Cas d’usage typiques |
|---|---|---|---|
| SQLite interne | Faible, aucun service supplémentaire | Suffisante pour un utilisateur ou de petits workflows | Prototypes, formation, mini-serveur sur poste individuel |
| PostgreSQL externe | Moyenne, nécessite un conteneur ou serveur DB dédié | Mieux adaptée aux workflows nombreux et volumineux | Instance partagée, pré-production, intégration multi-équipes |
Dans un fichier docker-compose.yml, basculer vers PostgreSQL consiste à ajouter un service supplémentaire. Par exemple, un bloc db pouvant utiliser une image stable comme postgres:13, avec des variables d’environnement pour l’utilisateur, le mot de passe et le nom de la base. N8n est alors configuré pour pointer vers cette base via ses propres variables d’environnement, ce qui le rend indépendant du stockage interne au conteneur.
Ce découplage a un intérêt immédiat pour les équipes qui raisonnent déjà en termes de sauvegardes et de supervision. Sauvegarder une base PostgreSQL se fait avec des outils connus, intégrables dans une stratégie globale, là où un volume Docker contenant une base SQLite demande plus de soin. En langage d’usine, on retrouve l’idée de séparer la logique de commande de l’organe de puissance : n8n est le cerveau, la base est le bloc d’alimentation mémoire.
Pour un bureau d’études ou une TPE, le conseil est souvent de commencer en mode minimal avec SQLite, puis de planifier un passage progressif à PostgreSQL si les workflows se multiplient et si plusieurs personnes doivent collaborer sur la même instance. Vouloir tout anticiper dès le départ conduit parfois à une couche de complexité qui décourage l’usage quotidien. À l’inverse, forcer l’usage de SQLite sur un corpus de données volumineux génère des lenteurs et des comportements peu lisibles.
Une autre dimension de la configuration n8n concerne les variables d’environnement sensibles : clés API OpenAI, identifiants Google, secrets pour les webhooks, etc. Docker Compose permet de les gérer soit directement dans le fichier (ce qui n’est pas conseillé pour de la production), soit via un fichier .env séparé ou un gestionnaire de secrets. Sur un n8n local dédié à des tests, il est fréquent de voir ces valeurs stockées localement, mais rien n’empêche de prendre dès le départ les bons réflexes, surtout si ce fichier est versionné.
Dans des contextes où l’équipe envisage plusieurs briques d’automatisation, il peut être utile de comparer n8n à d’autres solutions open source ou SaaS. Des ressources comme un panorama d’outils d’automatisation open source autour de n8n permettent de se faire une idée des forces et limites des différentes approches, en particulier pour les intégrations industrielles ou IoT.
Au bout du compte, la configuration n8n avec Docker Compose est un équilibre : partir volontairement simple, mais laisser des points de sortie maîtrisés pour monter autant en charge qu’en maturité sur la durée.
Automatisation des workflows avec n8n local : scénarios concrets Windows/Mac
Mettre en place n8n local sur Windows ou Mac n’a de sens que si cette base sert des automatisations concrètes. Les scénarios les plus parlants sont souvent les moins spectaculaires : un traitement d’e-mails entrants, une synchronisation entre un formulaire web et un tableur, une alerte Slack dès qu’une valeur dépasse un seuil dans un capteur ou un outil de suivi. C’est là que la combinaison Docker + n8n commence à rembourser son temps d’installation.
Dans une petite coopérative agricole, par exemple, un PC de bureau allumé en permanence héberge un n8n qui surveille des messages MQTT, consulte un Google Sheet qui liste les parcelles, et envoie des SMS aux techniciens quand certaines mesures dépassent un seuil. Le workflow ressemble à un schéma électrique : une entrée capteur, quelques blocs de logique, deux ou trois sorties. Le fait de l’exécuter en local garde le contrôle sur les données et évite d’exposer des API internes à une plateforme externe.
Sur Windows, un cas d’usage fréquent consiste à automatiser la vie d’un CRM ou d’un outil marketing. Un workflow peut, par exemple, surveiller une boîte mail dédiée aux demandes entrantes, parser les fichiers joints, vérifier la présence de certaines mentions dans le texte, puis remplir une ligne dans un tableur partagé ou pousser la création d’une opportunité dans un outil commercial. Chaque bloc du workflow reste lisible, ce qui permet à un non-développeur de comprendre pourquoi une tâche a été déclenchée ou non.
Sur Mac, le même genre de logique se retrouve dans des environnements plus créatifs. Un studio peut créer un workflow qui récupère les briefs reçus par e-mail, en extrait les métadonnées importantes (client, deadline, formats demandés), et alimente un outil de gestion de projet. Un second workflow s’occupe de la facturation prévisionnelle en fin de mois, en agrégeant les missions et en générant un export prêt à être injecté dans un logiciel comptable.
Dans tous les cas, l’interface graphique de n8n permet de matérialiser ces flux, avec une palette de nœuds qui couvrent déjà plus de deux cents services et protocoles : HTTP, Slack, Google Sheets, Telegram, OpenAI, mais aussi des bases SQL, des files de messages ou des webhooks personnalisés. Le gros intérêt, pour des équipes mixtes technique / métier, vient de cette visualisation commune. Un responsable métier peut suivre le cheminement des données, pendant qu’un développeur affine les expressions ou gère les éventuelles erreurs.
Un point souvent sous-estimé concerne la gestion des échecs. Dans un environnement n8n local, connecté par exemple à un ERP industriel, la moindre erreur silencieuse peut se traduire par un bon de commande non traité ou une alerte machine perdue. Il est donc pertinent d’intégrer dès le départ des nœuds de gestion d’erreur, des notifications en cas de blocage, voire des branches de reprise manuelle. C’est là qu’un workflow bien pensé, même simple, fait une différence réelle par rapport à un empilement de scripts bash ou PowerShell peu surveillés.
Pour les organisations qui envisagent des alternatives ou des compléments, il existe aussi d’autres plateformes d’automatisation, parfois plus orientées marketing, parfois plus fermées. Une analyse comme celle proposée dans un article sur les alternatives à n8n pour l’automatisation peut aider à pondérer les choix selon le niveau de contrôle souhaité, la politique de souveraineté des données et le budget.
En résumé, le nerf de la guerre n’est pas la somme de modules disponibles, mais la capacité à maintenir des workflows compréhensibles, qui résistent au temps et au turnover des équipes.
Bonnes pratiques, sécurité et organisation autour d’une installation n8n locale Docker
Une installation n8n en local avec Docker peut vite dériver en « prototype permanent » si quelques règles simples ne sont pas posées. Sur un PC Windows partagé par plusieurs utilisateurs ou sur un Macbook qui se balade entre bureau et domicile, la sécurité et l’organisation du travail comptent autant que la performance brute. La technologie ne protège pas d’un mot de passe collé sur un post-it ou d’un fichier docker-compose.yml oublié dans un dossier public.
Premier axe, les accès. L’authentification basique activée dans la configuration n8n est un minimum, même pour un usage isolé. Pour un poste accessible à d’autres personnes, il devient cohérent de placer un proxy inverse (par exemple Nginx ou Caddy) devant le conteneur n8n, avec un certificat TLS, même si l’usage reste limité au réseau local. Cela réduit la tentation de multiplier les ouvertures de ports non chiffrés dans des environnements parfois déjà complexes.
Deuxième point, la séparation des environnements. Plutôt que de mélanger dans la même instance n8n des workflows de test, des intégrations de production et des expérimentations d’agents IA, il vaut mieux structurer dès le départ plusieurs fichiers Docker Compose ou plusieurs conteneurs distincts. L’effort supplémentaire reste raisonnable, alors que le bénéfice en lisibilité et en gestion du risque est net. Personne n’a envie de voir un prototype casser un flux métier qui tourne depuis six mois.
Troisième levier, la documentation. Un simple fichier README associé au dossier n8n-docker, qui explique quels workflows tournent, quelles API sont utilisées, et où se trouvent les secrets, évite beaucoup de questions le jour où l’ordinateur change de main. Dans des équipes où les responsabilités se recoupent, ce type de documentation est presque plus utile qu’un manuel d’architecture haut niveau.
Pour faciliter la mise en place, une liste de contrôle concise aide à ne pas oublier les basiques :
- Vérifier la virtualisation activée et le bon fonctionnement de Docker Desktop (commande docker –version).
- Créer un dossier dédié (C:n8n-docker ou ~/n8n-docker) et y placer un docker-compose.yml versionné.
- Activer une authentification dès le départ avec N8N_BASIC_AUTH_ACTIVE et un mot de passe robuste.
- Utiliser un volume nommé (n8n_data) pour conserver les workflows lors des mises à jour.
- Planifier les mises à jour régulières avec docker compose pull et documenter la version utilisée.
Une réflexion complémentaire concerne la montée en puissance. Une fois qu’un poste individuel montre ses limites, plusieurs options existent : déplacer l’instance sur un serveur Linux, la fragmenter en plusieurs services spécialisés, ou basculer vers un hébergement plus formalisé. Ceux qui travaillent déjà avec des microcontrôleurs, des passerelles ou des mini-serveurs type Raspberry Pi savent à quel point un dimensionnement approximatif peut coûter du temps ; les mesures de consommation disponibles pour ces plateformes donnent des repères utiles pour éviter de surcharger une machine déjà à la peine.
Un dernier sujet touche à la culture d’équipe. Quand n8n devient un point de passage critique entre des systèmes, il est préférable que plusieurs personnes maîtrisent au moins les bases : lecture d’un workflow, déclenchement manuel d’un job, consultation des logs, relance d’un conteneur. L’installation n8n locale n’est pas un terrain pour un héros solitaire, mais un outil de travail collectif, surtout lorsque l’on commence à orchestrer des flux qui impactent directement les clients ou la production.
En filigrane, cette approche rappelle ce qui se pratique depuis longtemps dans le monde industriel : instrumenter suffisamment pour comprendre, mais sans complexifier au point de rendre le système ingérable le jour où il faut l’arrêter en urgence.
Comment mettre à jour une installation n8n locale sous Docker sans perdre les workflows ?
La mise à jour se fait en conservant le volume de données. Placez-vous dans le dossier contenant le fichier docker-compose.yml, exécutez d’abord docker compose pull pour récupérer la nouvelle image, puis docker compose up -d pour redémarrer le conteneur. Le volume (par exemple n8n_data) garde les workflows, les identifiants et la configuration n8n. Vérifiez simplement que le nom du volume n’est pas modifié entre deux versions du fichier de configuration.
Faut-il choisir SQLite ou PostgreSQL pour une installation n8n en local ?
Pour un usage individuel, de test ou de formation, SQLite suffit largement et évite de gérer un deuxième service dans Docker. Dès que plusieurs personnes utilisent la même instance, ou que les workflows manipulent des volumes de données plus importants, PostgreSQL devient plus approprié. Il offre de meilleures performances, des outils de sauvegarde plus standard et une plus grande flexibilité pour les requêtes. Beaucoup d’équipes commencent avec SQLite puis migrent ensuite vers PostgreSQL en conservant la même logique Docker Compose.
L’installation de n8n local sur Windows ou Mac est-elle adaptée à un usage en production ?
Pour un usage métier ponctuel ou limité à une petite équipe, un n8n local sur un poste fixe bien maîtrisé peut rendre service, notamment en période de prototypage. Pour une production au sens strict, avec des engagements de disponibilité, il vaut mieux basculer vers un serveur dédié ou un VPS, même si la configuration reste basée sur Docker et Docker Compose. L’avantage du modèle présenté est justement de pouvoir être transposé vers une infrastructure plus robuste sans tout réécrire.
Peut-on exposer son n8n local sur Internet pour recevoir des webhooks externes ?
C’est possible, par exemple en utilisant un tunnel comme Ngrok ou un reverse proxy sur une box ou un routeur, mais cela demande des précautions. Il faut au minimum un chiffrement TLS, une authentification robuste et une limitation de ce qui est accessible depuis l’extérieur. Pour des tests rapides, un service de tunnel peut suffire. Pour un usage régulier, mieux vaut mettre en place un n8n sur un serveur public contrôlé, plutôt que d’ouvrir la machine personnelle à tout vent.
Existe-t-il des alternatives intéressantes à n8n pour certains cas d’automatisation ?
Oui, pour des besoins très orientés marketing ou pour des équipes qui privilégient un SaaS prêt à l’emploi, d’autres plateformes peuvent être plus adaptées. Certaines se concentrent sur l’e-mailing, d’autres sur la gestion de données ou l’intégration low-code. Un tour d’horizon des alternatives permet de voir où n8n se situe, en particulier lorsqu’on a besoin d’une solution open source ou auto-hébergée, et d’ajuster le choix selon le niveau de contrôle et les contraintes de conformité.