Salut à tous,
Je commence à gérer une installation n8n plus importante avec plusieurs environnements :
Développement → Staging → Production
et j’essaie de déterminer la meilleure stratégie de déploiement/versioning des workflows.
En ce moment, les modifications se font directement dans l’éditeur, mais c’est devenu risqué parce que :
• C’est difficile de suivre les changements de workflow
• Les retours en arrière sont douloureux
• Les identifiants/configurations diffèrent selon les environnements
• De petites modifications peuvent accidentellement casser la production
J’ai exploré :
• L’export de workflows vers Git
• L’utilisation de l’API n8n pour le déploiement
• Les variables d’environnement pour séparer les configurations
• Des instances n8n séparées par environnement
Ce qui me pose problème :
• Comment les équipes promeuvent-elles en toute sécurité les workflows de dev → staging → prod
• Comment gérer les identifiants sans les encoder en dur
• Si les gens utilisent CI/CD avec n8n ou surtout un déploiement manuel
Décrivez le problème/erreur/question
Quel workflow de déploiement/versioning a fonctionné le mieux ?
Quelles sont les meilleures pratiques recommandées pour les sorties sécurisées et les retours en arrière ?
Quel est le message d’erreur (le cas échéant) ?
Veuillez partager votre workflow
(Sélectionnez les nœuds de votre canevas et utilisez les raccourcis clavier CMD+C/CTRL+C et CMD+V/CTRL+V pour copier et coller le workflow.)
Partagez la sortie retournée par le dernier nœud
Informations sur votre configuration n8n
- Version n8n :
- Base de données (par défaut : SQLite) :
- Paramètre n8n EXECUTIONS_PROCESS (par défaut : own, main) :
- Exécution de n8n via (Docker, npm, n8n cloud, application de bureau) :
- Système d’exploitation :
Ce qui a fonctionné le mieux pour moi, c’est de gérer les workflows n8n de la même manière que je gère les versions d’applications, plutôt que de faire des modifications directement en production.
Salut @Kabrooks
La plupart des équipes de production utilisent : Des instances n8n séparées pour Dev → Staging → Production
au lieu de modifier les workflows directement en production.
Tu vas Construire et tester en Dev
Tester à nouveau en Staging, Passer en Production seulement quand tout fonctionne
Ensuite tu Sauvegardes/exporte les workflows vers Git pour l’historique des versions
Utilise des variables d’environnement pour les clés API, les URLs et les paramètres de base de données
Garde des credentials différentes pour chaque environnement
Cela fonctionne mieux et C’est plus facile de suivre les changements
Mises à jour plus sûres
Rollback facile si quelque chose se casse
Moindre risque de casser les workflows en production
Bon à noter que n8n dispose d’une fonctionnalité Source Control intégrée (Settings > Source Control) - elle se connecte directement à un repo Git et vous permet de pousser/tirer des workflows depuis l’interface utilisateur sans exporter manuellement. Chaque environnement obtient sa propre branche (dev, staging, prod), et la promotion est simplement une fusion + un pull sur l’instance cible. Les identifiants sont exclus du repo par conception, vous les gérez donc séparément par environnement. Pour CI/CD, vous pouvez déclencher n8n pour qu’il tire depuis Git via l’API (POST /source-control/pull), de sorte qu’un pipeline GitHub Actions peut automatiser l’étape de promotion.
J’ai exactement le même problème. La fonctionnalité Source Control serait utile mais 667 €/mois est rédhibitoire pour la plupart des équipes en Community Edition. Ce que je n’ai pas trouvé de solution pour, c’est de donner à chaque développeur un environnement isolé sans copier manuellement 10+ workflows. Avez-vous aussi ce problème ou c’est principalement la promotion staging → prod ?
Salut @Kabrooks
Une approche légère que j’utilise est le versioning manuel des workflows par la dénomination et les sauvegardes exportées.
Par exemple, j’exporte les versions importantes des workflows et j’inclus :
J’ai généralement un style de numérotation structuré (exemple : 0.100) où les différents chiffres reflètent différents niveaux de changement, comme les mises à jour de fonctionnalités par rapport aux révisions de correction de bugs.
C’est une approche simple, mais elle m’aide à identifier rapidement quelle version restaurer si nécessaire. C’est un peu inspiré par les pratiques de versioning logiciel, avant même d’introduire des workflows Git complets de contrôle de source.