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).
Concordo que manter instâncias separadas de DEV e PROD, com os mesmos nomes de credenciais em ambos os ambientes, é a abordagem mais limpa para mover workflows entre ambientes.
No entanto, estou anexando uma captura de tela que mostra o problema que ainda estou enfrentando: mesmo quando os nomes das credenciais correspondem, após importar/mover o workflow ainda preciso abrir cada nó individual e atualizar/reselecionar a credencial manualmente antes que o workflow esteja totalmente utilizável.
Então sim, a abordagem funciona, mas na prática ainda requer abrir todos os nós que usam credenciais, o que se torna bastante demorado em workflows maiores.
Existe uma forma melhor de forçar o n8n a remapear ou atualizar credenciais automaticamente em todo o workflow importado, considerando que os nomes das credenciais são idênticos em DEV e PROD?
Evitaria importações manuais quando credenciais estão envolvidas e usaria controle de versão para DEV, staging e PROD. Só lembre-se de que o controle de versão não copia segredos de credenciais, então cada ambiente ainda precisa ter suas próprias credenciais configuradas. Manteria os nomes de credenciais consistentes, criaria as credenciais de PROD antes da importação e faria um remapeamento controlado em staging antes de mexer na produção. Para configurações auto-hospedadas em larga escala, procuraria usar a API ou CLI do n8n para inspecionar e ajustar referências de credenciais de workflow em vez de abrir cada nó manualmente.
Uma abordagem que funciona bem se você estiver em self-hosted: use a variável $env integrada do n8n em expressões para extrair configurações específicas do ambiente, então armazene suas chaves de API como variáveis de ambiente (por exemplo, OPENAI_API_KEY_PROD, OPENAI_API_KEY_DEV) e referencie-as em um nó Set no início do fluxo de trabalho. A credencial em si permanece genérica - apenas o nó HTTP Request ou um cabeçalho de autenticação personalizado muda com base em $env.ENVIRONMENT.
Para cloud onde $env não está disponível, a abordagem mais limpa é a que tamy.santos mencionou - mesmos nomes de credenciais nas instâncias. Nomeie-as exatamente como OpenAI Production, OpenAI Development, mantenha os nomes idênticos em cada instância, e os fluxos de trabalho são importados sem tocar em um único nó.
