n8n-nodes-custom-credential-vault

Store unlimited secrets inside n8n's own encrypted database and resolve them at runtime for every node type — including Code nodes. No external vault server, no .env files, no plaintext on disk, and no engine restarts after install.

This is a community node for n8n. It is MIT-licensed and has zero runtime dependencies and no telemetry — read every line before you install it.

Why this exists

n8n credentials are encrypted at rest, but their decrypted values are deliberately not available inside Code nodes. The common workaround is to put secrets in environment variables — which means plaintext on disk and a full engine restart on every change.

This package closes that gap. Secrets are stored in a custom credential (encrypted by n8n with your instance's AES‑256 key) and exposed to any node — Code nodes included — through a small resolver node.

What's in the package

| Component | What it does | |---|---| | Credential Vault (credential type) | Holds up to 30 Name / Value secret pairs. Values are write‑only — masked after saving, never shown again, type over to rotate. | | Credential Vault Resolver (node) | Reads the vault, lets you tick exactly which keys a workflow needs (searchable list), and outputs each selected secret as its own field on the item (e.g. item.json.ANTHROPIC_API_KEY). |

Security model

• Encrypted at rest. Secrets are stored in n8n's credentials_entity table, encrypted with your N8N_ENCRYPTION_KEY (AES‑256) — the same protection as any built‑in credential. This package never writes secrets anywhere else.
• Write‑only entry. Value fields use n8n's password field type: masked after save, with no "reveal" control. A secret you can read back in the UI is a secret that can leak.
• Least exposure. An empty key selection resolves nothing. Each workflow must explicitly declare the keys it needs.
• No phone‑home. No network calls, no analytics, no external services.

What this does NOT do (read this)

A resolver node, by design, outputs the secret values so downstream nodes can use them. Those values are therefore visible in that node's output panel while you run the workflow, and are written to execution data unless you disable it. This is inherent to how n8n passes data between nodes — anyone who can edit a workflow that uses a secret can read that secret (they can add an HTTP node and send it anywhere). No community node can prevent that.

n8n's sensitiveOutputFields (which would redact output in the UI) was tested on n8n 2.13.3 and did not redact — so this package does not rely on it. The real, version‑independent control is:

Set saveDataSuccessExecution: 'none' (workflow Settings → "Save successful production executions" → Do not save) on every workflow that consumes the vault, so resolved values are never persisted to the execution database. Combined with write‑only encrypted storage, this is the honest security posture: secrets are protected at rest and in logs, and exposure is limited to users who already have edit access to the consuming workflow.

Why 30 fixed slots (and not an "add row" button)

n8n credential modals cannot render a dynamic fixedCollection (add‑more) control — this is a known, still‑open limitation (n8n#6693). The supported approach is plain fields, so the vault uses a fixed list of 30 Name/Value pairs. Empty slots are ignored. Need more than 30 secrets? Create additional vault credentials.

Install

Via the n8n GUI (recommended once published): Settings → Community nodes → Install → n8n-nodes-custom-credential-vault.

From source:

git clone https://github.com/efmcyrill/n8n-nodes-custom-credential-vault.git
cd n8n-nodes-custom-credential-vault
npm install
npm run build          # compiles TypeScript to dist/
npm pack               # produces n8n-nodes-custom-credential-vault-x.y.z.tgz

Then install the tarball into your n8n nodes folder with npm (this registers the package; copying files in by hand will not register it and n8n will drop the node on the next restart):

cd ~/.n8n/nodes && npm install /path/to/n8n-nodes-custom-credential-vault-2.0.2.tgz --omit=peer

Restart n8n.

Usage

1. Create a Credential Vault credential. Give it a name and fill in Name / Value pairs (e.g. ANTHROPIC_API_KEY / your key).
2. Add a Credential Vault Resolver node to your workflow and select that credential.
3. In Keys to resolve, tick the secrets this workflow needs.
4. Reference a value anywhere downstream, including Code nodes:

   {{ $('Resolve Vault Secrets').item.json.ANTHROPIC_API_KEY }}

A preview of both UIs is in docs/.

Advanced: serving secrets to a remote caller (n8n as a secrets API)

You can let another service — a second n8n, or any backend — fetch secrets at runtime instead of running a separate vault server. Build a small workflow: Webhook (POST, Header-Auth) → Credential Vault Resolver (with Keys to Resolve = ={{ $json.body.keys }}) → Respond to Webhook (returns the resolved fields as JSON). The caller POSTs the key names it needs and loads the response into its own process memory.

curl -X POST https://<your-n8n>/webhook/vault-secrets \
  -H 'x-vault-key: <strong-shared-secret>' \
  -d '{"keys":["ANTHROPIC_API_KEY"]}'

This is convenient and free, but you now own a network endpoint that returns secrets — treat it as critical: HTTPS only, a strong header secret or HMAC signature (with timestamp/nonce against replay), an IP allowlist at your proxy, saveDataSuccessExecution: 'none', and your own request audit log (there is no built-in one). Use it only for internal, trusted, low-volume callers; for public/high-volume use or strict compliance, run a dedicated secrets manager instead.

Upgrading without losing secrets

Secrets live in the database, not in this package — upgrading the node never touches them. Field names (name1…name30, value1…value30) are stable and append‑only across versions, so your stored vaults survive every update.

Always upgrade with npm install <new-tarball> (in ~/.n8n/nodes) or the n8n GUI's Community nodes → Update. Do not hand‑copy the dist/ files over an installed package — n8n tracks a package registry/integrity record, and an unregistered file swap makes n8n drop the node on the next restart.

Development

npm install
npm run build

Source is TypeScript under credentials/ and nodes/. dist/ is generated and git‑ignored.

License

MIT © 2026 eFinancialModels