J’utilise n8n en auto-hébergé sur une image Docker dans un produit d’ingénierie logicielle. Chaque fois que je dois passer de l’environnement de développement à SIT, y a-t-il un moyen autre que de lancer une nouvelle image Docker et de copier tous les workflows d’un environnement à l’autre à chaque fois ? Le nombre de workflows est important
@Mohamed8 ne les copie pas à la main, utilise l’export/import de la CLI n8n, ça transfère toute ta bibliothèque d’un coup. Sur le conteneur de dev, exporte tous les workflows vers un dossier, copie ce dossier sur la box SIT, puis importe :
# on dev
docker exec -u node <dev-container> n8n export:workflow --backup --output=/tmp/wf/
# copy /tmp/wf across, then on SIT
docker exec -u node <sit-container> n8n import:workflow --separate --input=/tmp/wf/
il y a une paire export:credentials / import:credentials correspondante si tu dois aussi déplacer les identifiants. c’est mieux que de lancer une nouvelle image et copier à chaque fois.
Merci. J’utilise l’authentification de base dans mes flux de travail, je les ai ajoutées dans les Identifiants et je choisis la bonne pour chaque requête HTTP. Quand je copie le flux de travail, il se réinitialise et choisit le premier identifiant d’authentification de base pour tous les nœuds HTTP par défaut, et je dois les corriger.
Vais-je faire face au même problème avec cette approche ?
@Mohamed8 la réinitialisation se produit parce que les nœuds référencent les identifiants par id et une simple copie ne conserve pas ces ids, donc le système revient au premier correspondant. La CLI l’évite tant que vous déplacez aussi les identifiants, pas seulement les workflows : export:credentials --backup sur dev, import:credentials sur SIT. Cet import fait un upsert par id, donc chaque identifiant conserve son id original et les références du workflow se résolvent automatiquement vers le bon basic auth.
un piège cependant : les identifiants sont chiffrés avec N8N_ENCRYPTION_KEY, donc SIT a besoin de la même clé que dev sinon ils ne se déchiffreront pas. Si les clés diffèrent, exportez avec --decrypted et ils se rechiffrera lors de l’import.
Super ! Avez-vous une idée de comment accéder à cette clé de chiffrement ? Et si elle peut être exportée ou non ?
@Mohamed8 ce n’est pas exporté avec les workflows. c’est soit la variable d’env N8N_ENCRYPTION_KEY si tu en as défini une, soit si tu ne l’as jamais fait, n8n l’a générée automatiquement et l’a sauvegardée dans le fichier de configuration. lis-la en dev avec :
docker exec -u node <dev-container> cat /home/node/.n8n/config
tu verras une valeur encryptionKey dedans. le chemin le plus simple est de définir cette même valeur en tant que N8N_ENCRYPTION_KEY sur SIT (dans ton env compose/run), alors les deux partagent la clé et les identifiants importés se déchiffrent. la définir explicitement sur les deux est mieux que de compter sur le fichier généré automatiquement de toute façon.
Salut @Mohamed8, l’approche CLI de @achamm est la bonne solution pour ce que tu as actuellement. Un truc qui vaut le coup de considérer à plus long terme, puisque ça a l’air d’être une promotion dev→SIT récurrente dans un vrai pipeline de produit, n8n supporte le contrôle de source via Git (Settings → Source Control, disponible sur certains plans) qui transforme ça en un vrai flux style CI/CD : pousse tes workflows de dev vers un repo Git, puis tire/déploie sur SIT automatiquement. Ça versionne aussi tes workflows correctement, donc tu obtiens des diffs et des rollbacks gratuitement au lieu de faire des export/import manuels à chaque fois.
Si le contrôle de source basé sur Git n’est pas disponible sur ton plan/édition, l’export/import CLI de @achamm est l’équivalent manuel correct, juste bon de savoir que l’option automatisée existe si ça devient une étape de pipeline fréquente plutôt qu’une migration ponctuelle.
Je rencontre un problème lorsque j’essaie d’importer mes workflows dans mon nouvel environnement.
J’obtiens une erreur
Active version not found for workflow
Error: Active version not found for workflow
at ActiveWorkflowManager.clearWebhooks (/usr/local/lib/node_modules/n8n/src/active-workflow-manager.ts:248:10)
at ActiveWorkflowManager.remove (/usr/local/lib/node_modules/n8n/src/active-workflow-manager.ts:872:4)
at ImportService.importWorkflows (/usr/local/lib/node_modules/n8n/src/services/import.service.ts:84:5)
at ImportWorkflowsCommand.run (/usr/local/lib/node_modules/n8n/src/commands/import/workflow.ts:104:3)
at CommandRegistry.execute (/usr/local/lib/node_modules/n8n/src/command-registry.ts:83:4)
at /usr/local/lib/node_modules/n8n/bin/n8n:63:2
Could not remove webhooks of workflow "0YdMxcy7MAjVkwy2" because of error: "Active version not found for workflow"
Could not find workflow
Error: Could not find workflow
at ActiveWorkflowManager.clearWebhooks (/usr/local/lib/node_modules/n8n/src/active-workflow-manager.ts:244:10)
at ActiveWorkflowManager.remove (/usr/local/lib/node_modules/n8n/src/active-workflow-manager.ts:872:4)
at ImportService.importWorkflows (/usr/local/lib/node_modules/n8n/src/services/import.service.ts:84:5)
at ImportWorkflowsCommand.run (/usr/local/lib/node_modules/n8n/src/commands/import/workflow.ts:104:3)
at CommandRegistry.execute (/usr/local/lib/node_modules/n8n/src/command-registry.ts:83:4)
at /usr/local/lib/node_modules/n8n/bin/n8n:63:2
Étant donné que mes workflows ont des déclencheurs webhook et que certains d’entre eux sont actifs et que ma version n8n est 2.1.4, avez-vous une idée ?
@ShawnWilliams @achamm
@Mohamed8 c’est l’import qui essaie de gérer l’état actif des workflows. Les versions plus récentes de n8n suivent les workflows actifs via un ID de version, et importer un workflow actif dont le enregistrement active-version n’existe pas encore sur SIT fait échouer clearWebhooks avec ça. La solution la plus propre est de les importer en tant qu’inactifs, désactiver les workflows sur dev avant l’export pour qu’ils s’importent avec active:false, puis les activer sur SIT après leur chargement. Et si l’exécution échouée a laissé des copies partiellement importées bloquées actives sur SIT, désactivez ou supprimez-les d’abord pour que l’import suivant n’essaie pas de nettoyer les webhooks pour elles.
existe-t-il un moyen de les activer/désactiver via la CLI ?
@Mohamed8 ouais, la commande n8n update:workflow le fait :
docker exec -u node <container> n8n update:workflow --all --active=false
change --active=true pour activer, ou utilise --id= à la place de --all pour cibler un seul. donc ton flux devient désactiver sur dev, exporter, importer sur SIT, puis l’exécuter avec --active=true sur SIT. si tu ne veux pas que dev soit hors ligne, désactive juste les copies bloquées sur SIT avec --all --active=false, réimporte, puis réactive là-bas.
Merci beaucoup pour votre aide. @achamm
quand j’essaie de publier un par un, j’obtiens une erreur
Publishing workflow with ID: Error tracking disabled because this release is older than 6 weeks. (current version)
Error updating database. See log messages for details.
GOT ERROR
Workflow "Error tracking disabled because this release is older than 6 weeks." not found.
Error: Workflow "Error tracking disabled because this release is older than 6 weeks." not found.
at WorkflowRepository.publishVersion (/usr/local/lib/node_modules/n8n/node_modules/.pnpm/
+db@file+packages+
+db_@opentelemetry+api@1.9.0_@opentelemetry+sdk-trace-base@1._ab22bba05a964211b9fe14bf4b841570/node_modules/
/db/src/repositories/workflow.repository.ts:894:11)
at PublishWorkflowCommand.run (/usr/local/lib/node_modules/n8n/src/commands/publish/workflow.ts:43:3)
at CommandRegistry.execute (/usr/local/lib/node_modules/n8n/src/command-registry.ts:83:4)
at /usr/local/lib/node_modules/n8n/bin/n8n:63:2
Workflow "Error tracking disabled because this release is older than 6 weeks." not found.
Publishing 0YdMxcy7MAjVkwy2
Error tracking disabled because this release is older than 6 weeks.
Publishing workflow with ID: 0YdMxcy7MAjVkwy2 (current version)
Error updating database. See log messages for details.
auussi quand j’essaie de le publier depuis l’interface utilisateur, il dit Le workflow n’a pas pu être publié :
Version non trouvée
@Mohamed8 ne fais pas un par un, c’est ce per-id publish qui pose problème, l’ID du workflow ne se résout pas donc n8n ne peut pas le trouver. lance juste l’activation en masse :
docker exec -u node <container> n8n update:workflow --all --active=true
ça les active tous d’un coup sans que tu passes des IDs individuels. si même --all génère une erreur, c’est probablement une particularité de la version que tu utilises (cette ligne « 6-weeks » veut dire que c’est une version plus ancienne), et upgrader vers une version n8n actuelle vaut le coup d’essayer.
Le conseil d’export/import CLI est une bonne base. Si vous avez beaucoup de workflows, je traiterais également dev → SIT comme un processus de release plutôt que comme une opération de copie.
Les points que j’ajouterais :
- Conservez les exports dans le contrôle de version pour savoir ce qui a changé entre les promotions.
- Séparez la structure du workflow des valeurs spécifiques à l’environnement.
- Ne déplacez pas aveuglément les identifiants de production à moins d’avoir un modèle clair de propriété des identifiants.
- Exécutez des vérifications de base après l’import pour les workflows importants.
- Enregistrez les workflows qui ont été promus, ceux qui ont échoué et ce qui nécessite un suivi manuel.
- Maintenez un chemin de restauration, même si c’est juste réimporter l’export précédent connu comme bon.
L’étape de copie n’est généralement pas ce qui pose problème par la suite. La partie douloureuse, c’est quand personne ne sait quelle version se trouve dans quel environnement, si SIT a vraiment été testé, ou quel workflow s’est cassé après le déplacement. Ce journal de promotion devient particulièrement important une fois que les workflows deviennent accessibles aux clients.
@achamm mais chaque fois que j’utilise
docker exec -u node n8n update:workflow --all --active=true
ça dit
⚠️ WARNING: The "update:workflow" command is deprecated.
Workflow publishing via "update:workflow --all" is no longer supported.
Please publish workflows individually using: publish:workflow --id=<workflow-id>
@Mohamed8 ouais --all a été déprécié et le nouveau publish:workflow est où tu as eu cette erreur de version plus tôt, donc ignore la CLI publish et utilise l’API REST publique à la place, elle a un endpoint activate dédié qui contourne complètement le versioning :
POST /api/v1/workflows/{id}/activate
génère une clé API dans Settings > n8n API, liste tes workflows avec GET /api/v1/workflows pour récupérer les ids, puis boucle cet appel activate sur chacun. c’est ta bulk activate sans toucher à la commande publish cassée.
@achamm interroger les identifiants de workflow depuis sqlite et ensuite boucler dessus pourrait être une alternative ?
@Mohamed8 ouais lire les ids depuis sqlite fonctionne bien, la table est workflow_entity donc SELECT id FROM workflow_entity te donne la liste (l’api GET /api/v1/workflows fait la même chose et n’est pas liée au schéma de la db, mais ça marche dans les deux cas). limite-toi juste à la lecture, n’active pas en écrivant active=1 directement dans sqlite, ça contourne le trigger/webhook registration que n8n fait lors de l’activation et c’est exactement ce qui laisse les workflows dans cet état broken active-version. récupère les ids comme tu veux, mais lance l’activation via l’endpoint de l’api pour que n8n configure les triggers correctement.
Merci de ton aide @achamm. Penses-tu que la réplication du volume n8n de DEV pour être utilisé en SIT conserverait correctement les IDs de credentials et les nœuds attachés ?
Je vois que tous les détails sont stockés dans SQLite qui réside dans le volume n8n.
@Mohamed8 ouais, cloner le volume entier fonctionne et c’est le plus propre pour garder tout attaché — c’est une copie octet par octet de la même base de données sqlite, donc les credential ids, les workflow ids et chaque référence de nœud restent identiques, rien à relier. La clé de chiffrement voyage aussi puisqu’elle est dans .n8n/config à l’intérieur de ce volume, donc les credentials se déchiffrent sur SIT, juste ne définis pas une autre variable env N8N_ENCRYPTION_KEY sur SIT ou ça va entrer en conflit.
deux pièges cependant : c’est une complète réécriture, ça remplace tout sur SIT et ça porte la config spécifique à l’env de DEV (urls, webhook base, valeurs de creds dev-vs-prod), donc c’est top si SIT est censé refléter DEV, moins si SIT a besoin de ses propres paramètres. et arrête n8n avant de copier le fichier sqlite, le copier en direct peut le corrompre, ou utilise la .backup de sqlite pour un snapshot propre. si SIT a besoin de sa propre config, l’export/import sélectif reste la meilleure route.