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).
Estoy de acuerdo en que mantener instancias separadas de DEV y PROD, con los mismos nombres de credenciales en ambos entornos, es el enfoque más limpio para mover flujos de trabajo entre entornos.
Sin embargo, estoy adjuntando una captura de pantalla que muestra el problema que sigo enfrentando: incluso cuando los nombres de las credenciales coinciden, después de importar/mover el flujo de trabajo, sigo necesitando abrir cada nodo individual y actualizar/reseleccionar manualmente la credencial antes de que el flujo de trabajo sea completamente utilizable.
Así que sí, el enfoque funciona, pero en la práctica sigue requiriendo abrir cada nodo que usa credenciales, lo que se vuelve bastante tiempo-consumidor en flujos de trabajo más grandes.
¿Hay una mejor manera de forzar que n8n reasigne o actualice las credenciales automáticamente en todo el flujo de trabajo importado, asumiendo que los nombres de las credenciales son idénticos en DEV y PROD?
Evitaría las importaciones manuales cuando se trata de credenciales y usaría control de versiones para DEV, staging y PROD en su lugar. Solo ten en cuenta que el control de versiones no copia los secretos de credenciales, así que cada entorno todavía necesita sus propias credenciales configuradas. Mantendría los nombres de credenciales consistentes, crearía las credenciales de PROD antes de la importación, e haría un remapeo controlado en staging antes de tocar producción. Para configuraciones auto-hospedadas a escala, buscaría usar la API o CLI de n8n para inspeccionar y ajustar referencias de credenciales de flujos de trabajo en lugar de abrir cada nodo manualmente.
Un enfoque que funciona bien si estás en auto-alojado: usa la variable $env integrada de n8n en expresiones para extraer la configuración específica del entorno, luego almacena tus claves de API como variables de entorno (por ejemplo, OPENAI_API_KEY_PROD, OPENAI_API_KEY_DEV) y hazles referencia en un nodo Set al inicio del flujo de trabajo. Las credenciales en sí se mantienen genéricas - solo el nodo HTTP Request o un encabezado de autenticación personalizado cambia según $env.ENVIRONMENT.
Para la nube donde $env no está disponible, el enfoque más limpio es el que mencionó tamy.santos - los mismos nombres de credenciales en todas las instancias. Nómbralas exactamente OpenAI Production, OpenAI Development, mantén los nombres idénticos en cada instancia, e importa flujos de trabajo sin tocar un solo nodo.
