n8n external secrets with Vault and cloud secret managers

The external secrets capability is tied to the Enterprise plan, and n8n prices Enterprise on request, so the budget line cannot be read from the public pricing page. The most visible public figure is the Business plan at 667 euros per month billed annually. n8n's pricing page lists that plan as currently self-hosted only, which suits a team running its own instance, but Business is the wrong reference point if the external secrets entitlement is part of the design. Treat the Enterprise quote as the number that matters for this topic and use Business only as a floor for comparison.

The plan decision should be made once, for every feature that depends on it. According to n8n's pricing page, SSO and LDAP, environments with Git, and log streaming are included only in the Business and Enterprise plans. SAML single sign-on is documented for those plans, so a team that needs SSO, separate Git-backed environments and external secrets is not making three small decisions. Write down every feature the platform must support in the first year, then compare one Enterprise quote with a Business plan plus any separate tooling you would need for the features Business does not cover. Enterprise also adds dedicated support with an SLA, which matters if the instance is critical to production workflows.

Ask n8n for the external secrets entitlement in writing before design starts. The confirmation should name the secret providers you plan to use, such as HashiCorp Vault, AWS, Azure, GCP, Infisical or 1Password, and state whether they are all covered under the same entitlement. Ask whether the entitlement applies to self-hosted deployments, to queue mode workers and webhook processors, and to the n8n version you intend to run. Also confirm the license term, how renewals are priced, whether the support level and SLA are included, and whether multi-main high availability is part of the same agreement, since the queue mode documentation restricts multi-main to Enterprise self-hosted deployments.

Separate the n8n license from the secrets platform cost. The n8n subscription is a recurring cost tied to the plan. The secret manager is a different line: Vault Enterprise needs its own license applied to the cluster, HCP Vault Dedicated is a managed service, and HashiCorp's pricing pages direct self-managed Enterprise buyers to sales rather than publishing Vault Enterprise prices. Cloud secret managers bill differently again. Add the one-time costs of implementation, network paths from each worker to the provider, and testing of credential rotation and outage behavior. Ask each vendor for a written quote that states what recurs annually and what scales with usage.

If the entitlement cannot be confirmed in writing, do not start the design on the assumption that it will be granted later. Design a fallback that keeps credentials in the n8n database under the encryption key, and record the decision so the team can see which parts of the architecture depend on the Enterprise plan. This protects the budget from a late redesign and gives procurement a clear basis for comparing the Enterprise quote against the alternatives.

In queue mode, the design question for external secrets is not only where credentials live but which processes must be able to resolve them. The n8n main instance receives triggers and webhooks and hands executions through Redis to a pool of workers. Those workers read and write workflow data in PostgreSQL. Credentials stored in the database are encrypted with the main instance's encryption key, and n8n's queue mode documentation says that key must be shared with all worker and webhook processor nodes so they can access those credentials. Moving secrets out of the database to Vault or a cloud secret manager changes what sits in PostgreSQL, but it does not remove the need for every node that runs executions to hold the key. Plan for that key distribution explicitly before you wire anything else.

Your first task is to confirm, for the n8n version you intend to run, how each process role resolves an external secret value at execution time. Check whether the main instance, workers and webhook processors each fetch the value from the provider on demand, and whether any role caches it. The answer determines which roles need network reachability to Vault or the cloud API, and which need only Redis and PostgreSQL. Write this down per role. Webhook processors are easy to overlook because they handle inbound traffic, yet any workflow they start may reference an external secret. Do not assume the workers inherit the main instance's access to the secret store.

Next, map identities to roles. Each process that resolves a secret needs its own identity with the narrowest policy that allows reading the specific paths it uses. In Vault, that usually means separate AppRole, Kubernetes auth or cloud IAM roles for the main, worker and webhook tiers, rather than one shared token copied to every container. Confirm the network paths too: worker subnets may sit in a different zone from the main instance, and egress rules, proxies and private endpoints for the secret manager often differ by tier. Ask your platform team to test each role's path to the provider separately, because a workflow that works on the main instance can fail on a worker with a permission or routing error that appears only under load.

