Securing n8n credentials: best practices for managing API keys

Credentials are the most sensitive part of an n8n workflow: an OpenAI API key, a Stripe token, a database password — anything that grants access to an external system passes through them. n8n encrypts them properly by default, but "encrypted by default" doesn't mean "safe to ignore." Here's how to manage credentials seriously, from baseline encryption to rotating keys in production.

How n8n encrypts your credentials

Every credential saved in n8n is encrypted at rest with AES, using a key unique to your instance: the N8N_ENCRYPTION_KEY. It's generated automatically on first startup if you don't set it yourself, and stored locally (in ~/.n8n/config on a typical self-hosted setup). That key — and only that key — is what lets n8n decrypt your credentials to run a workflow.

In practice, that means n8n's database (Postgres or SQLite depending on your install) never holds your API keys in plain text, even if someone gets direct access to it. That's good news for data-at-rest security, but it also creates a single point of failure that deserves to be taken seriously.

Never lose your encryption key

This is self-hosted mistake number one: the N8N_ENCRYPTION_KEY isn't backed up anywhere by default outside the instance itself. Lose the server, the Docker volume, or simply the config file without having copied it elsewhere, and every existing credential becomes permanently unreadable — not "hard to recover," unreadable, full stop. You'd then have to recreate every credential by hand in every workflow that uses it.

The fix is simple and belongs on your production checklist:

• Set the value yourself instead of letting n8n generate it, via the N8N_ENCRYPTION_KEY environment variable defined before the first startup.
• Back it up separately from the n8n database: a team password manager, a secrets vault — never a text file sitting in the same folder as everything else.
• Include it in your disaster recovery procedure, alongside the workflow backups described in our guide on versioning n8n workflows with Git — a workflow export without its matching encryption key won't restore the credentials that go with it.

Credentials in the UI vs. environment variables

n8n gives you two ways to feed a secret to a workflow, and they don't serve the same purpose.

Credentials stored in the UI are the default option, and the right one for the vast majority of cases: an OpenAI API key, a Slack token, database login details. They're encrypted with the N8N_ENCRYPTION_KEY, reusable across multiple workflows, and — crucially — governed by n8n's permission system, so you can share them with a team without exposing the actual value.

Environment variables (accessible via $env in expressions and Code nodes) fit better for instance-wide secrets: the encryption key itself, access credentials for an external secrets manager, configuration that never changes and applies to the whole installation rather than to one specific business workflow. They don't get the same granular sharing model as UI credentials, so reserving them for genuine infrastructure secrets keeps you from losing track of who can see what.

Who can see what: permissions and team sharing

On n8n Cloud (Team plan and above) and on self-hosted n8n Enterprise, credentials are organized into projects: each credential belongs to a project, and only members with access to that project can use it inside a workflow. A credential can also be shared individually with a specific user or role, without granting access to the whole project.

The principle to apply is the same as with any privileged access: least privilege. A freelancer building a scraping workflow doesn't need to see the production Stripe credential. On Community edition instances (no projects), that granularity doesn't exist — every user with instance access can potentially use every credential, which is a strong argument for moving to Enterprise or Cloud Team as soon as more than two or three people share the same instance.

Rotating an API key without breaking production

Regular API key rotation is basic hygiene that gets pushed off constantly — "what if it breaks a production workflow?" With n8n, the move is actually simple, because the credential is an object independent of the workflow itself:

1. Generate the new key with the provider (OpenAI, Stripe, etc.) without revoking the old one right away.
2. Open the existing credential in n8n and swap the value — every node that references this credential switches over automatically, without touching a single workflow.
3. Run a test execution on a representative workflow to confirm the new key works.
4. Revoke the old key on the provider's side once the switch is confirmed.

The key point: you never edit the workflows themselves, only the credential's contents. That's exactly why you should never duplicate an API key hardcoded across multiple nodes — rotation then turns into a treasure hunt across every workflow instead of a single edit in one place.

Avoiding leaks: the Code node trap

The sneakiest risk isn't a stolen credential — it's an accidental leak. An API key pasted directly into a Code node instead of being referenced via $credentials, or an expression like {{ $json.apiKey }} that surfaces the plain-text value in the execution panel — both can end up visible in execution logs, in a JSON export shared with a colleague, or in a screenshot sent for support.

The phenomenon is massive and well documented: a study by Meli, McNiece, and Reaves, presented at the NDSS Symposium in 2019, scanned billions of public files on GitHub and found hundreds of thousands of repositories containing secrets leaked by mistake (API keys, tokens, database credentials), with several thousand new secrets leaking every single day (Meli, McNiece & Reaves, 2019, NDSS Symposium). An n8n workflow export shared carelessly, or accidentally pushed to a public Git repository, reproduces exactly that scenario at the scale of a single company.

A few simple habits prevent most leaks:

• Always reference a secret through a node's dedicated credential (HTTP Request, Postgres, Slack, etc.), never as a hardcoded value in a Set or Code node.
• If a Code node genuinely needs a secret, read it from $env (an environment variable) rather than pasting it into the script.
• Before sharing a workflow export or a screenshot, check that no credential value shows up in visible fields or displayed execution data.
• Treat every inbound webhook with the same rigor described in our guide on securing a public n8n webhook: a well-protected credential is worthless if access to the workflow itself is wide open.

Auditing which credentials each workflow uses

Before a production launch or a security audit, it's worth knowing exactly which workflow uses which credential — and, more importantly, which credentials nobody uses anymore. n8n lists credentials by type and name in its interface, but doesn't natively provide a cross-reference view mapping "credential → workflows that use it." On self-hosted instances with database access, a query against the credentials_entity table cross-referenced with the nodes in your exported workflows lets you rebuild that map.

This kind of audit follows the same logic as the GDPR audit trail with n8n and Supabase: knowing who has access to what, and being able to prove it, is part of the baseline expectation as soon as a workflow touches sensitive data or payment systems.

Self-hosted: environment variables and an external secrets manager

Self-hosted, you get a layer of control that n8n Cloud doesn't offer: direct server access. That makes it possible to harden secret management further:

• Isolate sensitive environment variables in a .env file that's never committed to your infrastructure config repository.
• Encrypt the disk volume hosting the n8n database, on top of the application-level encryption already provided by N8N_ENCRYPTION_KEY.
• Wire in an external secrets manager (HashiCorp Vault, AWS Secrets Manager) for organizations that already run automated rotation policies across their whole infrastructure — n8n can then fetch certain values through API calls in a Code or HTTP Request node at workflow startup, instead of storing them locally. That's added complexity worth considering only if it already exists elsewhere in your stack.

This is the same trade-off between simplicity and control we cover in our comparison, n8n self-hosted vs cloud: more control, but also more operational responsibility for secret security.

Wrapping up

n8n credential security comes down to a short list of rules, but they don't forgive being ignored: back up the N8N_ENCRYPTION_KEY separately, reserve environment variables for infrastructure secrets, scope access by project, rotate API keys through the credential rather than hardcoding them in nodes, and audit regularly who's using what. If you're starting from a fresh instance, the lowest-friction path is the earliest one: building these habits in from the first credential you create costs a few minutes; fixing them after a leak costs a lot more.