💬 Votre avis sur une modification proposée : l'obligation d'utiliser Docker pour exécuter n8n

Annonces
1

Jusqu’à présent, il y a toujours eu deux principaux moyens de déployer n8n : via npm et via Docker. Nous envisageons d’abandonner le support natif npm et aimerions avoir vos commentaires à ce sujet.

Nous aimerions que vous puissiez remplir ce sondage après lecture.

Pourquoi nous envisageons cela

Nous travaillons dur sur un assistant IA beaucoup plus puissant - pensez à Claude Code, mais intégré dans n8n. C’est depuis longtemps en tête de la liste des souhaits de la communauté, et il est important que nous le mettions en auto-hébergement. Nous visons une version auto-hébergée cet été.

Pour des raisons de sécurité, cet assistant a besoin d’un bac à sable. Ce bac à sable doit être déployé dans un conteneur Docker distinct. Cela signifie que n8n aura une dépendance à Docker. Pour cette raison, il est logique de se standardiser sur un déploiement basé sur Docker - d’autant plus que c’est de toute façon une méthode de déploiement plus fiable.

Ce que cela signifierait pour les installations basées sur npm

Si vous vouliez faire une mise à jour, vous devriez vous assurer que Docker est installé et déployer en utilisant cela à la place. Vous pourriez toujours conserver votre installation dans le même répertoire et monter ce répertoire dans Docker. Nous vous fournirons des conseils sur la façon de procéder.

Si je ne veux pas de l’assistant, pourquoi ne pourrais-je pas continuer à exécuter le reste de n8n via npm ?

Bien que cela soit techniquement possible, plus un produit a de variantes et de configurations différentes, plus on introduit de complexité et de bogues.

Il y a d’autres avantages à passer à Docker uniquement ; l’assistant est juste le plus immédiat. Le faire :

  • AccĂ©lèrerait le dĂ©veloppement de n8n
  • Rendrait n8n plus facile Ă  supporter
  • Ouvrirait la porte au regroupement d’autres produits avec n8n Ă  l’avenir si nĂ©cessaire, par exemple une base de donnĂ©es vectorielle ou Redis.

Ce que nous aimerions savoir

Nous sommes conscients qu’il peut y avoir des situations où l’utilisation de Docker est difficile. n8n est utilisé de toutes sortes de façons et nous n’en sommes probablement pas au courant de certaines. Nous aimerions donc avoir vos commentaires sur ce sujet, que vous utilisiez actuellement npm ou Docker — veuillez remplir le sondage ci-dessous ! :folded_hands:

:backhand_index_pointing_right: Lien vers le sondage

11 « J'aime »
3

Je soutiens cela. Cela fait longtemps que je n’ai pas utilisé une installation npm de n8n, sauf lors du développement de nœuds.
Utiliser npm pour les installations de n8n entraînera toujours des problèmes à un moment ou à un autre. Docker est également plus sécurisé.
Quand les clients nous demandent de gérer leur instance, nous les poussons toujours vers Docker s’ils utilisent npm. Cela rend tout plus facile à gérer. :slight_smile:

12 « J'aime »
4

Je suis d’accord avec Bram, Docker est beaucoup plus facile à configurer et c’est plus rapide, et il a des conteneurs donc ça peut aider à garder les choses sécurisées.

5 « J'aime »
5

Je soutiens cette direction. Je gère moi-même n8n dans Docker et j’ai brièvement expérimenté avec npm auparavant. La différence en termes de stabilité et de maintenabilité est flagrante.
Ce qui m’a convaincu dans cette décision : l’assistant IA intégré a besoin d’une sandbox, et une sandbox nécessite Docker. Ce n’est pas une dépendance arbitraire mais une justification technique. Ceux qui utilisent n8n sérieusement ont généralement Docker en fonctionnement de toute façon.
Le seul point qui me préoccupe : il existe des utilisateurs qui exécutent n8n dans des environnements très légers, par exemple de petits VPS avec peu de RAM, où Docker consomme sensiblement plus de ressources qu’une installation npm brute. Pour eux, une aide à la migration claire et idéalement une image Docker optimisée seraient importantes.
Globalement : moins de variantes signifie moins de bugs et un développement plus rapide. C’est bénéfique pour toute la communauté.

