The n8n encryption key is the single piece of your n8n install that has no backup, no reset and no support path. Lose it and your credentials are still there, still encrypted, permanently unreadable.
It is also almost invisible. n8n generates one silently on first startup, writes it to a file nobody opens, and never mentions it again until the day you restore a database on a new machine and every credential fails at once.
What Is the n8n Encryption Key?
It is the secret n8n uses to encrypt credentials before storing them. Per n8n’s docs, it “uses that key to encrypt the credentials before they get saved to the database”. Every API key, password and OAuth token goes in encrypted with it. Workflows are not encrypted - only credentials. Without the key, those credential rows are ciphertext and nothing else.
This matters because it splits your n8n data into two categories that need completely different handling:
- Workflows - plain JSON in the database. Portable, diffable, easy to back up, no secret required.
- Credentials - encrypted blobs. Useless without the key, no matter how good your database backup is.
Most people back up the database and believe they are covered. They are covered for half of it.
Where Is the n8n Encryption Key Stored?
In n8n’s settings file at ~/.n8n/config, as a JSON field called encryptionKey. n8n’s docs say it “creates a random encryption key automatically on the first launch and saves it in the ~/.n8n folder”. The docs never name the file - config and encryptionKey come from n8n’s source, where the settings file path and the JSON shape are both defined. On Docker the same folder is /home/node/.n8n.
To read it:
cat ~/.n8n/configYou get something like:
{
"encryptionKey": "aB3dEf...",
"instanceId": "..."
}On an InstaPods n8n pod the path is /home/instapod/.n8n/config, and you can reach it from the web terminal or over SSH:
cat /home/instapod/.n8n/configIf you are running n8n in a container elsewhere, exec into it first - the file lives inside the container’s filesystem, which is exactly why ephemeral containers lose it.
The environment variable and the file must agree
If N8N_ENCRYPTION_KEY is set, n8n compares it against the settings file. If they disagree, n8n refuses to start, with an error naming both: “Mismatching encryption keys. The encryption key in the settings file does not match the N8N_ENCRYPTION_KEY env var. Please make sure both keys match.”
That refusal is a feature. n8n would rather not boot than boot with a key that cannot read your credentials. If you see it, do not delete the settings file to make the error go away - find out which of the two values is the original.
Where it gets dangerous is when there is no settings file to disagree with. A container whose ~/.n8n is not on a persistent volume starts clean every time, n8n generates a brand new key, no mismatch is detected, and every credential in your database silently fails to decrypt.
What Happens If I Lose the n8n Encryption Key?
n8n’s docs answer this in one sentence: “Losing it means all stored credentials in your workflows become permanently unreadable.” The data is not deleted - it is unreadable, which looks the same from your side and is worse to explain. There is no recovery. You delete each credential and re-enter it, which for OAuth means redoing the consent flow with every provider.
The realistic damage is not the typing. It is:
- Every OAuth integration (Google, Microsoft, Slack, HubSpot) needs its consent flow re-run, sometimes by whoever owns the account rather than by you.
- Any API key you did not store elsewhere has to be regenerated at the provider, which may invalidate it in other systems that were using the same key.
- Workflows keep running on schedule while their credentials are broken, so you get a burst of auth failures rather than a clean stop.
If you are here because it already happened: there is no decryption trick. Export your workflows (those are fine), delete the broken credentials, and re-create them. That is the whole procedure.
How Do I Back Up the n8n Encryption Key?
Copy the value out of ~/.n8n/config into whatever holds your other secrets - a password manager, a secrets store, a sealed env file. Store it separately from the database backup, because a backup containing both is a single file that decrypts all your credentials.
Two defensible patterns, pick one:
- Key in a password manager, database backed up normally. The backup is safe to store anywhere; the key is the thing you protect. This is the right default. If you would rather that vault ran on your own server than someone else’s, we ranked the best self-hosted password managers on client apps and server footprint.
- Key travelling inside the archive. A
tarof the whole~/.n8nfolder contains bothdatabase.sqliteandconfig, so a restore just works. Simple and complete - and now the archive is as sensitive as your credentials, so encrypt it at rest.
There is no version where the backup restores credentials by itself and is not secret-bearing. Decide which risk you would rather manage.
InstaPods takes the second shape: the backed-up path is the whole n8n data directory, so config and database.sqlite are captured and restored together and credentials decrypt after a restore. The full picture is in how to back up n8n workflows and credentials.
Can I Change the n8n Encryption Key?
Not in place. n8n does not re-encrypt existing credentials, and it will not even start if the env var and the settings file disagree. The route that works is: export decrypted with the old key, change the key, re-import.
# 1. Export credentials in plaintext, using the CURRENT key
n8n export:credentials --all --decrypted --output=creds.json
# 2. Set the new key (env var, or edit ~/.n8n/config), restart n8n
# 3. Re-import - they are re-encrypted with the new key
n8n import:credentials --input=creds.json
# 4. Shred the plaintext file
rm -P creds.jsonBetween steps 1 and 4 you have a file containing every secret in your n8n instance in plaintext. Do that on the server, not on your laptop, and do not let it touch git or a shared folder.
When Do I Need to Set N8N_ENCRYPTION_KEY Explicitly?
Whenever the key cannot be trusted to persist on its own, or when more than one process needs the same one. A single long-lived instance with a real disk does not need it. Containers with ephemeral filesystems, multi-instance setups sharing a database, and restores from another host all do.
The four cases:
| Situation | Set it explicitly? | Why |
|---|---|---|
| One instance, persistent disk | No | n8n generates and keeps it |
Container with no persistent volume on ~/.n8n | Yes | A new key is generated on every restart, breaking every credential |
| Multiple instances or queue-mode workers sharing a database | Yes | They all must decrypt the same credentials |
| Restoring a database from a different host | Yes | Set it to the OLD host’s key, or the restored credentials do not decrypt |
The third row is the one that surprises people who move to queue mode: workers are separate n8n processes, and a worker with a different key cannot run a node that needs a credential.
The fourth is the classic migration failure. Our n8n migration guide covers it in the context of a full move. Moving to a different product is the harsher version of the same problem, because credentials do not cross product boundaries at all: whichever of the n8n alternatives you land on, every API key gets re-entered by hand.
How This Works on InstaPods
n8n on InstaPods runs from a persistent data directory at /home/instapod/.n8n, so the key n8n generates on first boot stays put across restarts and updates. It is included in the daily backup because the whole directory is the backup path, and you can read it from the web terminal any time.
Concretely, for an n8n pod on the $7/mo Build plan:
- The key lives in
/home/instapod/.n8n/configon real disk, not in a layer that gets discarded. - It is inside every daily backup, alongside the database it decrypts, so a restore is not a credential re-entry exercise.
- App updates snapshot the pod first and refuse to run if they cannot create that rollback point, so a failed update rolls back rather than leaving you with a database and no key.
- You still own the copy in your password manager. We are a host, not a key escrow, and if you ever move off the platform you want that value in your hands.
What we do not do: manage secrets inside your workflows. If the same Stripe key is pasted into four n8n credentials and two environment variables, that is credential sprawl and it lives in your n8n instance, not in the hosting layer. No host fixes it.
What About Key Rotation?
Recent n8n versions add an opt-in two-layer scheme behind N8N_ENV_FEAT_ENCRYPTION_KEY_ROTATION, where rotatable data-encryption keys sit under the instance key. It is a one-way door and you should read the docs before enabling it.
Two lines from n8n’s own page are the whole decision. First, on the master key: “Instance encryption key (N8N_ENCRYPTION_KEY): your master key, set at deployment time. This key never changes.” Second, on turning the feature off: “Removing N8N_ENV_FEAT_ENCRYPTION_KEY_ROTATION or setting it to false makes all data encrypted after you enabled the feature permanently inaccessible.”
So it does not save you from losing N8N_ENCRYPTION_KEY, and disabling it after the fact is destructive. n8n’s own guidance on the page is to take a full database backup before enabling it. Do that.
FAQ
How do I generate an n8n encryption key?
Any long random string works. openssl rand -base64 24 matches what n8n generates for itself - 24 random bytes, base64-encoded - and openssl rand -hex 32 is equally fine. n8n generates one on first startup, so make your own only when you are setting N8N_ENCRYPTION_KEY deliberately.
Is the n8n encryption key the same as an API key? No. The n8n API key authenticates calls to n8n’s own REST API. The encryption key protects the credentials stored inside n8n. Different things, different places, and losing them has completely different consequences.
Does n8n Cloud have an encryption key I need to manage? No. Key management is n8n’s job on Cloud. This is a self-hosting concern, which is the trade you make for running it yourself.
Why did my credentials break after a redeploy?
Almost always because the key changed. Either the container’s ~/.n8n was not on a persistent volume so a fresh key was generated, or N8N_ENCRYPTION_KEY was set, unset or changed between deploys. Check the environment before you assume the database is damaged.
Can I recover credentials without the key? No. That is what encryption is for.
Want n8n on a disk that keeps your key and a backup that carries it? Deploy n8n on InstaPods - $7/mo, 2 vCPU, 2 GB RAM, daily backups of the full data directory. Or compare eight n8n hosts, including doing it yourself on a VPS.