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

The instance you're running now is using a different encryption key than the one that encrypted those credential rows. The rows are intact and the database is fine — n8n simply cannot read them.

This almost always means one thing: the database was restored, moved or recreated without the key that went with it.

Before you try anything, understand the precedence rule

This is the part that wastes people's evenings. n8n gets its encryption key from one of two places, and they are not equal partners:

1. If the settings file exists, the key in that file is used.

2. Only if the settings file does not exist is N8N_ENCRYPTION_KEY used — and n8n then writes it into a new settings file.

3. If the file exists and N8N_ENCRYPTION_KEY is set and they differ, n8n refuses to start:

   Mismatching encryption keys. The encryption key in the settings file <path> does not
   match the N8N_ENCRYPTION_KEY env var. Please make sure both keys match.
   

The settings file lives at config inside n8n's user folder — ~/.n8n/config by default. It's JSON, and the key is under encryptionKey.

So the reflex fix — "set N8N_ENCRYPTION_KEY to the old value and restart" — does nothing on an instance that already has a settings file, or it turns a runtime error into a container that won't boot. Neither outcome looks like progress and both are commonly reported as "setting the env var didn't work".

The fix, if you still have the old key

Find it first. It is one of:

• the encryptionKey value in the old instance's ~/.n8n/config
• the N8N_ENCRYPTION_KEY you set in a compose file, .env, Kubernetes secret or hosting-provider config
• whatever your backup contains — if you backed up ~/.n8n as well as the database

Then make this instance use it, via whichever route matches how the instance is set up:

• Settings file present: edit encryptionKey in ~/.n8n/config to the old value and restart. If you also have N8N_ENCRYPTION_KEY set somewhere, make it match or remove it, or you'll hit the mismatch error above.
• Fresh container, no settings file yet: set N8N_ENCRYPTION_KEY to the old value before first start. n8n will adopt it and write the file itself.

Restart, open any affected credential, and confirm the fields populate. That is the only proof that worked — the absence of an error on the credentials list page is not.

If the key is gone, the credentials are gone

There is no recovery path and no tool that can help. The secrets were encrypted with a key that no longer exists; that's the entire point of encrypting them.

What survives: the workflows, the credential records themselves, their names, types and every node's reference to them. What's lost: the secret values inside.

So the repair is to open each affected credential, re-enter the secrets, and save — which re-encrypts them under the current key. Tedious, proportional to how many credentials you have, and it does not require rebuilding any workflows.

Say it plainly to yourself before you spend three hours searching: nobody on a forum has a workaround for this, because there isn't one.

Why this happens, and the Docker version specifically

The encryption key is not stored in the database. If it were, it would be encrypting data while sitting next to it, which protects nothing. It lives on the instance's filesystem instead — which means the database and the key are two separate things to back up, and it is entirely possible, and very common, to back up only one.

The recurring version is a container whose ~/.n8n isn't on a named volume. n8n starts, finds no settings file, auto-generates a key (it logs "No encryption key found - Auto-generating and saving to: …"), and everything works. The container is later recreated — an image update, a host migration, a redeploy — the filesystem goes with it, n8n generates a new key, and now the database it reconnects to is full of rows it can no longer read. Nothing broke at the moment of failure; it broke at the moment the volume wasn't declared.

In queue mode, a worker started without an encryption key refuses to start rather than generating one of its own. That's deliberate: a worker that silently invented a key would write credential data the main instance couldn't read.

Prevent it in the two minutes you have now

• Set N8N_ENCRYPTION_KEY explicitly, from the first start, rather than letting n8n generate one. A key you chose is a key you can find again.
• Store it where you store the database backup. They are useless apart.
• Persist ~/.n8n on a named volume, not in the container's writable layer.
• Test the restore, don't assume it. Restore into a scratch instance and open a credential. A database that restores without errors proves nothing about whether its credentials are readable.

Related credential errors

These come from the same place in n8n's source and are worth telling apart:

The fourth one is the one worth noticing: if decryption succeeded and the JSON is invalid, your key is correct and your data is damaged. That is a different problem with a different owner — your storage or your backup process, not your key.

Sources: packages/core/src/constants.ts (the exact message strings), packages/core/src/credentials.ts (where each is thrown) and packages/core/src/instance-settings/instance-settings.ts (the precedence rule and the mismatch error) in n8n's repository, read directly.

Last verified 15 September 2026 against n8n 2.39.5 (source read on master @ 2.40.0). n8n changes these messages between releases; if the wording you see differs, the version above is what this page was checked against.