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).
Ich stimme zu, dass die Verwendung separater DEV- und PROD-Instanzen mit denselben Anmeldedatennamen in beiden Umgebungen der sauberste Ansatz ist, um Workflows zwischen Umgebungen zu verschieben.
Allerdings habe ich einen Screenshot angehängt, der das Problem zeigt, mit dem ich immer noch konfrontiert bin: Auch wenn die Anmeldedatennamen übereinstimmen, muss ich nach dem Importieren/Verschieben des Workflows jede einzelne Node öffnen und die Anmeldedaten manuell aktualisieren/erneut auswählen, bevor der Workflow vollständig nutzbar ist.
Ja, der Ansatz funktioniert also, aber in der Praxis erfordert er trotzdem das Öffnen jeder Node, die Anmeldedaten verwendet, was bei größeren Workflows ziemlich zeitaufwändig wird.
Gibt es eine bessere Möglichkeit, n8n dazu zu bringen, Anmeldedaten automatisch über den importierten Workflow hinweg neu zuzuordnen oder zu aktualisieren, vorausgesetzt, die Anmeldedatennamen sind in DEV und PROD identisch?
Ich würde manuelle Importe vermeiden, wenn es um Anmeldedaten geht, und stattdessen Versionskontrolle für DEV, Staging und PROD verwenden. Denk daran, dass Versionskontrolle keine Credential Secrets kopiert, also muss jede Umgebung ihre eigenen Anmeldedaten einrichten. Ich würde die Credential-Namen konsistent halten, die PROD-Anmeldedaten vor dem Import erstellen und eine kontrollierte Neuzuordnung in Staging durchführen, bevor ich Production anfasse. Bei selbstgehosteten Setups im großen Maßstab würde ich die n8n API oder CLI verwenden, um Workflow-Credential-Referenzen zu überprüfen und anzupassen, anstatt jeden Node von Hand zu öffnen.
Ein Ansatz, der gut funktioniert, wenn du Self-Hosted nutzt: Verwende n8ns integrierte $env-Variable in Ausdrücken, um umgebungsspezifische Konfigurationen zu laden, speichere dann deine API-Keys als Umgebungsvariablen (z. B. OPENAI_API_KEY_PROD, OPENAI_API_KEY_DEV) und referenziere sie in einem Set-Node am Anfang des Workflows. Die Credential selbst bleibt generisch - nur der HTTP Request-Node oder ein Custom-Auth-Header ändert sich basierend auf $env.ENVIRONMENT.
Für Cloud, wo $env nicht verfügbar ist, ist der sauberste Ansatz das, was tamy.santos erwähnt hat - gleiche Credential-Namen über alle Instanzen hinweg. Benenne sie exakt OpenAI Production, OpenAI Development, halte die Namen auf jeder Instanz identisch, und Workflows werden importiert, ohne dass du auch nur einen Node anfassen musst.