3 « J'aime »
6

Bon, c’est le moment d’entrer dans le terrier Docker CLI et les tutoriels Desktop.
Si un magicien peut partager un fichier Docker complet avec file d’attente, workers, task runners, postgresql, redis… nous pourrions définitivement empêcher les amateurs de npm de le refaire à l’avenir :slight_smile:

P.S certains aiment npm… certains aiment docker… mais ce qui est plus important, c’est que TOUT LE MONDE adore N8N!!!

1 « J'aime »
7

Je suis d’accord : Docker me semble être la solution la plus propre et la plus facile à maintenir ici, surtout pour le bac à sable de l’assistant IA et la stabilité à long terme.

1 « J'aime »
8

La mise à niveau à partir de npm a été un cauchemar. Il y avait beaucoup de problèmes de dépendances.
Docker est plus facile bien qu’il entraîne quelques surcharges. La gestion est la clé.

+1 pour Docker

1 « J'aime »
9

Favorable à cette direction. Suite à l’exécution de n8n sur des instances VPS pour plusieurs environnements clients, Docker s’est avéré nettement plus prévisible que npm selon les versions de n8n — surtout quand le sandbox IA a commencé à exiger une isolation de processus distincte.

La seule demande concrète que j’ajouterais : un fichier Compose minimaliste sur un seul conteneur optimisé pour petit VPS (1-2 vCPU, 1-2 GB RAM) avec une documentation claire sur les services qu’on peut désactiver pour réduire la surcharge. Beaucoup d’utilisateurs auto-hébergés exécutent n8n sur des VPS bon marché où le daemon Docker lui-même ajoute de la pression mémoire, donc des conseils sur la configuration Docker minimale viable réduiraient les frictions pour ces migrations.

4 « J'aime »
10

Je lance Docker sur un VPS Ubuntu via MobaXterm. Cette méthode est un peu technique, mais quiconque l’a utilisée auparavant la préférera probablement à long terme.
Docker Compose + Cloudflare Tunnel est une configuration essentielle pour les utilisateurs - assez facile à sauvegarder, maintenir et même migrer les données.
La nécessité d’un environnement de sandbox pour l’assistant IA est simplement un avantage supplémentaire.

Cependant, la configuration Docker Compose actuelle a-t-elle besoin de modifications au lancement de l’assistant ? Ou s’agit-il simplement d’un conteneur supplémentaire qui se connecte au système et s’exécute sur celui-ci ?

11

Ce devrait être juste un conteneur supplémentaire, oui :+1:

2 « J'aime »
12

Merci pour cette transparence. Je suis d’accord qu’il y a des avantages à passer à Docker, mais aussi quelques défis techniques, notamment l’accès aux fichiers locaux et la possibilité d’effectuer des opérations en ligne de commande comme créer des dossiers et des fichiers. Cela fonctionne avec plusieurs ajustements aujourd’hui et cela deviendra encore plus complexe avec l’ajout de Docker.

Un autre point qui pourrait compliquer les choses est la licence Docker elle-mĂŞme et ce que cela signifie pour certains utilisateurs.

13

Très bonne idée, en plus de cela, le nom du piratage par npm a augmenté, ce qui peut nuire à vos données en travaillant sur n8n. Et pour installer n8n sur docker, il faut avoir des connaissances techniques, mais on peut apprendre, j’ai moi-même eu des problèmes lors de l’installation de n8n sur docker desktop, mais je les ai résolus étape par étape en cherchant sur YouTube et en posant des questions à l’IA chinoise Deepseek.

14

supporté, questionnaire complété

2 « J'aime »
15

Heureusement, Coolify rend Docker plus convivial. L’accès aux fichiers reste quelque chose de difficile à gérer.

1 « J'aime »
16

Exécuter n8n auto-hébergé pour une plateforme SaaS avec plusieurs locataires - support complet de Docker-first. Tout ce qui concerne la configuration multi-worker et queue-mode fonctionne de manière plus fiable lorsque la version de n8n et l’environnement d’exécution sont cohérents sur l’ensemble des conteneurs main, workers et webhooks. Les installations basées sur npm dérivent au niveau du système d’exploitation hôte et causent des différences subtiles entre les environnements qui sont difficiles à déboguer. L’exigence d’isolation de l’assistant IA est simplement le point final naturel d’une direction qui était déjà le bon choix pour les déploiements en production.

