Changements majeurs de n8n v2.0 | Documentation n8n

n8n v2.0 sera bientôt publié. Cette documentation met en avant les changements majeurs importants, ainsi que les mesures de préparation à prendre pour réussir la transition. Ces mises à jour renforcent la sécurité, simplifient la configuration et suppriment des fonctionnalités héritées.

La sortie de n8n 2.0 s’inscrit dans la continuité de l’engagement de n8n à fournir une plateforme d’automatisation sécurisée, fiable et prête pour la production. Cette version majeure inclut d’importants renforcements de sécurité ainsi qu’un nettoyage des fonctionnalités obsolètes.

Changements de comportement

Retour des données attendues lorsqu’un sous-workflow reprend après une mise en attente

Auparavant, lorsqu’une exécution parente appelait un sous-workflow dont un nœud faisait passer l’exécution enfant en attente, et que l’exécution parente était configurée pour attendre la fin de l’exécution enfant, l’exécution parente recevait un résultat incorrect.

Par exemple, un sous-workflow entrait dans un état d’attente lorsqu’il contenait un nœud Wait avec un délai supérieur à 65 secondes, un appel Webhook, une soumission de formulaire ou un nœud de validation manuelle (comme un nœud Slack).

Workflow parent :

Sous-workflow :

v1 : l’exécution parente renvoyait en sortie l’entrée du sous-workflow :

v2 : l’exécution parente reçoit le résultat du sous-workflow :

Cela permet d’utiliser des nœuds de validation manuelle dans un sous-workflow et d’exploiter leur résultat dans le workflow parent (par exemple, approuver ou rejeter une action).

Chemin de migration : passez en revue tous les workflows qui appellent des sous-workflows et s’attendent à recevoir l’entrée du sous-workflow, puis mettez-les à jour pour tenir compte du nouveau comportement — le workflow parent recevra désormais la sortie finale du sous-workflow, et non plus son entrée.

Suppression du nœud Start

Le nœud Start n’est plus pris en charge. Ce nœud était la méthode d’origine pour démarrer un workflow, désormais remplacée par des nœuds de déclenchement plus adaptés.

Chemin de migration : remplacez le nœud Start selon l’usage de votre workflow :

• Exécution manuelle : remplacez le nœud Start par un nœud Manual Trigger.
• Sous-workflow : si un autre workflow appelle ce workflow comme sous-workflow, remplacez le nœud Start par un nœud Execute Workflow Trigger et activez le workflow.
• Nœud Start désactivé : si le nœud Start est déjà désactivé, supprimez-le du workflow.

Enregistrer et publier les workflows

Le nouveau système de publication des workflows remplace l’ancien interrupteur d’activation/désactivation. L’ancien bouton « activer/désactiver » devient le nouveau bouton « publier/dépublier ». Ce changement vous permet de mieux contrôler quand les modifications d’un workflow sont publiées et réduit le risque de publier accidentellement en production des changements en cours. Pour plus d’informations, consultez la page Enregistrer et publier des workflows.

Suppression des nœuds liés à des services arrêtés

Les nœuds suivants ont été supprimés, car les services externes auxquels ils étaient connectés ne sont plus disponibles :

• nœud Spontit
• nœud crowd.dev
• nœud Kitemaker
• nœud Automizy

Chemin de migration : si vos workflows utilisent l’un de ces nœuds, mettez-les à jour ou supprimez-les afin d’éviter les erreurs.

Sécurité

Blocage par défaut de l’accès aux variables d’environnement depuis le nœud Code

Pour renforcer la sécurité, n8n bloquera par défaut l’accès aux variables d’environnement depuis le nœud Code. La valeur par défaut de N8N_BLOCK_ENV_ACCESS_IN_NODE sera désormais true.

Chemin de migration : si vos workflows doivent accéder aux variables d’environnement dans un nœud Code, définissez N8N_BLOCK_ENV_ACCESS_IN_NODE=false dans votre configuration d’environnement. Pour les données sensibles, il est recommandé d’utiliser des informations d’identification ou d’autres méthodes sécurisées plutôt que des variables d’environnement.

