n8n encryption key errors

Which message you have, and what it means

All three were triggered on purpose on n8n 2.41.3, installed from npm on Node 24 and run with NODE_ENV=production, the same value the official image’s Dockerfile sets. Messages are copied from the terminal, with our local folder path shortened to …/.n8n/config. We did not run the Docker image itself for this page; paths in the Docker column come from n8n’s Dockerfile and docs.

Step 1 — find the key your data was encrypted with

Every fix below needs the original key, so find it before changing anything. It is in one of two places:

• The config file in the old n8n folderA one-field JSON file; on our instance it had this shape, with a 32-character random value:

  {
  	"encryptionKey": "<32 random characters, unique to this instance>"
  }

  In Docker it is inside whatever volume was mounted at /home/node/.n8n. If you recreated the container with a new, empty volume, the old volume — not the new one — has the key you need.
• An N8N_ENCRYPTION_KEY you set yourselfIn a Compose file, an .env file, a Kubernetes secret or a hosting panel. If it was ever set, it is the key: n8n uses the variable and, on a fresh folder, writes it into the config file.

If neither exists, the credentials cannot be decrypted by anyone. Skip to “If the key is gone”.

Step 2 — the fix for each message

“Mismatching encryption keys” — make the file and the variable agree

n8n refuses to pick one. We got the error on n8n start and on n8n export:credentials alike, the moment N8N_ENCRYPTION_KEY differed from the file:

Error: Mismatching encryption keys. The encryption key in the settings file
…/.n8n/config does not match the N8N_ENCRYPTION_KEY env var. Please make sure
both keys match. More information:
https://docs.n8n.io/hosting/environment-variables/configuration-methods/#encryption-key

If the instance has been running on the file’s key, that one encrypted your credentials. Set the variable to the value from the file, and recreate the container so the new variable actually reaches the process. Only if you know the credentials were created under the variable’s value should you go the other way.

“Deployment key 'signing.hmac' cannot be read” — restore the original key

This one is new in the 2.x line and older guides do not mention it. We reproduced it by swapping the key in a working instance’s config file and starting it again:

n8n ready on ::, port 5690
Error: Deployment key 'signing.hmac' cannot be read with this instance encryption key
Exiting due to an error.

In 2.41.3 the database stores deployment keys encrypted with the instance key, and startup reads the signing key back. Under a different key that read fails and the process exits. The usual real-world cause: the database survived (Postgres, or an old database.sqlite) but the .n8n folder holding the key was replaced. We put the original config file back and the same instance started and ran a credentialed workflow straight away.

“Credentials could not be decrypted” — re-import the credentials correctly

This is the migration trap. We exported credentials from instance A with a plain n8n export:credentials --all, imported them into a fresh instance B, and ran a workflow that used one. The import printed Successfully imported 1 credential. The run did not:

Credentials could not be decrypted. The likely reason is that a different
"encryptionKey" was used to encrypt the data.
error:1C800064:Provider routines::bad decrypt
Webhook execution failed before a response was sent

The webhook’s caller only saw HTTP 500 {"message":"Error in workflow"}. A plain export writes each credential’s data as an encrypted string (ours began U2FsdGVkX1…), and import stores it untouched. Two ways out, and we ran both successfully on 30 September 2026:

# A — move the secrets in the clear, then delete the file
n8n export:credentials --all --decrypted --output=creds.json   # on the old instance
n8n import:credentials --input=creds.json                      # on the new instance
rm creds.json

# B — give the new instance the old key BEFORE its first start
export N8N_ENCRYPTION_KEY="<value of encryptionKey from the old config>"
n8n import:credentials --input=creds-encrypted.json

Both returned {"status":"ok"} through the same credentialed HTTP Request node that had failed. Option A leaves every secret in a plain-text file for as long as it exists, so treat that file like a password vault export. Option B keeps the old key for good, which is what you want when moving an instance rather than merging two.

If the key is gone

There is no recovery for the credentials themselves. Workflows are a different matter: with the wrong key in place, n8n export:workflow --all still reported Successfully exported 2 workflows. on our instance. Export them, start a clean instance (new folder, new database), import the workflows, then recreate each credential and reselect it in the nodes that use it. Imported workflows keep their credential references by ID and name, so the nodes point at credentials that no longer exist until you do.

To avoid a repeat, pin the key: set N8N_ENCRYPTION_KEY explicitly in your Compose or secret store, so the key no longer depends on one file in one volume. The n8n docs add that in queue mode every worker needs the same variable. Changing the key on a running instance is a separate, documented operation (N8N_ENV_FEAT_ENCRYPTION_KEY_ROTATION, set on all main and worker instances). Simply editing the value reproduces the errors above.

Related failures on a self-hosted instance

If n8n will not start because it cannot write that same config file, you have a permission problem (EACCES), not a key problem. If it starts but webhook URLs point at localhost, see why n8n shows a localhost webhook URL. For the full install, the self-hosted n8n guide covers the volume and environment variables around this one.

Sources and last verified

Reproduced on n8n 2.41.3 on 30 September 2026; every doc quote was read on the same day. If n8n’s docs and this page disagree, n8n wins. Write to support@flowtemplates.app and we will re-verify.

• n8n Docs — Set a custom encryption key — checked 2026-09-30
• n8n Docs — Deployment environment variables (N8N_ENCRYPTION_KEY, N8N_ENV_FEAT_ENCRYPTION_KEY_ROTATION) — checked 2026-09-30
• n8n Docs — Docker installation (why /home/node/.n8n must be a persistent volume) — checked 2026-09-30
• n8n source — deployment-key.repository.ts (the “cannot be read with this instance encryption key” check) — checked 2026-09-30