External Secrets in n8n: connecting Vault, AWS Secrets Manager and Azure Key Vault

An OpenAI API key, a Stripe token, a database password: our guide on securing n8n credentials explains how n8n encrypts them by default with the instance's N8N_ENCRYPTION_KEY, and why that system is enough for most teams. But once an organization runs several n8n instances (dev, staging, prod, or several clients at an agency), the question changes shape: the "source of truth" secret already lives somewhere else — an enterprise vault with its own rotation policy, its own access logs, its own compliance audit trail — and copying it credential by credential into every n8n instance quickly becomes the one link nobody remembers to rotate. That's exactly the problem External Secrets solves: wiring n8n directly to that external vault, without ever storing the secret's actual value inside n8n itself.

This isn't a theoretical precaution. A study by Meli, McNiece and Reaves presented at the NDSS Symposium in 2019 scanned hundreds of thousands of public GitHub repositories and found hundreds of thousands of valid secrets in them — API keys, database credentials, cloud tokens — committed in plain text, often because a developer in a hurry had pasted them straight into a config file instead of referencing them from a centralized system (Meli, McNiece & Reaves, How Bad Can It Git?, NDSS 2019). The risk with multiple n8n instances is the same failure mode at a smaller scale: every manual copy of an API key into a new credential is one more chance to leave it sitting in a shared JSON export, a support screenshot, or a poorly protected backup.

What External Secrets does — and who it's for

External Secrets is an Enterprise feature, on both n8n Cloud and self-hosted: it doesn't exist on the free Community edition. Once enabled, it lets you declare one or more external "vaults" in Settings, then reference their secrets from any n8n credential field without ever typing the actual value into the interface. n8n only reads these secrets on a regular schedule; it never writes to or modifies them on the provider's side.

Supported providers today are AWS Secrets Manager, Azure Key Vault, GCP Secrets Manager, HashiCorp Vault (self-hosted, Community or Enterprise — not the HCP Vault Secrets SaaS offering, despite the similar name), Infisical, and 1Password via a self-hosted 1Password Connect Server (a machine-access API, not your personal 1Password vault).

Setting up a vault

All configuration happens in the UI, under Settings > External Secrets > Add secrets vault — there's no environment-variable equivalent for declaring a vault itself. For HashiCorp Vault, for instance, n8n asks for:

• the Vault server's URL;
• the authentication method: Token, AppRole, or Userpass;
• an optional namespace (relevant for a multi-tenant Vault Enterprise setup);
• a manually entered KV mount path, useful when the supplied token lacks the sys/mounts permission n8n needs to auto-detect it.

Once a vault is added and validated, n8n lists the secrets it finds there — never showing their plaintext value in the interface, only their names.

Using a secret inside a credential

A secret isn't usable just anywhere: only in an n8n credential field, switched to expression mode, with the syntax {{ $secrets.<vault-name>.<secret-name> }}. For a plain API Key credential, that looks like {{ $secrets.vault-prod.stripe-secret-key }} in the field that would normally hold the Stripe key in plain text. For 1Password, the syntax adds one more level — item, then field — as {{ $secrets.<vault>.<item-title>.<field-label> }}.

This is a structural limit worth knowing before building on top of it: the syntax only works inside credential fields. It silently fails (or simply doesn't resolve) inside a Code node, a Set field, or any standard node parameter. To move an external value elsewhere in a workflow's logic, you need a dedicated credential attached to a node that can consume it — typically HTTP Request with generic authentication (Header Auth, Query Auth) pointing at that credential.

Refresh, permissions, and multi-project setups

n8n doesn't re-query the external provider on every workflow run: it polls each vault on a regular interval, 300 seconds by default, adjustable via the N8N_EXTERNAL_SECRETS_UPDATE_INTERVAL environment variable (see our guide on n8n environment variables for the rest of that family of settings). That cache has a direct operational consequence: after an emergency rotation on the provider's side, the old value stays usable in n8n until the next cycle, unless the affected vault is manually resynced from Settings. Worth baking into any compromised-key revocation runbook rather than discovering it the day it matters.

Access to vaults is governed by a dedicated role ("sync vaults" under Settings > Roles), separate from regular workflow permissions. Recent versions add the ability to declare several vaults for the same provider (useful for keeping several clients' secrets apart on a single instance — a scenario our guide on hosting n8n for multiple clients covers directly), plus vaults scoped to a single n8n project rather than the whole instance, with read or admin access restricted to the relevant project roles — an addition aimed squarely at organizations that already split environments or clients by project.

What External Secrets doesn't replace

Two mix-ups come up often:

• It's not a substitute for N8N_ENCRYPTION_KEY: that key still encrypts n8n's own credentials, including those referencing an external secret. Losing it remains just as disruptive as before, as detailed in our guide on n8n credentials.
• It's not an injection mechanism for the body of a workflow: only plain strings are supported (no structured JSON object), and only inside a credential field. A need to reach a complex configuration stored in a secrets manager calls for a direct HTTP call to the provider's API, not External Secrets.

Do you actually need this?

For a single n8n instance run by a small team, n8n's native encrypted credential system — used properly, with per-team permissions and a documented manual rotation process — covers the essentials without justifying an Enterprise license or the overhead of running a Vault or an AWS Secrets Manager account on top. External Secrets earns its place in two concrete situations: an organization that already runs an automated rotation policy across its whole infrastructure and just wants to plug one more system into it, or an agency hosting several clients on separate n8n instances that wants to centralize secret management instead of manually duplicating it for every new client — a context that lines up directly with what our Compliance & Audit Pack (€149) is built for, aimed at teams that already need to document who has access to what and why. If your stack also runs AI automations under the same traceability requirements, the Complete FlowKit Bundle (€269) brings that pack together with the other two on the same baseline.