J’exécute 2 instances n8n auto-hébergées (EKS) - dev et prod. Actuellement, chaque fois que je mets à jour ou ajoute des identifiants en dev, je dois les recréer/mettre à jour manuellement en prod aussi, ce qui est fastidieux et sujet aux erreurs, surtout à mesure que le nombre de workflows et d’identifiants augmente.
Je suis bloqué sur la façon d’éviter cette étape de synchronisation manuelle. Quelles sont les meilleures façons d’automatiser la synchronisation des identifiants entre les instances auto-hébergées dev et prod ?
Voici quelques points sur lesquels j’aimerais avoir votre avis :
Y a-t-il un moyen supporté d’exporter/importer des identifiants via la CLI ou l’API qui pourrait être scripté ?
Quelqu’un a-t-il configuré un pipeline CI/CD (par exemple, en utilisant le contrôle de source + la CLI n8n) pour promouvoir les identifiants/workflows de dev vers prod ?
Les variables d’environnement ou un gestionnaire de secrets externe (Vault, AWS Secrets Manager, etc.) sont-ils une meilleure approche à long terme que de stocker les identifiants directement dans chaque instance ?
Tout conseil, workflow ou exemple de personnes qui ont résolu ce problème serait grandement apprécié. Merci !
La CLI n8n est le moyen principal de scripter cela. Vous pouvez en effet exporter et importer à la fois les flux de travail et les identifiants.
L’obstacle : la clé de chiffrement n8n chiffre toutes les identifiants dans sa base de données à l’aide de la clé N8N_ENCRYPTION_KEY. Si vos instances EKS Dev et Prod ont des clés différentes (ce qui devrait être le cas pour des raisons de sécurité), une exportation/importation directe de fichiers chiffrés échouera en Prod car l’instance Prod ne pourra pas les déchiffrer.
La solution : fichiers intermédiaires déchiffrés Vous pouvez utiliser le flag --decrypted pour contourner cela, mais vous devez gérer les fichiers en texte brut résultants avec une extrême prudence.
Flux de travail proposé :
Côté Dev : Exécutez un script dans votre conteneur Dev : n8n export:credentials --all --decrypted --output=credentials_export/
Transport sécurisé : Poussez ces fichiers JSON vers un emplacement sécurisé et éphémère (par exemple, un bucket AWS S3 chiffré avec une politique de cycle de vie pour supprimer après 1 jour, ou une entrée AWS Secrets Manager). Ne commitez jamais ces JSONs en texte brut dans votre référentiel Git.
Côté Prod (Pipeline CI/CD) :
Récupérez les JSONs déchiffrés de votre stockage sécurisé.
Exécutez la commande d’importation dans votre conteneur Prod : n8n import:credentials --input=credentials_export/ --separate
Effacez immédiatement les fichiers locaux après l’importation.
Pour une configuration EKS professionnelle, vous devriez vous éloigner du traitement de la base de données interne de n8n comme « source unique de vérité » pour les secrets. Au lieu de cela, traitez vos identifiants comme faisant partie de votre infrastructure.
La stratégie : gestionnaire de secrets externe + variables d’environnement Au lieu de synchroniser l’« entité d’identifiant » dans n8n, vous tirez parti de la capacité de n8n à utiliser des variables d’environnement pour de nombreuses configurations de service.
Architecture : Stockez vos clés API/mots de passe réels dans AWS Secrets Manager ou HashiCorp Vault.
Implémentation :
Utilisez l’External Secrets Operator (ESO) dans votre cluster EKS pour synchroniser les valeurs d’AWS Secrets Manager dans les secrets Kubernetes.
Injectez ces secrets Kubernetes dans vos pods n8n comme variables d’environnement.
Bien que les identifiants créés via l’interface utilisateur de n8n soient basés sur la base de données, vous pouvez utiliser l’API n8n dans un pipeline CI/CD pour « provisionner » les identifiants en utilisant ces variables d’environnement comme valeurs d’entrée. Cela garantit que la définition de l’identifiant vit dans votre code/coffre-fort, et seule la valeur est injectée au moment de l’exécution.
J’ai créé un outil qui fait exactement cela — il synchronise les identifiants entre les instances n8n auto-hébergées. Pointez-le sur les deux, il gère la correspondance. Plus besoin de rentrer chaque identifiant à la main quand vous poussez en prod.
Bravo @kjooleng ! @Saransh_Sharma
et puis.. un truc que j’ajouterais c’est le contrôle de version/les environnements de n8n pour la promotion dev → prod. Ça peut gérer les workflows et les stubs de credentials via Git tout en gardant les secrets réels en dehors du repo.
Pour EKS, une configuration propre serait :
Git/n8n Source Control → workflow + référence de credential
AWS Secrets Manager/Vault → Secrets réels
CI/CD → promouvoir les changements et déployer en Prod
Je traiterais aussi les exports --decrypted comme une option de migration/automatisation, pas comme la source de vérité à long terme, puisque ces fichiers contiennent les credentials en texte clair