Rotating n8n Credentials: Swap Secrets Without Stopping Workflows

If an API key or password in an n8n credential record is compromised, first swap the value directly in the affected credential record, because workflows reference credentials by a fixed ID and not by the stored value, so no link needs to be recreated. For automated or centrally managed rotation across multiple environments, n8n offers its own mechanism with External Secrets, which is not available in every edition, however. Status: August 2026.

What do you do immediately with a compromised credential record?

Open the affected credential record in n8n, enter the new value, and save. Because all workflows reference the record by its ID, they automatically run with the new value after saving, without you having to touch individual nodes. Simultaneously revoke the old key directly with the respective provider, because n8n itself cannot invalidate an externally valid key.

How does External Secrets work, and who can use it?

External Secrets stores sensitive values in an external vault instead of directly in n8n and loads them on demand. The function is available exclusively in the Enterprise editions, both Self-hosted and Cloud, and is completely absent in the Community Edition.

• Supported providers: 1Password via Connect Server, AWS Secrets Manager, Azure Key Vault, GCP Secrets Manager, HashiCorp Vault, and Infisical.
• Setup: under Settings, External Secrets, add a new vault, select the provider, and store the provider-specific credentials.
• Usage: in the desired credential field, enter the reference {{ $secrets.<vault-name>.<secret-name> }} via expression.

An important limitation: Secrets from an external vault resolve exclusively in credential fields, not in other expressions within a workflow.

What is the difference between credential rotation and encryption-key rotation?

These are two different processes that are regularly confused in the n8n forum. Changing a single credential record affects only that one record. Changing the N8N_ENCRYPTION_KEY, on the other hand, affects the encryption of all stored credentials simultaneously, because this key secures the entire credential database.

User reports in the forum repeatedly describe the same error after careless encryption-key rotation: "Credentials could not be decrypted, the likely reason is that a different encryptionKey was used to encrypt the data." This error effectively means total loss of all stored credentials if no database backup exists before rotation. Therefore, only change the encryption code with a prior backup and never in response to a single compromised API key; changing the affected credential record is sufficient for that.

What emergency path exists for the Community Edition without External Secrets?

Without an Enterprise license, only the manual path remains: swap the affected value directly in the respective credential record in the interface. For globally valid credentials, such as OAuth connections that should be automatically set at startup, n8n additionally offers Credential Overwrites. This function overwrites credentials globally via a REST API or environment variable, but is not designed for rotating compromised keys, but rather for central initial configuration. The documentation explicitly advises against the CREDENTIALS_OVERWRITE_DATA environment variable because environment variables in n8n do not have special protection, and instead recommends the endpoint path with optional auth token. Those considering External Secrets in principle will find support with NordFlux support for implementation.

Frequently asked questions about credential rotation in n8n

Do I need to re-save workflows after changing a credential record?

No. Workflows reference credentials by a fixed ID, so a change to the record automatically takes effect for all linked workflows as soon as you save the record.

What happens if I change the encryption code?

Without a prior database backup and careful procedure, all stored credentials can become unusable with the error "Credentials could not be decrypted". Therefore, treat this step separately from rotating individual credentials and only with a backup.

Which vault providers does External Secrets support?

Supported are 1Password via Connect Server, AWS Secrets Manager, Azure Key Vault, GCP Secrets Manager, HashiCorp Vault, and Infisical. The function is available exclusively in the Enterprise editions.

Can I use External Secrets outside of credential fields?

No, the documentation makes clear that secrets from an external vault resolve exclusively in credential fields. They are not available in other expressions within a workflow, such as in a code node.