Secure credential and API key management in n8n: a production checklist

Separate three data classes. Credentials authenticate access, such as OAuth clients, passwords, and API keys. Configuration contains non-secret values such as base URLs, timeouts, and environment names. Business data is the information processed by a workflow. Combining them in one variable or JSON object makes authorization, rotation, and auditing harder.

Do not treat n8n Variables as a secret store merely because they are reusable. Never distribute API keys through chat, email, tickets, or runbooks. During onboarding, an authorized operator should enter the value directly into the approved store; workflow builders should select an already-authorized credential.

For a small team and low-risk integrations, n8n's built-in credential store can be a reasonable starting point if the instance, database, backups, and N8N_ENCRYPTION_KEY are properly protected. For self-hosting, provide a stable encryption key through the deployment platform's secret mechanism; every replica and worker must use the same key. Do not rely on a key that exists only in an ephemeral container, commit it to a manifest, or keep it beside the database backup. Losing the key may make encrypted credentials unusable.

For critical production, multiple teams, or audit requirements, prefer an external secret store supported by your n8n edition, such as AWS Secrets Manager, Azure Key Vault, Google Cloud Secret Manager, or HashiCorp Vault. Central storage separates secret administration from workflow editing and improves access auditing and controlled rotation. Confirm current edition availability before committing to the design.

1. Generate a strong N8N_ENCRYPTION_KEY with a cryptographically secure generator and supply it through Kubernetes Secret, Docker secret, or a secret manager. Prefer file mounting where supported to reduce environment-variable exposure.
2. Enforce TLS and restrict editor access with SSO/MFA, VPN, Zero Trust, or an appropriate allowlist.
3. Isolate the n8n database account and network, encrypt backups, and keep recovery material and the encryption key under separate controls.
4. Install community nodes only after reviewing source, permissions, maintenance history, and supply-chain risk.
5. Restrict Code nodes and arbitrary environment access for untrusted workflows.
6. Patch n8n, nodes, and images; scan for vulnerabilities and monitor security advisories.
7. Define execution-data retention and avoid retaining successful or failed payloads containing sensitive headers or bodies longer than necessary.

Maintain an inventory containing owner, target system, permission scope, environment, consuming workflows, creation date, and review date. Do not rotate mechanically when the provider already offers automatically renewed short-lived tokens; the objective is to limit useful exposure time and respond quickly to compromise.

A safe sequence is to create a new secret in parallel, update the credential or external-secret reference, validate it with a canary workflow, monitor authentication failures, and then revoke the old secret. If the provider cannot accept two secrets concurrently, plan a maintenance window and rollback. API-key rotation is not the same as changing N8N_ENCRYPTION_KEY: the latter protects all stored credentials and requires a tested migration and recovery plan.

Record who creates, changes, shares, or uses a credential; which workflow calls the service; the timestamp, outcome, and request ID. Never log tokens, Authorization headers, cookies, passwords, private keys, or unfiltered payloads. Configure redaction across n8n, proxies, APM, and alerting, then test it with synthetic secrets.

Alert on bursts of 401/403 responses, credential changes outside approved windows, unusual secret access, or keys used from unexpected locations. Run secret scanning against Git, CI/CD artifacts, workflow exports, tickets, and runbooks—not source code alone.

Revoke or disable the exposed credential immediately when risk warrants it; issue a replacement with narrower permissions; identify affected workflows and users; inspect provider-side audit logs; isolate the instance if compromise is suspected; and remove the secret from Git history, execution data, logs, shared backups, and documentation.

If N8N_ENCRYPTION_KEY may be compromised, assume every credential decryptable with that key is at risk. Rotating provider-side credentials is generally more important than changing only the encryption key. Preserve a timeline, scope, evidence, and remediation record, then add controls that block the same leak path.

Does n8n encrypt credentials in its database?

Yes. n8n uses an encryption key to protect stored credentials. You must still secure the instance, database, backups, and key.

Should API keys be environment variables?

Environment variables are preferable to hard-coding but may leak through configuration, process inspection, or observability tools. For critical production, prefer secret mounts, workload identity, or a secret manager with restricted read access.

Does a workflow export include credentials?

Do not use workflow exports to transport secret values. Credential references may be present, so review exports before sharing and never embed a key directly in a node.

Does every workflow need a separate credential?

Separate credentials when ownership, permission scope, or risk differs. Avoid one shared administrator account for every integration.

How often should an API key be rotated?

It depends on provider capabilities, risk, and compliance. Rotate immediately after suspected exposure, ownership changes, or permission changes; prefer short-lived credentials and automated rotation.