Migrer vers n8n 2.0 sans casser ses workflows : guide Docker

💡 En résumé (TL;DR)

• n8n 2.0 renforce la sécurité et la stabilité, mais modifie certains comportements qui peuvent interrompre des workflows existants.
• Lancez le Migration Report avant la mise à jour : il détecte les workflows et paramètres nécessitant une intervention.
• Sauvegardez PostgreSQL ou SQLite, le volume n8n et surtout N8N_ENCRYPTION_KEY avant toute opération.
• Les nœuds ExecuteCommand et LocalFileTrigger sont désactivés par défaut ; l'accès aux variables d'environnement et aux fichiers est plus restrictif.
• Ne mettez jamais une instance métier à niveau avec l'image Docker latest sans test. Épinglez une version exacte et préparez le retour arrière.

n8n 2.0 ne doit pas être traité comme une mise à jour mineure. Cette version consolide l'exécution du code, la gestion des fichiers, la publication des workflows et plusieurs réglages historiques. Les changements améliorent la sécurité, mais peuvent casser une automatisation qui dépendait d'un ancien comportement permissif.

Ce guide propose une migration contrôlée pour une instance n8n auto-hébergée avec Docker. Si vous débutez, commencez par notre guide complet n8n pour PME. Si vous venez de Zapier, utilisez plutôt notre méthode pour migrer de Zapier vers n8n.

Pourquoi n8n 2.0 demande une préparation ?

n8n présente la version 2.0 comme une évolution centrée sur la sécurité, la fiabilité et les performances. Les principaux effets visibles pour une instance existante sont :

• exécution du code davantage isolée par les task runners ;
• accès aux variables d'environnement bloqué par défaut dans certains nœuds ;
• restriction de l'accès au système de fichiers ;
• désactivation par défaut de nœuds capables d'exécuter des commandes ou de surveiller des fichiers locaux ;
• suppression de fonctions et modes de stockage hérités ;
• séparation plus nette entre sauvegarder un brouillon et publier une version active ;
• corrections de comportement des sous-workflows et des exécutions longues.

Un workflow simple Gmail → Google Sheets peut continuer à fonctionner sans changement. Un workflow avec scripts, commandes système, fichiers montés, variables process.env ou sous-workflows doit être considéré à risque jusqu'à validation.

Étape 1 — Inventorier l'instance

Avant de toucher à Docker, documentez :

Exportez aussi la liste des workflows et identifiez ceux qui facturent, suppriment des données, créent des commandes ou contactent des clients.

Étape 2 — Utiliser le rapport de migration n8n 2.0

n8n fournit un outil de migration qui analyse l'instance et signale les problèmes de compatibilité et de configuration. Exécutez-le depuis une version 1.x prise en charge avant la bascule.

Le rapport ne remplace pas les tests. Il permet de trouver plus vite :

• les nœuds désactivés en 2.0 ;
• les anciens déclencheurs ;
• les accès à l'environnement ou au système de fichiers ;
• les configurations supprimées ou renommées ;
• les workflows qui nécessitent une publication explicite ;
• les composants communautaires à vérifier.

Traitez les alertes selon trois niveaux :

1. Bloquant : corriger avant la mise à niveau.
2. Risque métier : tester avec un jeu de données contrôlé.
3. Amélioration : planifier après stabilisation.

Conservez une copie du rapport avec la date et la version analysée.

Étape 3 — Sauvegarder ce qui permet réellement de restaurer

Un export JSON des workflows ne suffit pas. Il ne restaure pas nécessairement les credentials, utilisateurs, historiques et configurations.

Sauvegarde PostgreSQL

Adaptez les noms du conteneur et de la base :

docker exec n8n-postgres pg_dump -U n8n -d n8n -Fc > n8n-pre-v2.dump

Le fichier doit être copié hors du serveur et testé par une restauration dans une base temporaire.

Sauvegarde des volumes

Sauvegardez le volume /home/node/.n8n et les répertoires métiers montés. La commande dépend de votre plateforme ; l'objectif est d'obtenir une archive lisible hors du conteneur, pas un instantané dont personne ne connaît la procédure de restauration.

Clé de chiffrement

Sans la valeur exacte de N8N_ENCRYPTION_KEY, les credentials chiffrés peuvent devenir inutilisables après restauration. Stockez cette clé dans un gestionnaire de secrets, séparée de l'archive de la base.

Test de restauration

Une sauvegarde est validée uniquement si vous pouvez :

1. lancer une instance isolée ;
2. restaurer la base et les volumes ;
3. ouvrir les workflows ;
4. déchiffrer les credentials ;
5. exécuter un workflow de test sans contacter la production.

Étape 4 — Corriger les changements les plus cassants

ExecuteCommand et LocalFileTrigger

Ces nœuds sont désactivés par défaut pour réduire le risque d'exécution arbitraire et d'accès au système de fichiers.

Ne les réactivez pas globalement par réflexe. Pour chaque workflow :

• remplacez une commande par une API lorsque possible ;
• placez le traitement dans un microservice isolé ;
• limitez l'utilisateur Linux et les volumes visibles ;
• journalisez la commande et ses paramètres ;
• réactivez uniquement ce qui est indispensable.