Application obligatoire de permissions strictes sur les fichiers

n8n exigera des permissions de fichier strictes pour les fichiers de configuration afin d’améliorer la sécurité. Par défaut, les fichiers de configuration devront utiliser les permissions 0600, ce qui signifie que seul le propriétaire du fichier pourra les lire et les modifier. Cette approche est similaire à la manière dont SSH protège les clés privées.

Chemin de migration : pour tester ce comportement avant la v2.0, définissez N8N_ENFORCE_SETTINGS_FILE_PERMISSIONS=true. Si votre environnement ne prend pas en charge les permissions de fichiers (par exemple sous Windows), définissez N8N_ENFORCE_SETTINGS_FILE_PERMISSIONS=false pour désactiver cette exigence.

Activation par défaut des exécuteurs de tâches

n8n activera par défaut les exécuteurs de tâches afin d’améliorer la sécurité et l’isolation. Tous les nœuds Code s’exécuteront via les exécuteurs de tâches.

Chemin de migration : avant la mise à niveau vers la v2.0, définissez N8N_RUNNERS_ENABLED=true pour tester ce comportement. Assurez-vous que votre infrastructure répond aux exigences nécessaires à l’exécution des exécuteurs de tâches. Pour une sécurité supplémentaire, vous pouvez envisager le mode externe.

Suppression des exécuteurs de tâches de l’image Docker n8nio/n8n

À partir de la v2.0, l’image Docker principale n8nio/n8n n’inclura plus les exécuteurs de tâches nécessaires au mode externe. Vous devrez utiliser l’image Docker distincte n8nio/runners pour exécuter les exécuteurs de tâches en mode externe.

Chemin de migration : si vous exécutez des exécuteurs de tâches en mode externe avec Docker, mettez à jour votre configuration pour utiliser l’image n8nio/runners à la place de n8nio/n8n.

Suppression du nœud Code Python et des outils basés sur Pyodide

n8n supprimera le nœud Code Python et les outils basés sur Pyodide, et les remplacera par une implémentation basée sur les exécuteurs de tâches utilisant Python natif, plus sûre et plus performante. À partir de la v2.0, vous ne pourrez utiliser le nœud Code Python qu’avec des exécuteurs de tâches en mode externe et des outils Python natifs.

Le nœud Code Python natif ne prend pas en charge les variables intégrées fournies par la version Pyodide (comme _input) ni la notation par point. Pour plus de détails, consultez la documentation du nœud Code.

Les outils Python natifs prennent en charge _query, c’est-à-dire la chaîne d’entrée transmise lorsqu’un agent d’IA appelle l’outil.

Chemin de migration : pour continuer à utiliser Python dans le nœud Code, configurez les exécuteurs de tâches en mode externe et vérifiez la compatibilité de vos nœuds Code Python et outils existants.

Désactivation par défaut des nœuds ExecuteCommand et LocalFileTrigger

n8n désactivera par défaut les nœuds ExecuteCommand et LocalFileTrigger, car ils présentent des risques de sécurité. Ces nœuds permettent aux utilisateurs d’exécuter des commandes arbitraires et d’accéder au système de fichiers.

Chemin de migration : si vous devez utiliser ces nœuds, retirez ces nœuds de la liste d’exclusion définie par la variable d’environnement NODES_EXCLUDE. Par exemple, définissez NODES_EXCLUDE="[]" pour activer tous les nœuds, ou retirez uniquement les nœuds spécifiques dont vous avez besoin.

Authentification requise par défaut pour les URL de callback OAuth

n8n exigera par défaut une authentification sur les URL de callback OAuth. La valeur par défaut de N8N_SKIP_AUTH_ON_OAUTH_CALLBACK passera de true (pas d’authentification requise) à false (authentification requise).

