Why Do Admin Credentials Fail to Decrypt After Upgrading n8n to 1.75.0–1.75.2?

Below is an explanation that might help you narrow down the issue:

What the Error Means

n8n is trying to decrypt stored credentials but finds that the decryption fails because the encryption key used at decryption time doesn’t match the one that was used to encrypt the data. The error message:

  "Credentials could not be decrypted. The likely reason is that a different “encryptionKey” was used to encrypt the data."

indicates a mismatch in encryption keys.

Why It Might Happen for the Admin User Only

Even though the encryption key has never been intentionally changed, there are a couple of scenarios to consider:

• Different Worker or Environment Configuration:
  If you’re running n8n with multiple processes (even when using pm2), ensure that all processes have the same value for the encryption key. In queue mode (or when multiple workers are involved) the environment variable (commonly set as N8N_ENCRYPTION_KEY) must be defined consistently for every instance.

• Initial Auto-Generated Encryption Key:
  By default, n8n creates a random encryption key on first launch and stores it in the ~/.n8n folder. If that key somehow changed for the Admin user’s process (for example, due to a process restart without preserving the original key), the Admin’s credentials wouldn’t be decryptable—while credentials for other users (encrypted with the previous key) might continue to work if they’re being handled differently.

Steps to Troubleshoot

1. Check Your Environment Variables:
   Verify that the environment variable N8N_ENCRYPTION_KEY is set consistently across all n8n processes. If it’s not provided explicitly, n8n will use the auto-generated key each time it starts, and that can change between restarts if not persisted.

   BASHCopied
   export N8N_ENCRYPTION_KEY=<your-custom-string>

2. Confirm Worker Consistency:
   Make sure that if you’re running n8n with multiple processes or in queue mode, every worker is launched with the same encryption key. This ensures that every process can correctly decrypt credentials.

3. Review the Upgrade Impact:
   Since the issue started in version 1.75.0, check if the upgrade affected how the encryption key is handled or loaded (for example, changes in default behavior when no custom key is set). Reviewing the release notes may provide further hints.

4. Admin Credentials Specificity:
   Investigate whether credentials owned by the admin were created or modified before/after the upgrade. Any potential inconsistency in when those credentials got encrypted could lead to decryption issues if the key is not the same.

Summary

The error indicates that, for the Admin user, the encryption key currently used by n8n does not match the key that was used when the credentials were originally encrypted. Confirm all n8n processes are started with the same N8N_ENCRYPTION_KEY (or are consistently using the same auto-generated key), especially when running in a multi-process environment like with pm2. This should help resolve why only the Admin user encounters the decryption problem.