Variables d'environnement dans le nœud Code

Un script utilisant process.env.MA_CLE peut ne plus fonctionner. Déplacez les secrets vers les credentials n8n ou une méthode explicitement prise en charge. Les données non sensibles peuvent être passées en entrée du workflow.

Accès aux fichiers

Montez un répertoire dédié, par exemple /files, et configurez la restriction d'accès pour empêcher un workflow de parcourir l'hôte. Vérifiez les chemins absolus : un montage Docker différent entre test et production est une source classique d'échec.

Task runners

Les nœuds Code utilisent des runners isolés. Pour un mode externe, le conteneur principal et le conteneur runner doivent partager un réseau, un jeton d'authentification et une URI de broker cohérents.

Exemple de structure à adapter, sans secrets en clair :

services:
  n8n:
    image: docker.n8n.io/n8nio/n8n:2.0.0
    restart: unless-stopped
    environment:
      N8N_RUNNERS_ENABLED: "true"
      N8N_RUNNERS_MODE: external
      N8N_RUNNERS_BROKER_LISTEN_ADDRESS: 0.0.0.0
      N8N_RUNNERS_AUTH_TOKEN: ${N8N_RUNNERS_AUTH_TOKEN}
    networks: [n8n_net]

  runners:
    image: n8nio/runners:2.0.0
    restart: unless-stopped
    environment:
      N8N_RUNNERS_MODE: external
      N8N_RUNNERS_TASK_BROKER_URI: http://n8n:5679
      N8N_RUNNERS_AUTH_TOKEN: ${N8N_RUNNERS_AUTH_TOKEN}
      N8N_RUNNERS_ENABLED_TASK_TYPES: javascript,python
    networks: [n8n_net]

networks:
  n8n_net:

Vérifiez les exemples correspondant à votre version dans la documentation n8n ; les variables peuvent évoluer.

Étape 5 — Cloner une préproduction fidèle

La préproduction doit reproduire :

• même moteur et version de base de données ;
• mêmes montages, mais données isolées ;
• même reverse proxy et mêmes en-têtes ;
• mêmes nœuds communautaires ;
• même mode de runners ;
• mêmes limites de mémoire et de CPU.

Neutralisez les actions irréversibles :

• emails vers une boîte de test ;
• paiements en sandbox ;
• CRM de test ;
• webhooks avec URL différente ;
• suppression remplacée par un journal.

Importez une copie récente des workflows, puis mettez la copie à niveau.

Étape 6 — Épingler les images Docker

Évitez :

image: docker.n8n.io/n8nio/n8n:latest

Préférez une version exacte validée :

image: docker.n8n.io/n8nio/n8n:2.0.0

Après validation, vous pourrez passer vers un correctif 2.0.x ou 2.x précis. L'épinglage garantit qu'un redémarrage ne télécharge pas silencieusement une version différente.

Avant la mise à niveau :

docker compose config
docker compose pull
docker compose up -d
docker compose logs --tail=200 n8n

Ne lancez pas ces commandes sans avoir vérifié le répertoire, le fichier Compose, les sauvegardes et la procédure de retour arrière.

Étape 7 — Construire une matrice de tests

Testez au moins une exécution réussie, une donnée vide, une erreur API, un timeout et une relance pour chaque workflow critique.

Étape 8 — Basculer et surveiller

1. Geler les modifications de workflows.
2. Réaliser une sauvegarde finale.
3. Mettre en pause les déclencheurs externes si nécessaire.
4. Déployer la version validée.
5. Vérifier santé, base, runners et files d'exécution.
6. Réactiver par groupes de workflows.
7. Surveiller erreurs, latence, doublons et webhooks pendant 24 à 72 heures.

Le retour arrière doit préciser la version Docker précédente, la base à restaurer, les volumes concernés et la manière de rejouer les événements reçus pendant l'interruption.

FAQ migration n8n 2.0

Peut-on mettre n8n 1.x à niveau directement vers 2.0 ?

Oui si la version de départ et la configuration sont prises en charge, mais il faut d'abord lire les changements cassants, exécuter le rapport de migration et tester une copie.

Le rapport de migration garantit-il que tout fonctionnera ?

Non. Il détecte de nombreux risques connus, mais ne peut pas valider la logique métier, les API externes, les données réelles et les nœuds communautaires.

Pourquoi ExecuteCommand a-t-il disparu ?

Il est désactivé par défaut en raison de son risque de sécurité. Il peut être réactivé explicitement, mais un service isolé ou une API est souvent préférable.

Faut-il passer de SQLite à PostgreSQL ?

Pour un usage professionnel soutenu, PostgreSQL est généralement plus adapté. La décision dépend du volume et de l'architecture ; migrez la base dans une opération séparée si possible.

Peut-on revenir à n8n 1.x après la migration ?

Uniquement avec un plan testé et une sauvegarde compatible de la base et des volumes. Ne supposez pas qu'il suffit de changer le tag Docker après une migration de schéma.

Sources officielles consultées

• n8n — Changements cassants de la version 2.0
• n8n — Outil de migration 2.0
• n8n — Notes de version 2.x
• n8n — Installation avec Docker

Dernière vérification des informations : 30 août 2026.