Chemin de migration : avant de passer à la v2.0, définissez N8N_SKIP_AUTH_ON_OAUTH_CALLBACK=false et testez vos intégrations OAuth afin de vérifier qu’elles fonctionnent correctement avec l’authentification activée.

Définition d’une valeur par défaut pour N8N_RESTRICT_FILE_ACCESS_TO

n8n définira une valeur par défaut pour N8N_RESTRICT_FILE_ACCESS_TO afin de contrôler les emplacements autorisés pour les opérations sur les fichiers. Cela affecte les nœuds ReadWriteFile et ReadBinaryFiles. Par défaut, ces nœuds ne pourront accéder qu’aux fichiers du répertoire ~/.n8n-files.

Chemin de migration : examinez les workflows qui utilisent des nœuds de fichiers et assurez-vous qu’ils n’accèdent qu’à des fichiers situés dans les répertoires autorisés. Si vous devez permettre l’accès à d’autres répertoires, définissez la variable d’environnement N8N_RESTRICT_FILE_ACCESS_TO avec le chemin souhaité.

Changement de la valeur par défaut de N8N_GIT_NODE_DISABLE_BARE_REPOS à true

Pour des raisons de sécurité, le nœud Git bloquera désormais par défaut les dépôts bare. La valeur par défaut de N8N_GIT_NODE_DISABLE_BARE_REPOS est définie sur true, ce qui signifie que les dépôts bare seront désactivés sauf si vous modifiez ce paramètre.

Chemin de migration : si vos workflows doivent utiliser des dépôts bare, définissez N8N_GIT_NODE_DISABLE_BARE_REPOS=false dans votre configuration d’environnement pour les activer.

Données

Fin de la prise en charge de MySQL/MariaDB

n8n ne prendra plus en charge MySQL et MariaDB comme moteur de stockage ; cette prise en charge était déjà dépréciée depuis la v1.0. Pour une compatibilité optimale et un support à long terme, utilisez PostgreSQL. Le nœud MySQL continuera d’être pris en charge comme auparavant.

Chemin de migration : avant de passer à la v2.0, utilisez un outil de migration de base de données pour transférer vos données de MySQL ou MariaDB vers PostgreSQL ou SQLite.

Suppression de l’ancien pilote SQLite

En raison de problèmes de fiabilité, n8n supprimera l’ancien pilote SQLite. Le pilote avec pool de connexions deviendra l’unique pilote SQLite. Ce pilote utilise le mode WAL, une seule connexion d’écriture et un pool de connexions de lecture. Nos tests de performance montrent qu’il peut être jusqu’à 10 fois plus rapide.

Chemin de migration : le pilote sqlite-pooled deviendra automatiquement le pilote par défaut. Vous pouvez activer immédiatement le pool de connexions en définissant DB_SQLITE_POOL_SIZE sur une valeur supérieure à 0. La taille par défaut du pool sera définie à 2.

Suppression du mode de données binaires en mémoire

n8n supprimera le mode default de N8N_DEFAULT_BINARY_DATA_MODE, qui conserve en mémoire les données binaires des exécutions pendant l’exécution. À partir de la v2, les options suivantes seront disponibles pour de meilleures performances et une meilleure stabilité :

• filesystem : les données binaires sont stockées dans le système de fichiers (option par défaut en mode standard).
• database : les données binaires sont stockées dans la base de données (option par défaut en mode file d’attente).
• s3 : les données binaires sont stockées dans un stockage compatible S3.

Le paramètre N8N_AVAILABLE_BINARY_DATA_MODES sera également supprimé ; le mode sera désormais déterminé uniquement par N8N_DEFAULT_BINARY_DATA_MODE.

Chemin de migration : le mode système de fichiers ou base de données sera utilisé automatiquement selon votre configuration. Assurez-vous que votre instance n8n dispose de suffisamment d’espace disque pour stocker les données binaires. Pour plus de détails, consultez la configuration des données binaires.

Configuration et environnement

Mise à niveau de dotenv

