Changements majeurs dans n8n v2.0

La version 2.0 de n8n arrive bientôt. Ce document met en avant les changements majeurs importants ainsi que les mesures à prendre pour préparer votre transition. Ces mises à jour améliorent la sécurité, simplifient la configuration et suppriment des fonctionnalités obsolètes.

La publication de n8n 2.0 poursuit l’engagement de n8n à fournir une plateforme d’automatisation sécurisée, fiable et prête pour la production. Cette version majeure inclut des améliorations importantes en matière de sécurité ainsi qu’un nettoyage des fonctionnalités dépréciées.

Changements de comportement

Retour des données attendues lors de la reprise d’un sous-workflow depuis un état d’attente

Auparavant, lorsqu’une exécution parente appelait une exécution enfant contenant un nœud qui plaçait cette dernière en attente (par exemple un nœud Wait avec un délai supérieur à 65 secondes, un appel Webhook, une soumission de formulaire ou un nœud nécessitant une validation humaine comme Slack), et que l’exécution parente était configurée pour attendre la fin de l’enfant, l’exécution parente recevait un résultat incorrect.

Workflow parent :

Sous-workflow :

v1 : L’exécution parente reproduisait l’entrée de l’exécution enfant comme sortie :

v2 : L’exécution parente reçoit le résultat de l’exécution enfant :

Cela permet désormais d’utiliser des nœuds nécessitant une validation humaine dans un sous-workflow, puis d’utiliser leur résultat (par exemple une approbation ou un refus) dans le workflow parent.

Chemin de migration : Vérifiez tous les workflows qui appellent un sous-workflow et s’attendent à recevoir l’entrée de ce dernier. Mettez à jour ces workflows afin qu’ils s’adaptent au 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. Il s’agissait de la méthode initiale pour démarrer un workflow, désormais remplacée par des déclencheurs plus spécifiques.

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

• Exécution manuelle : Remplacez-le par un nœud Manual Trigger.
• Sous-workflow : Si un autre workflow appelle celui-ci en tant que sous-workflow, remplacez le nœud Start par un Execute Workflow Trigger et activez le workflow.
• Nœud Start désactivé : Si le nœud Start est déjà désactivé, supprimez-le simplement du workflow.

Enregistrement et publication des workflows

Le nouveau système de publication des workflows remplace l’ancien interrupteur « Activer/Désactiver ». L’ancien bouton « Activer/Désactiver » devient désormais un bouton « Publier/Annuler la publication ». Ce changement vous permet un meilleur contrôle sur le moment où vos modifications sont mises en production, réduisant ainsi le risque de déployer accidentellement des modifications en cours. Pour plus d’informations, consultez la documentation sur l’enregistrement et la publication des workflows.

Suppression des nœuds liés à des services désactivés

Les nœuds suivants ont été supprimés car les services externes auxquels ils se connectaient 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 pour éviter des erreurs.

Sécurité

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

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

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

Application stricte des permissions de fichiers

n8n exigera désormais des permissions strictes sur les fichiers de configuration pour améliorer la sécurité. Par défaut, ces fichiers doivent avoir des permissions 0600, ce qui signifie que seul le propriétaire peut les lire et les modifier — de la même manière que 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 task runners

n8n activera par défaut les task runners pour améliorer la sécurité et l’isolation. Toutes les exécutions des nœuds Code se feront désormais via un task runner.

Chemin de migration : Avant de passer à la v2.0, définissez N8N_RUNNERS_ENABLED=true pour tester ce comportement. Assurez-vous que votre infrastructure répond aux exigences pour exécuter des task runners. Pour renforcer la sécurité, envisagez d’utiliser le mode externe.

Suppression des task runners de l’image Docker n8nio/n8n

À partir de la v2.0, l’image Docker principale n8nio/n8n ne contiendra plus les task runners destinés au mode externe. Vous devrez utiliser l’image Docker séparée n8nio/runners pour exécuter les task runners en mode externe.

Chemin de migration : Si vous exécutez des task runners en mode externe via Docker, mettez à jour votre configuration pour utiliser l’image n8nio/runners au lieu de n8nio/n8n.

Suppression du nœud Python Code basé sur Pyodide

n8n supprime le nœud Python Code et les outils basés sur Pyodide, au profit d’une implémentation basée sur les task runners utilisant Python natif, offrant une meilleure sécurité et performance. À partir de la v2.0, vous ne pourrez utiliser le nœud Python Code qu’avec un task runner en mode externe et des outils Python natifs.

Le nœud Python natif ne prend pas en charge les variables intégrées disponibles dans la version Pyodide (comme _input) ni la notation par points. Consultez la documentation des nœuds Code pour plus de détails.

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

Chemin de migration : Pour continuer à utiliser Python dans les nœuds Code, configurez un task runner en mode externe et vérifiez la compatibilité de vos nœuds et outils Python existants.

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

n8n désactive par défaut les nœuds ExecuteCommand et LocalFileTrigger en raison de leurs risques de sécurité. Ces nœuds permettent d’exécuter des commandes arbitraires et d’accéder au système de fichiers.

Chemin de migration : Si vous avez besoin de ces nœuds, supprimez-les de la liste des nœuds exclus via la variable d’environnement NODES_EXCLUDE. Par exemple, définissez NODES_EXCLUDE="[]" pour activer tous les nœuds, ou retirez uniquement ceux dont vous avez besoin.

Authentification obligatoire par défaut pour les URLs de rappel OAuth

n8n exigera désormais une authentification sur les endpoints de rappel OAuth. La valeur par défaut de N8N_SKIP_AUTH_ON_OAUTH_CALLBACK passe de true (pas d’authentification requise) à false (authentification requise).

