N8N Credentials: A Complete Guide to Secure Storage & Setup
Every workflow automation platform needs a way to store secrets safely, and n8n credentials are the mechanism n8n uses to keep API keys, OAuth tokens, and database passwords out of your workflow JSON and out of plain sight. This guide walks through how n8n credentials work, how to create and manage them, and how to keep them secure in both cloud and self-hosted deployments.
If you’ve ever pasted an API key directly into an HTTP Request node and immediately regretted it, this article is for you. We’ll cover the credential model, encryption internals, node-level credential binding, sharing and permissions, and common failure modes you’ll hit when running n8n in production.
What Are N8N Credentials?
N8N credentials are encrypted, reusable objects that store authentication data — API keys, OAuth2 tokens, basic auth username/password pairs, database connection strings, and more — separately from the workflows that use them. Instead of hardcoding a Slack token into every node that posts a message, you create a single Slack credential once and reference it from any node that needs it.
This separation matters for a few reasons:
N8N ships with dozens of built-in credential types (Slack, Google Sheets, Postgres, generic HTTP Header Auth, OAuth2, etc.), and custom nodes can define their own credential schema when needed.
Creating and Managing N8N Credentials
Creating a Credential From the UI
The most common path is creating a credential directly from a node. When you drop an HTTP Request node or a Postgres node onto the canvas and select “Create New Credential,” n8n opens a form specific to that credential type. Fill in the required fields (API key, host, username/password, OAuth client ID/secret), give it a descriptive name, and save.
You can also manage credentials independently from the Credentials tab in the left sidebar, which lists every credential in your instance, its type, and when it was last updated. This is the better entry point when you’re pre-provisioning credentials before building workflows, since it lets you organize by naming convention (e.g. prod-postgres-readonly, stripe-live) before any workflow references them.
Credential Types You’ll Use Most
A few credential types cover the majority of real-world n8n workflows:
Editing and Rotating Credentials
When a key expires or you need to rotate a secret, open the credential from the Credentials list, update the relevant field, and save. N8n credentials updates apply immediately to every workflow referencing that credential — there’s no need to touch individual nodes or redeploy workflows. This is one of the strongest arguments for always using n8n credentials instead of hardcoding values in Set nodes or expressions, since rotation becomes a one-step operation instead of a search-and-replace across your workflow library.
How N8N Encrypts Credential Data
Understanding the encryption model behind n8n credentials is important if you’re running a self-hosted instance, because it directly affects your backup and disaster-recovery strategy.
The Encryption Key
N8n encrypts credential data at rest using a symmetric encryption key, controlled by the N8N_ENCRYPTION_KEY environment variable. If you don’t set this variable explicitly, n8n generates a random key on first startup and stores it in the local config file inside your n8n user data directory.
This has a critical operational implication: if you lose the encryption key, every stored credential becomes permanently unreadable. You cannot decrypt them without the original key, even if you still have full access to the underlying database. This is different from a typical “forgot password” scenario — there’s no key-recovery mechanism, because n8n was deliberately designed so that even the n8n team cannot access your stored secrets.
For any production deployment, explicitly set N8N_ENCRYPTION_KEY as an environment variable rather than letting n8n auto-generate one, and store that key in a secrets manager or password vault separate from your n8n database backups. A minimal Docker Compose snippet showing this looks like:
services:
n8n:
image: n8nio/n8n:latest
restart: unless-stopped
environment:
- N8N_ENCRYPTION_KEY=${N8N_ENCRYPTION_KEY}
- N8N_HOST=n8n.example.com
- N8N_PROTOCOL=https
- DB_TYPE=postgresdb
- DB_POSTGRESDB_HOST=postgres
- DB_POSTGRESDB_DATABASE=n8n
- DB_POSTGRESDB_USER=n8n
- DB_POSTGRESDB_PASSWORD=${POSTGRES_PASSWORD}
ports:
- "5678:5678"
volumes:
- n8n_data:/home/node/.n8n
depends_on:
- postgres
volumes:
n8n_data:If you’re pairing n8n with a Postgres backend rather than the default SQLite store, our Postgres Docker Compose setup guide walks through the database side of that configuration in detail.
Where the Encrypted Data Lives
With SQLite (the default), credentials are stored inside the database.sqlite file in the n8n data directory. With Postgres or MySQL, they live in the credentials_entity table. In both cases, the sensitive fields are encrypted blobs — inspecting the raw database row will not reveal the underlying secret without the matching N8N_ENCRYPTION_KEY.
Binding Credentials to Nodes
Node-Level Credential Selection
Most nodes that talk to an external service expose a “Credential to connect with” dropdown. Selecting an existing credential attaches it to that specific node instance — not the whole workflow. This means a single workflow can use different credentials for the same service type across different nodes (for example, posting to two different Slack workspaces from two Slack nodes in the same workflow).
Expressions and Credential References
N8n credentials cannot be referenced or read via workflow expressions — this is intentional. You can’t write {{$credentials.myApiKey}} inside a node parameter to pull a raw secret value into a text field, because that would defeat the purpose of encrypting them in the first place. Credentials can only be consumed through the credential-selector mechanism built into a node’s authentication logic.
If you need a secret value inside generic logic (say, to sign a payload manually in a Function node), the supported pattern is to use a Generic Credential Type bound to an HTTP Request node’s authentication, rather than trying to extract the raw value into a Code node. If your use case truly requires low-level secret access, environment variables passed into the n8n container (and read via $env in a Code node, if enabled) are the safer route than trying to work around the credential model.
Sharing and Access Control
Credential Sharing in Team Environments
In n8n’s team/enterprise features, credentials can be shared with specific users or roles without exposing the underlying secret value. A user granted “use” access on a credential can select it in a node dropdown and run workflows with it, but cannot view or export the raw API key or password. This separation of “can use” from “can view” is what makes n8n credentials suitable for teams where a junior developer might build workflows against a production database credential they should never actually see.
Owner-Only Fields
Even for the credential owner, certain sensitive fields (API secrets, OAuth client secrets) are write-only in the UI after initial creation — the form shows a masked placeholder instead of the real value on subsequent edits. This prevents accidental screen-sharing exposure and matches the general principle that secrets should be set once and rotated, not repeatedly re-read.
Common Issues and Troubleshooting
“Credentials Not Found” Errors
This typically happens after a workflow import when the target instance doesn’t have a matching credential ID. N8n credentials are referenced by internal ID in workflow JSON exports, not by name, so importing a workflow from one instance to another requires manually re-linking each node to a locally-created credential of the same type.
OAuth2 Redirect URI Mismatches
OAuth2-based n8n credentials (Google, Microsoft, etc.) require the redirect URI registered with the third-party provider to exactly match n8n’s callback URL, which depends on N8N_HOST and N8N_PROTOCOL being set correctly. A mismatched redirect URI is the single most common cause of failed OAuth2 credential setup on self-hosted instances behind a reverse proxy.
Encryption Key Mismatches After Migration
If you move your n8n instance to new infrastructure — a new VPS, a new container host, or a restored backup — and the N8N_ENCRYPTION_KEY environment variable isn’t carried over exactly, every credential will fail with a decryption error even though the database migrated successfully. Always back up N8N_ENCRYPTION_KEY alongside your database dumps, not as a separate afterthought.
If you’re running n8n on a fresh VPS and want a clean, repeatable setup from scratch, our n8n self-hosted Docker installation guide covers the full stack setup including reverse proxy and TLS, and our n8n automation guide covers general self-hosting patterns on a VPS.
Best Practices for N8N Credential Management
N8N_ENCRYPTION_KEY explicitly and store it in a password manager or secrets vault — never rely on auto-generation.stripe-prod, stripe-test) to avoid accidental cross-environment usage.For teams building more complex automation — say, chaining n8n credentials across multiple integrated services — it’s worth comparing platforms before committing. Our n8n vs Make comparison covers how the two platforms differ in credential and connection management specifically.
FAQ
Q: Can I export n8n credentials along with a workflow?
A: Workflow exports include a reference to the credential ID and type, but not the decrypted secret value. When importing into a new instance, you need to create or re-link the credential manually.
Q: What happens if I lose my N8N_ENCRYPTION_KEY?
A: Every stored credential becomes permanently unreadable. There is no recovery mechanism, so back up the key separately from (but alongside) your database backups.
Q: Can two different nodes in the same workflow use different credentials for the same service?
A: Yes. Credential binding happens per node, not per workflow, so you can mix credentials for the same service type within a single workflow.
Q: Is it safe to store database passwords as n8n credentials instead of environment variables?
A: Yes — that’s exactly what the credential system is designed for. Database credentials are encrypted at rest using the same mechanism as API keys, and referencing them through a node’s credential selector keeps the raw password out of workflow JSON.
Conclusion
N8n credentials exist to solve a problem every automation platform eventually faces: how do you let workflows authenticate against dozens of external services without scattering plaintext secrets across your workflow definitions? By encrypting secrets at rest, binding them to nodes rather than exposing them through expressions, and supporting granular sharing permissions, n8n credentials give you a secure, auditable, and rotation-friendly secret management layer built directly into the platform.
The operational discipline that matters most is protecting N8N_ENCRYPTION_KEY with the same rigor you’d apply to a root database password — because functionally, that’s exactly what it is. Combine that with sensible naming conventions and least-privilege sharing, and n8n credentials become a solid foundation for running automation at any scale. For further reading on the underlying encryption model and OAuth2 flow specifics, see the official n8n documentation and the OAuth 2.0 specification.
Leave a Reply