Rotation needs its own plan. There are two kinds of change to consider: rotating the n8n encryption key, which affects every process that reads stored credentials, and rotating a secret held in the external store, which affects only the workflows that resolve it at run time. Confirm with n8n's documentation for your version whether a changed encryption key requires restarting all workers and webhook processors together, and what happens to executions in flight. For external secret values, confirm whether workers pick up a new value on the next resolution or only after a restart. Schedule rotations in a maintenance window, test them in a staging queue-mode setup that mirrors your production node count, and record the expected order of changes.

Finally, treat the worker pool as a larger part of your secret attack surface than a single-instance deployment suggests. Every additional worker holds the encryption key and a provider identity, so scaling out increases the places a leaked credential could be used. Ask whether the key can be injected from a protected store at startup rather than written into images or configuration files, and whether provider identities can be limited to the paths each worker role needs. Include worker replacement, scaling events and node decommissioning in your runbook. Request the exact configuration for your n8n version and your secret provider in writing as part of the design scope, because the details of key sharing and secret resolution determine both your security posture and your operating effort.

The first control to settle is the identity n8n uses to read secrets, because that identity defines what a compromised n8n instance can reach. Give n8n its own Vault auth method, such as AppRole or Kubernetes auth, as your n8n release supports it, and bind that method to a policy that grants read access only to the paths n8n references. Root tokens and shared operator tokens should not appear anywhere in the n8n configuration. For AWS Secrets Manager, Azure Key Vault and GCP Secret Manager, use the workload identity of the n8n host or container, with resource-level policies that name each secret. Confirm which provider versions your n8n release supports and how it handles token renewal. Vault namespaces, which separate teams inside one cluster, are an Enterprise feature that requires a license applied to the cluster.

Network restrictions come next. Limit outbound traffic from n8n to the store's listener address and port, enforce the rule with security groups, host firewalls or network policies, and deny everything else. Include worker and webhook processor nodes in the rule set, since in queue mode they also need to resolve credentials, which widens the number of hosts that can reach the store. Require TLS on the Vault listener and install the internal certificate authority on each n8n host or container so verification succeeds without being disabled. For cloud managers, prefer private endpoints so secret traffic stays off the public internet, and confirm that your n8n version can use them. Keep Vault's cluster and management interfaces on a network segment separate from the n8n subnet.

Audit logging must exist on both sides, and the two logs should be correlated. On the Vault side, enable at least one audit device, send its output to a location n8n administrators cannot edit, and record which auth role read which path and when. On AWS, Azure and GCP, use CloudTrail, Azure diagnostic logs and Cloud Audit Logs, and confirm that data access logging is enabled for the secret service, because some of these logs are not enabled by default. On the n8n side, the Enterprise plan provides audit events for credential changes, and the log streaming topic covers forwarding them to a SIEM. Agree on a common time source and a stable identifier for each n8n instance so an investigator can connect a credential change in n8n to the store read that followed it.

Rotation covers two sets of material. The first is the credential n8n uses to reach the store, such as AppRole secret IDs, cloud access keys or service account keys. Prefer workload identities so that no static key exists, and where a static credential is unavoidable, set a rotation schedule that your change process can execute without an outage. The second is the n8n encryption key, which protects credentials stored in n8n's database. Rotating it means updating every main, worker and webhook processor node together, because queue mode requires all of them to share the key. Rehearse that change in staging, document the procedure, and confirm in n8n's documentation for your version how existing data is handled when the key changes. Store the key in a secret manager or a protected file with restricted read access.

Plan for a store outage before one happens. Confirm in your n8n version whether external secret values are cached and for how long, because that determines whether running workflows keep working. In general, an execution that has already loaded its credentials may finish, while new executions that need a secret from an unreachable store will fail. Test this by stopping the store in staging and observing both scheduled and webhook-triggered workflows. For the store itself, back up Vault's integrated Raft storage on a schedule, keep unseal or recovery keys in separate custody, and rehearse a restore into an isolated cluster. HashiCorp recommends integrated storage for most deployments. Cloud managers depend on provider durability, so confirm versioning, deletion recovery windows and any cross-region replication you need. Vault Enterprise disaster recovery replication also requires a license. DeployOpen can design these controls and prepare the configuration and evidence an assessment will ask for, but audit reports and certifications come from independent auditors and certification bodies.