Chemin de migration : Avant la mise à niveau vers la v2.0, définissez N8N_SKIP_AUTH_ON_OAUTH_CALLBACK=false et testez vos intégrations OAuth pour vous assurer qu’elles fonctionnent correctement avec l’authentification activée.

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 où les opérations sur les fichiers peuvent être effectuées. Cela affecte les nœuds ReadWriteFile et ReadBinaryFiles. Par défaut, ces nœuds ne pourront accéder qu’aux fichiers situés dans le répertoire ~/.n8n-files.

Chemin de migration : Vérifiez les workflows utilisant des nœuds de fichiers et assurez-vous qu’ils n’accèdent qu’aux répertoires autorisés. Si vous devez autoriser d’autres chemins, définissez la variable d’environnement N8N_RESTRICT_FILE_ACCESS_TO avec les chemins souhaités.

N8N_GIT_NODE_DISABLE_BARE_REPOS passe à true par défaut

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

Chemin de migration : Si vos workflows nécessitent l’utilisation de dépôts bare, définissez N8N_GIT_NODE_DISABLE_BARE_REPOS=false dans votre configuration.

Données

Fin du support de MySQL/MariaDB

n8n ne prendra plus en charge MySQL et MariaDB comme moteurs de stockage. Ce support avait déjà été déprécié dans la v1.0. Pour une compatibilité optimale et un support à long terme, utilisez PostgreSQL. Le nœud MySQL reste quant à lui toujours pris en charge.

Chemin de migration : Avant de passer à la v2.0, migrez vos données de MySQL ou MariaDB vers PostgreSQL ou SQLite à l’aide d’outils de migration appropriés.

Suppression de l’ancien pilote SQLite

En raison de problèmes de fiabilité, n8n supprime l’ancien pilote SQLite. Le pilote avec pool de connexions devient le seul disponible. Ce pilote utilise le mode WAL, une connexion unique en écriture et un pool de connexions en lecture. Nos tests 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 l’activer immédiatement en définissant DB_SQLITE_POOL_SIZE à une valeur supérieure à 0. La taille par défaut du pool sera fixée à 2.

Suppression du mode binaire en mémoire

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

• filesystem : les données binaires sont stockées sur le système de fichiers (mode par défaut en mode régulier).
• database : les données binaires sont stockées dans la base de données (mode 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é : seul N8N_DEFAULT_BINARY_DATA_MODE déterminera désormais le mode utilisé.

Chemin de migration : Le mode fichier ou base de données sera utilisé automatiquement selon votre configuration. Assurez-vous que votre instance n8n dispose d’assez d’espace disque pour stocker les données binaires. Consultez la documentation sur la configuration des données binaires.

Configuration et environnement

Mise à niveau de dotenv

n8n utilise la bibliothèque dotenv pour charger la configuration depuis les fichiers .env. Cette bibliothèque sera mise à niveau de la version 8.6.0 vers la dernière version, ce qui pourrait modifier la façon dont les fichiers .env sont analysés. Les principaux changements incluent :

• Prise en charge des backticks (anti-apostrophes) (#615) : si vos valeurs contiennent des backticks, entourez-les d’apostrophes simples ou doubles.
• Prise en charge des valeurs multilignes.
• Le caractère # marque désormais le début d’un commentaire : les lignes commençant par # seront ignorées.

Chemin de migration : Consultez le journal des modifications de dotenv et mettez à jour vos fichiers .env pour garantir la compatibilité.

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 --tunnel pour le développement ou les tests, passez à une autre solution de tunneling comme ngrok, localtunnel ou Cloudflare Tunnel. Mettez à jour vos workflows et votre documentation en conséquence.

Suppression de QUEUE_WORKER_MAX_STALLED_COUNT

La variable d’environnement QUEUE_WORKER_MAX_STALLED_COUNT et le mécanisme de Bull pour relancer les tâches bloquées seront supprimés, car ils causaient souvent de la confusion et fonctionnaient de manière peu fiable.

Chemin de migration : Supprimez cette variable de votre configuration. Après la mise à niveau, n8n ne relancera plus automatiquement les tâches bloquées. Si vous en avez besoin, implémentez votre propre logique de relance ou un système de surveillance.

Suppression de N8N_CONFIG_FILES

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

Chemin de migration : Supprimez cette variable de votre configuration. Migrez vos paramètres 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 est 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 est supprimé pour éviter les publications accidentelles en production
• unpublish:workflow, avec les paramètres id et all

Chemin de migration : Utilisez la nouvelle commande publish:workflow pour publier des workflows individuels par ID, en précisant éventuellement une version. Pour annuler la publication, utilisez unpublish:workflow. Cela offre une meilleure clarté et un meilleur contrôle sur l’état de publication des workflows.

Hooks externes (External Hooks)

Dépréciation des hooks frontend pour les workflows

Les fonctions hook workflow.activeChange et workflow.activeChangeCurrent sont dépréciées au profit du nouveau hook workflow.published. Ce dernier est déclenché dès qu’une version quelconque d’un workflow est publiée.

Chemin de migration : Mettez à jour votre code pour utiliser le nouveau hook workflow.published à la place des anciens. Ce hook offre un comportement plus cohérent et est déclenché au moment de la publication d’une version de workflow.

Canaux de publication

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

Le tag stable correspond à la dernière version stable, tandis que beta correspond à la dernière version expérimentale. Ces tags sont disponibles à la fois sur npm et Docker Hub. Pour l’instant, n8n continuera à appliquer les tags latest et next sur les versions publiées, mais ceux-ci seront supprimés dans une future version majeure.

Recommandation : Fixez la version de n8n à un numéro spécifique, par exemple 2.0.0.

Signaler un problème

Si vous rencontrez des difficultés lors de la mise à niveau vers n8n 2.0, rendez-vous sur le forum communautaire pour obtenir de l’aide et du support.