n8n utilise la bibliothèque dotenv pour charger la configuration d’environnement depuis le fichier .env. Cette bibliothèque passera de la version 8.6.0 à la dernière version, ce qui peut modifier la manière dont les fichiers .env sont interprétés. Les principaux changements majeurs incluent :

• prise en charge des backticks (#615) : si vos valeurs contiennent des backticks, entourez-les de guillemets simples ou doubles.
• prise en charge multiligne : les valeurs sur plusieurs lignes sont désormais possibles.
• # marque le début d’un commentaire : toute ligne commençant par # sera considérée comme un commentaire.

Chemin de migration : consultez le journal des modifications de dotenv et mettez à jour votre fichier .env pour garantir la compatibilité avec la nouvelle version.

Suppression de l’option n8n --tunnel

L’option de ligne de commande n8n --tunnel sera supprimée dans la v2.0.

Chemin de migration : si vous utilisez actuellement l’option --tunnel pour le développement ou les tests, basculez vers une autre solution de tunnel, comme ngrok, localtunnel ou Cloudflare Tunnel. Mettez à jour vos workflows et votre documentation pour refléter ce changement.

Suppression de QUEUE_WORKER_MAX_STALLED_COUNT

La variable d’environnement QUEUE_WORKER_MAX_STALLED_COUNT ainsi que le mécanisme de nouvelle tentative des tâches bloquées de Bull seront supprimés, car ils provoquent souvent de la confusion et fonctionnent de manière peu fiable.

Chemin de migration : supprimez cette variable d’environnement de votre configuration. Après la mise à niveau, n8n ne relancera plus automatiquement les tâches bloquées. Si vous devez gérer ce type de tâche, envisagez de mettre en place votre propre logique de nouvelle tentative ou une surveillance dédiée.

Suppression de N8N_CONFIG_FILES

La variable d’environnement N8N_CONFIG_FILES a été supprimée.

Chemin de migration : supprimez cette variable d’environnement de votre configuration. Migrez votre configuration vers des variables d’environnement, un fichier .env ou une configuration basée sur _FILE.

CLI et workflows

Remplacement de la commande CLI update:workflow

La commande CLI update:workflow sera dépréciée et remplacée par deux nouvelles commandes offrant des fonctionnalités similaires avec une sémantique plus claire :

• publish:workflow, avec les paramètres id et versionId (optionnel)
• le paramètre --all sera supprimé afin d’éviter la publication accidentelle de workflows en production
• unpublish:workflow, avec les paramètres id et all

Chemin de migration : utilisez la nouvelle commande publish:workflow pour publier des workflows individuellement par ID, avec la possibilité de préciser une version. Pour dépublier, utilisez la nouvelle commande unpublish:workflow. Cela offre davantage de clarté et de contrôle sur l’état de publication des workflows.

Hooks externes

Dépréciation des hooks frontend de workflow

Les fonctions hook workflow.activeChange et workflow.activeChangeCurrent seront dépréciées et remplacées par le nouveau hook workflow.published. Ce nouveau hook sera déclenché lorsqu’une version quelconque d’un workflow sera publiée.

Chemin de migration : mettez à jour votre code pour utiliser le nouveau hook workflow.published à la place de workflow.activeChange et workflow.activeChangeCurrent. Ce hook fournit un comportement plus cohérent et se déclenche lors de la publication d’une version de workflow.

Canaux de publication

n8n a renommé ses canaux de publication : latest devient stable et next devient beta.

Le tag stable désigne la dernière version stable, tandis que beta désigne la dernière version expérimentale. Ces tags sont disponibles à la fois sur npm et sur Docker Hub. Pour le moment, n8n continuera également à publier les versions avec les tags latest et next. Ces tags seront supprimés dans une future version majeure.

Recommandation : épinglez la version de n8n à un numéro de version précis, par exemple 2.0.0.

En cas de problème

Si vous rencontrez des problèmes lors de la mise à jour vers n8n 2.0, rendez-vous sur le forum de la communauté pour obtenir de l’aide et du support.