The n8n encryption key: what it protects and how not to lose it

• Where the key comes from
• Set it explicitly
• Queue mode needs the same key everywhere
• Back it up separately
• Rotating the key
• Quick audit

Every credential saved in n8n, from API keys to database passwords, is encrypted in the database with a single key. If that key is lost, your workflows still exist but every credential is unreadable. It is the most important value in a self-hosted n8n setup, and it is easy to lose by accident.

§Where the key comes from

If you set N8N_ENCRYPTION_KEY as an environment variable, n8n uses it. If you do not, n8n generates a random key on first start and writes it to the settings file in its user folder, typically /home/node/.n8n/config inside the container.

That second case is where trouble starts. If /home/node/.n8n is not on a persistent volume, the key is regenerated whenever the container is recreated. The database still holds credentials encrypted with the old key, and n8n reports that credentials cannot be decrypted.

§Set it explicitly

Generate a key once and pass it in:

openssl rand -hex 32

services:
  n8n:
    image: docker.n8n.io/n8nio/n8n
    environment:
      N8N_ENCRYPTION_KEY: ${N8N_ENCRYPTION_KEY}
      DB_TYPE: postgresdb

If you already have a running instance with a generated key, read the existing value from the config file and set that same value as the variable. Do not generate a new one.

§Queue mode needs the same key everywhere

In queue mode, the main instance and every worker decrypt credentials. All of them must receive the identical key. A worker with a different key fails every execution that uses credentials, with errors that look unrelated at first.

§Back it up separately

Store the key in a password manager or secret store, separately from database backups. A database backup without the key restores workflows but not credentials. Test a restore on a scratch server at least once: start n8n with the backup and the key, open a credential and check that it loads.

§Rotating the key

n8n does not rotate the key for you. The safe route is to export credentials decrypted with the CLI (n8n export:credentials --decrypted), start with the new key and import them again. The decrypted export contains every secret in plain text, so do it on the server, delete the file afterwards and never commit it.

§Quick audit

• Is N8N_ENCRYPTION_KEY set explicitly?
• Is the n8n user folder on a volume anyway?
• Do all workers use the same key?
• Is the key stored somewhere other than the server?

For the rest of the setup, including Postgres, webhooks and updates, see this guide to self-hosting n8n.

Disclosure: I help build Peon.