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.
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:
If the settings file exists, the key in that file is used.
Only if the settings file does not exist is N8N_ENCRYPTION_KEY used — and n8n
then writes it into a new settings file.
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".
Find it first. It is one of:
encryptionKey value in the old instance's ~/.n8n/configN8N_ENCRYPTION_KEY you set in a compose file, .env, Kubernetes secret or
hosting-provider config~/.n8n as well as the databaseThen make this instance use it, via whichever route matches how the instance is set up:
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.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.
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.
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.
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.~/.n8n on a named volume, not in the container's writable layer.These come from the same place in n8n's source and are worth telling apart:
| Message | Meaning |
|---|---|
Credentials could not be decrypted… |
wrong key — this page |
Mismatching encryption keys… |
settings file and env var disagree; n8n won't start |
No data is set on this credentials. |
the credential record has no encrypted payload at all |
Decrypted credentials data is not valid JSON. |
decryption succeeded but produced garbage — usually partial or corrupted data, not a key problem |
Credentials data is not in a valid format. |
the stored shape isn't what n8n expects |
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.