n8n Credentials Security

Every API key, OAuth token, and database password stored in n8n is encrypted before it touches the database. What almost nobody realizes until it is too late is that this protection depends entirely on a single encryption key, and losing that key means losing every credential it protected, permanently, not recoverably. This is one of the first things I check and lock down on any self-hosted n8n instance I take over from a client.

This post covers how n8n actually stores and protects credentials, why the encryption key is the single most important piece of security infrastructure on a self-hosted instance, and the practical steps that prevent both credential leaks and, just as importantly, permanent credential loss.

How n8n Stores Credentials

Credentials, API keys, OAuth tokens, database passwords, whatever a node needs to authenticate against an external service, are encrypted before being written to n8n's database. What lives in the database is ciphertext, not the raw secret. The key that does the actual encrypting and decrypting is the encryption key, and it lives separately from the database entirely, in a local settings file by default, or in an environment variable if you set one explicitly.

Encryption and Encryption Keys

On first launch, if you have not set a custom key, n8n generates a random encryption key automatically and saves it to a local settings file. This works fine until that file disappears, which happens more often than people expect: a Docker container gets rebuilt without the underlying volume properly persisted, a host migration does not carry the file across, or a fresh deployment simply starts from scratch. If the encryption key is lost while the database of encrypted credentials survives, every single credential in that database becomes permanently unreadable garbage. There is no recovery path. Every API key, OAuth connection, and stored password has to be re-entered manually from scratch.

The fix is straightforward and worth doing on day one of any real deployment: set a custom encryption key explicitly through the N8N_ENCRYPTION_KEY environment variable rather than relying on the auto-generated one sitting in a file that might not survive infrastructure changes, and back that key up in at least two separate, secure locations, a password manager and a cloud secrets manager, for instance, not just the one settings file on the server itself.

n8n also supports encryption key rotation on self-hosted instances, letting you generate a new active key without losing access to data encrypted under the previous one. Existing records stay readable under their original key and get silently re-encrypted to the new key the next time they are updated. This is a genuinely useful capability if a key has been exposed and needs to be retired, but it is a one-way change with no rollback path, so a full database backup before enabling it is not optional.

Environment Variables

Beyond the encryption key itself, avoid putting other secrets, API tokens for external services you are calling, webhook signing secrets, directly into workflow nodes where they end up saved as plain data inside the workflow JSON. Anything hardcoded into a node travels with that workflow every time it gets exported, shared, or backed up, which defeats the purpose of encrypting credentials properly through n8n's credential system in the first place. Use n8n's built-in credentials feature for anything genuinely sensitive rather than pasting secrets directly into node parameters or Code node scripts.

User Permissions

For any multi-user n8n instance, credential-level permissions control who can view, use, or edit a given credential independent of who can edit the workflows using it. This matters more as a team grows, since not everyone building or maintaining workflows needs, or should have, direct visibility into every credential's underlying secret value. Review who has access to which credentials periodically rather than assuming the original setup still reflects who should have access today.

Avoiding Secrets in Nodes

This is worth repeating on its own because it is the mistake I see most often on client instances: a Code node with an API key typed directly into the script, or an HTTP Request node with a token pasted straight into a header field instead of referenced through a proper credential. Both work functionally, and both mean that secret is now sitting in plain text inside the workflow's stored JSON, visible to anyone who can view or export that workflow, sidestepping the encryption n8n's credential system would otherwise provide.

Execution Data Exposure

Beyond the credentials themselves, execution data, the input and output of every node run, can incidentally capture sensitive information that passed through a workflow even if the credential used to fetch it was properly secured. If a workflow handles anything genuinely sensitive, personal data, payment details, health information, review what gets saved in execution history, covered in n8n Execution Data Cleanup, since a properly encrypted credential does not help if the sensitive data it retrieved is sitting readable in execution logs indefinitely.

Data Redaction

For nodes that handle particularly sensitive fields, check whether n8n's data redaction options for that credential or node type can mask the value in logs and execution data, reducing what is visible even to someone with legitimate access to view execution history. This is a secondary layer on top of proper credential storage, not a substitute for it, but worth checking for anything handling data you would not want visible in a casual look at execution history.

Production Security Checklist

Before treating a self-hosted n8n instance as production-ready: a custom encryption key is set explicitly, not left to the auto-generated default, that key is backed up in at least two secure, separate locations, no secrets are hardcoded into Code nodes or node parameters outside n8n's credential system, credential-level permissions reflect who actually needs access on a multi-user instance, and if you are running queue mode, covered in n8n Queue Mode, every worker has the identical encryption key set, since a mismatch there causes workers to fail decrypting credentials they need to run a workflow.

Getting credential storage, key management, and backup handled correctly from the start of a self-hosted n8n deployment is exactly the kind of infrastructure work I take on for clients. If you are not confident your current setup would survive a lost encryption key, book a free 30-minute call and bring your current deployment, and we will get it locked down properly.

Frequently Asked Questions

Are n8n credentials encrypted?

Yes. n8n encrypts credentials, API keys, OAuth tokens, and passwords before writing them to the database, using an encryption key that is stored separately from the database itself, either in a local settings file or an environment variable.

Where does n8n store API keys?

The encrypted credential values live in the database, but the key that decrypts them lives separately, in a local settings file by default or in the N8N_ENCRYPTION_KEY environment variable if you set one explicitly.

How do I secure n8n credentials?

Set a custom encryption key explicitly rather than relying on the auto-generated default, back that key up in at least two secure locations, and use n8n's credential system for every secret rather than hardcoding tokens directly into node parameters or Code nodes.

Should I put API keys in n8n environment variables?

The encryption key itself, yes, as an environment variable. Individual service API keys are better stored through n8n's built-in credentials system, which encrypts them, rather than as separate environment variables referenced manually in nodes.

Can n8n execution logs expose API keys?

The credential value itself, generally not, since it is used to authenticate a request rather than passed through as data. However, sensitive data retrieved using that credential can end up saved in execution history, which is a separate exposure worth managing through retention settings.

Does n8n support execution-data redaction?

Yes, for certain node types and credentials, n8n supports masking sensitive field values in logs and execution data, reducing what is visible in execution history even to someone with legitimate access to view it.

If you would rather have this locked down than lock it down yourself, I take on n8n self-hosted security and infrastructure work through Fiverr.