n8n stores the API keys and passwords your workflows use as encrypted credentials, and the entire security of that store rests on one encryption key. Most n8n credential incidents trace back to mishandling that key — losing it, leaking it, or never rotating it. Get the key right and the rest follows.
The encryption key is everything
n8n encrypts credentials with the value in N8N_ENCRYPTION_KEY. If you do not set it, n8n generates one and writes it to disk on first run — fine until you move or rebuild the instance without that file, at which point every stored credential is unreadable. Always set the key explicitly via the environment, and treat it like the master secret it is: without it the credential store is garbage, and with it, it is fully decryptable.
# Set explicitly — never rely on the auto-generated on-disk key
export N8N_ENCRYPTION_KEY="$(cat /run/secrets/n8n_key)"
# Back it up separately from the database. Restoring the DB without
# this exact key leaves every credential undecryptable.Back up the key separately
The credentials live in the database; the key to read them lives in the environment. A database backup alone is useless for credentials without the matching key, and storing the key next to the backup defeats the point of encrypting. Back the key up in your secret manager, separate from the database dump, and document that a restore needs both.
Prefer external secrets
For sensitive deployments, do not treat n8n as the permanent home of your secrets. n8n (enterprise) integrates with external secret stores, and even on the community edition you can pass secrets in through environment variables referenced from expressions, so the source of truth stays in your vault. The less that lives only inside n8n's store, the smaller the blast radius if the instance is compromised.
Anyone who can edit a workflow can use its credentials, and on shared instances that can leak access broadly. Use n8n's user management and project/role scoping to limit who can see and attach which credentials, and give integration users least-privilege API keys — a workflow that only reads should not hold a write-capable key.
n8n credential management comes down to four disciplines: set and protect the encryption key explicitly, back it up apart from the database, keep the real source of secrets in an external vault where you can, and scope who can use each credential. The key is the crown jewel — guard it and the encrypted store takes care of itself.
Independent software engineer in Nairobi specialising in Acumatica customisations, Laravel backends, and tax fiscalisation integrations across East and Southern Africa.