17

C’est une nouvelle décevante - je ne suis pas (encore :wink: un expert, mais j’ai essayé d’utiliser Docker et cela a bloqué ma machine (Windows 16 Go de RAM avec n8n installé localement). Quand j’ai désinstallé Docker et que je suis revenu à NPM, j’ai pu enfin faire un vrai travail sur n8n au lieu de passer du temps à résoudre des problèmes de ressources. Bien sûr, je pourrais mettre à niveau ma machine, mais certains de mes clients ont des configurations plus basiques et je dois parfois travailler avec ce qu’ils ont.
De mon point de vue (bien que limité), utiliser Docker semble ajouter une couche de complexité et une surcharge inutiles pour les situations simples. Si Docker doit absolument être utilisé pour des raisons techniques, est-ce qu’il faut vraiment qu’il soit aussi gourmand ?

2 « J'aime »
18

À mon avis, même les non-administrateurs peuvent installer Docker, et grâce à des outils comme Portainer, c’est aussi facile à gérer. Cela facilite les choses pour les débutants (comme moi) qui ne veulent pas de solution cloud pour commencer.

Avoir plusieurs options laisse souvent beaucoup de gens face à un dilemme au moment de prendre une décision. Parfois, c’est bien de se laisser décider pour soi (je fais référence ici aux utilisateurs qui veulent simplement essayer une installation).

Je suis enthousiaste à l’idée d’un assistant IA, et je suis sûr qu’il aidera n8n à faire de grands progrès.

Sondage terminé ? Fait :wink:

2 « J'aime »
19

Je suis d’accord avec l’orientation Docker uniquement pour la plupart des utilisateurs, et une image par défaut légère, renforcée et sans droits root a du sens. Mais elle a deux propriétés qui la rendent difficile à exécuter correctement sur les hôtes NAS/auto-hébergés (Unraid, Synology, …), et passer à Docker uniquement transforme ces problèmes de « il suffit d’utiliser npm » en blocages insurmontables :

  1. Pas de mappage UID/GID hôte. L’image s’exécute en tant qu’utilisateur node fixe (uid 1000), donc les partages montés en bind se retrouvent avec des UID/GID incorrects sur l’hôte. Le correctif établi (images LinuxServer.io et similaires) consiste à démarrer en tant que root, effectuer la configuration de première exécution, puis passer à un utilisateur remappé à partir des variables PUID/PGID fournies par l’hôte - de sorte que le conteneur ne corrompe jamais les permissions des partages.

  2. Pas de gestionnaire de paquets (apk est supprimé). Certaines intégrations NAS ont besoin de droits root + d’un gestionnaire de paquets au premier démarrage - par exemple, l’intégration Tailscale d’Unraid utilise un hook qui installe et configure Tailscale au démarrage du conteneur, ce qui devient impossible une fois que apk/apt est supprimé.

Il est important de noter que (1) ne peut pas simplement être un drapeau d’environnement sur l’image actuelle : le remappage d’UID (chown des données montées, usermod, passage via su-exec/gosu) nécessite fondamentalement que le conteneur démarre en tant que root. C’est un changement délibéré de posture par rapport à la valeur par défaut non-root renforcée - ce qui est exactement pourquoi je pense que cela devrait se trouver dans une image séparée plutôt que d’affaiblir la valeur par défaut.

Donc : l’équipe envisagerait-elle une variante auto-hébergée/NAS officiellement maintenue - par exemple n8nio/n8n:<version>-nas - qui démarre en tant que root, remapperait les variables PUID/PGID de l’hôte, abandonnerait les droits privilégiés, et conserverait un gestionnaire de paquets disponible pour les hooks de première exécution ? La valeur par défaut renforcée reste exactement la même pour tous les autres.

1 « J'aime »
20

Non merci. J’ai migré de Docker vers du bare metal. Trop de commandes « Docker dit » superflues juste pour implémenter ce dont j’ai besoin. « Mais Docker est tellement plus sécurisé ! » comme si les pirates ne connaissaient pas les commandes Docker et comment les contourner… non merci…