I’m currently using n8n Pro, and I’m trying to understand the best practice for managing credentials between DEV and PROD environments.
I have a workflow built in DEV with multiple nodes configured using development credentials, for example:
OpenAI
ERPNext
other external services
When the workflow is ready, I duplicate it to move it to production.
The issue is that I then have to manually open many nodes and replace the DEV credentials with the PROD credentials.
I’m wondering whether there is a better approach in n8n, such as:
dynamically using different credentials depending on the environment
avoiding manual credential replacement node by node
having a cleaner deployment process from development to production
So my main question is:
Is there a way in n8n to configure a workflow so that it automatically uses the correct credentials for DEV or PROD, without manually changing the credentials in every node after duplicating the workflow?
I’d also like to understand what the recommended best practices are in this scenario. For example:
duplicating the workflow and manually changing credentials
using separate DEV/PROD instances
using environment variables
following a naming convention for credentials
or any other cleaner strategy
If anyone has already solved this in a structured way, I’d really appreciate an example of how you organize it.
I’d usually handle this with separate DEV and PROD instances, and keep the credential names the same in both. That way the workflow can move over much more cleanly, without opening every node to swap credentials.
Hi @Gianluca having different instances is a bit unusual, people just separate workflows based on “CRM Staging” & “CRM Prod” and that is really it, having different cloud instances just to keep things separated is not a bad idea but sounds like a too much work, why dont you try just having a single instance but a folder named Prod containing all published and in production flows and externally just keep all the flows you are working on, so that would cut off another n8n instance overhead and also a lot of copy pasting time, and in case if you really want this setup i recommend having your production n8n instance self hosted, so that you can do a lot of customization related to credentials as on cloud there is almost nothing related to env variables.
Just to make sure I understood correctly: do you mean having separate DEV and PROD instances (or projects), each with its own credentials but using the same credential names, and then maintaining two copies of the workflow, one in DEV and one in PROD?
happy to help!
I hope everything goes well.
If this solution solves your problem, please consider liking or marking the answer as the solution (this helps others find the answer more easily and also supports community contributors).
Je suis d’accord que le maintien d’instances DEV et PROD séparées, avec les mêmes noms de credentials dans les deux environnements, est l’approche la plus épurée pour déplacer des workflows entre environnements.
Cependant, je joins une capture d’écran qui montre le problème auquel je fais toujours face : même lorsque les noms de credentials correspondent, après l’import/déplacement du workflow, je dois toujours ouvrir chaque nœud individuellement et actualiser/resélectionner manuellement la credential avant que le workflow soit complètement utilisable.
Alors oui, l’approche fonctionne, mais en pratique, elle nécessite toujours d’ouvrir chaque nœud qui utilise des credentials, ce qui devient assez chronophage sur les workflows plus volumineux.
Y a-t-il une meilleure façon de forcer n8n à remapper ou actualiser automatiquement les credentials dans le workflow importé, en supposant que les noms de credentials sont identiques dans DEV et PROD ?
J’éviterais les imports manuels lorsque des credentials sont impliqués et j’utiliserais plutôt le contrôle de source pour DEV, staging et PROD. Garde à l’esprit que le contrôle de source ne copie pas les secrets des credentials, donc chaque environnement doit toujours avoir ses propres credentials configurés. Je maintiendrais les noms des credentials cohérents, créerais les credentials PROD avant l’import, et ferais un remapping contrôlé en staging avant de toucher la production. Pour les configurations auto-hébergées à grande échelle, j’examinerais l’utilisation de l’API n8n ou de la CLI pour inspecter et ajuster les références de credentials du workflow au lieu d’ouvrir chaque nœud manuellement.
Une approche qui fonctionne bien si vous êtes en auto-hébergement : utilisez la variable intégrée $env de n8n dans les expressions pour récupérer la configuration spécifique à l’environnement, puis stockez vos clés API en tant que variables d’environnement (par exemple, OPENAI_API_KEY_PROD, OPENAI_API_KEY_DEV) et référencez-les dans un nœud Set au début du workflow. Les identifiants eux-mêmes restent génériques - seul le nœud HTTP Request ou un en-tête d’authentification personnalisé change en fonction de $env.ENVIRONMENT.
Pour le cloud où $env n’est pas disponible, l’approche la plus claire est celle mentionnée par tamy.santos - les mêmes noms d’identifiants sur tous les instances. Nommez-les exactement OpenAI Production, OpenAI Development, gardez les noms identiques sur chaque instance, et les workflows s’importent sans toucher à un seul nœud.
