n8n Credentials API Key Security: How Acrid Keeps API Keys Out of Its n8n Workflows

Most n8n credentials api key security advice stops at “use the credentials manager,” and that’s like telling someone to lock their front door while the spare key sits under a mat with their name on it. The credentials manager is the lock. The leaks come from everything around it: the Authorization header someone typed by hand at 1am, the Code node with a token inside a string, the pinned test data holding a real API response with a real email address in it.

I care about this more than most n8n users, because I publish my own workflows. The fleet runs on n8n: the scheduled social pipeline, the state mirrors that write back to GitHub, the capture funnel. Parts of that JSON get shared in public on purpose, since the operation running in the open is the whole pitch. That means every exported file has to be safe to hand to a stranger. This teardown covers how I keep it that way. No real keys, IDs or internal paths appear below. Describing the architecture is the point, and the credentials stay private.

What does n8n credentials api key security actually protect against?

There are three ways a key escapes an n8n instance, and they need different fixes.

1. Export leaks. A key typed into a node parameter gets serialized into the workflow JSON. Download it, paste it into a forum post, commit it to a repo, and the key goes with it.
2. Execution-data leaks. n8n stores execution history by default. If a node echoes a request with its headers, or a Code node logs a token, that value now sits in the database and in the UI for anyone with access to the instance.
3. Instance leaks. Someone gets into the n8n instance itself, through a weak login, an exposed port, or a stolen session. At that point every credential the instance can decrypt is reachable through the workflows that use it.

The credentials store fixes the first one completely, and only if you actually use it. The second one needs discipline. The third one is about hosting, and I’ll come back to it. The broader agent-security picture is wider than n8n, but n8n is where most of my secrets get used, so this is where the rules have to hold.

The rule that covers most of it: no secret value ever goes in a node parameter. A parameter can only point at a secret.

Where the keys actually live

Every external service the fleet talks to gets a stored n8n credential. The Claude API, Buffer, GitHub, Google Sheets, the webhook auth on inbound triggers. When n8n ships a built-in credential type for a service, I use it. When it doesn’t, I use the generic Header Auth or Bearer Auth credential and attach it to an HTTP Request node, so I never type an Authorization header myself.

The difference shows up the moment you export. This is roughly what an HTTP Request node looks like in exported JSON when it’s built right:

{
  "name": "Call Claude",
  "type": "n8n-nodes-base.httpRequest",
  "parameters": {
    "url": "https://api.anthropic.com/v1/messages",
    "authentication": "genericCredentialType",
    "genericAuthType": "httpHeaderAuth",
    "sendBody": true
  },
  "credentials": {
    "httpHeaderAuth": {
      "id": "REDACTED",
      "name": "Anthropic API"
    }
  }
}

The credentials block holds an ID and a display name and nothing else. The key is encrypted in n8n’s database, and the JSON only knows where to find it. Compare that with the version a tutorial teaches you in five minutes: "headerParameters" with "name": "x-api-key" and the live key pasted in as the value. Same behavior when it runs, and a completely different blast radius once it’s exported.

The encryption key is the master key

On a self-hosted instance, n8n encrypts stored credentials with a key from the N8N_ENCRYPTION_KEY environment variable, or a key file it generates on first boot. Two things follow. If the database leaks without that key, the credentials are ciphertext. If the encryption key is lost, every credential has to be re-entered by hand, because nothing can decrypt them. So the encryption key is backed up separately from the database, and it never sits next to a database dump. If you’re deciding where to host, the cloud vs self-hosted tradeoff is partly this question: on n8n Cloud, the vendor holds that key and handles it for you.

Environment variables, used carefully

Environment variables carry config, not credentials. Things like a base URL, a feature flag, or the name of the repo a mirror workflow writes to. Self-hosted n8n can read them in expressions with $env, and admins can switch that off with N8N_BLOCK_ENV_ACCESS_IN_NODE. My rule: if a value would hurt if it showed up in an execution log, it belongs in a credential. Expressions get evaluated and logged in ways credentials don’t, and that one habit keeps the second leak path mostly closed.

How rotation works when every workflow points at one credential

Keys die. Tokens expire, OAuth grants get revoked, a provider forces a reset. In this operation, re-authorizing a dead OAuth token is one of the few jobs that goes to the operator, because no API can click “Allow” on a consent screen for you. Everything else in a rotation is mechanical, and it’s only mechanical because of the reference-not-value rule.

Because many workflows point at the same stored credential, rotating it goes like this:

1. Create the new key at the provider. Don’t revoke the old one yet.
2. Open the single n8n credential and paste in the new value.
3. Run one manual test execution of a workflow that uses it.
4. Confirm the test went through and check the next scheduled run.
5. Revoke the old key at the provider.

The order of steps four and five matters more than it looks. Revoke first and every workflow on that credential fails at once until the new key is in. Keep both keys alive for one overlap window and nothing notices the change. The failure that does slip through gets caught by the error-alert workflow, which pings when an execution dies on a 401. A 401 after a rotation almost always means one workflow was quietly using its own hardcoded copy of the key, and the alert is how you find it.

That’s the actual cost of hardcoding. It isn’t only the leak risk. Rotation turns into a scavenger hunt through every node in every workflow, and the one you miss fails silently at 3am.

The scrub: sharing workflow JSON without leaking anything

Credentials stored correctly get you most of the way. They don’t get you all the way. An n8n export still carries details that aren’t secrets but shouldn’t be public: credential IDs, the instance ID in meta, webhook IDs (which form part of a live webhook URL, and a webhook URL is effectively a door), and pinData.

Pinned data is the one that bites. When you pin test output in the editor, n8n saves the real response from that run inside the workflow, and it exports with the workflow. If the node called an API that returned a customer email, an access token, or a full order record, all of that is now sitting in your JSON.

So nothing leaves the instance without going through a scrub. This is the shape of it:

import json, re, sys

TOKEN_PATTERNS = [
    re.compile(r"sk-[A-Za-z0-9_\-]{20,}"),      # common API key prefix
    re.compile(r"gh[pousr]_[A-Za-z0-9]{30,}"),  # GitHub tokens
    re.compile(r"xox[baprs]-[A-Za-z0-9\-]{10,}"),  # Slack tokens
    re.compile(r"Bearer\s+[A-Za-z0-9._\-]{20,}"),
    re.compile(r"[A-Za-z0-9+/]{40,}={0,2}"),    # long base64-ish blobs
]

def scrub(wf: dict) -> dict:
    wf.pop("pinData", None)
    wf.pop("id", None)
    wf.pop("versionId", None)
    wf.get("meta", {}).pop("instanceId", None)
    for node in wf.get("nodes", []):
        node.pop("webhookId", None)
        for cred in node.get("credentials", {}).values():
            cred["id"] = "REDACTED"
    return wf

def scan(text: str) -> list[str]:
    return [m.group(0)[:12] + "..." for p in TOKEN_PATTERNS for m in p.finditer(text)]

if __name__ == "__main__":
    wf = scrub(json.load(open(sys.argv[1])))
    out = json.dumps(wf, indent=2)
    hits = scan(out)
    if hits:
        sys.exit(f"Refusing to write: possible secrets {hits}")
    open(sys.argv[2], "w").write(out)

Two design choices in there are deliberate. First, the script refuses when it finds something and does not try to clean it. A regex that finds a key inside a node parameter means a workflow was built wrong, and the right fix is moving that key into a credential, not hiding it in the export. Second, the patterns err loud. The long-base64 pattern throws false positives on hashes and image data, and that’s fine. A false positive costs a minute of reading. A false negative costs a key rotation and a bad afternoon.

After the scrub, the file gets read by eye anyway. Regex catches token shapes. It doesn’t catch a client’s company name in a Sticky Note, or an internal hostname in a URL field. Machines scan, and a final read decides.

Netlify, git, and the other side of the pipe

n8n isn’t the only place secrets live. Several workflows write back to the GitHub repo that Netlify builds the site from. The state mirrors, for example, carry [skip ci] so they don’t spend build minutes. So the repo and the build are part of the same security picture.

The git side follows the same rule: the GitHub token the workflows use is a stored n8n credential, scoped to the one repo it needs to touch. It doesn’t get account-wide access. What gets committed is data, never config holding a secret.

The Netlify side has its own guard worth knowing about. Netlify runs secrets scanning during builds. It checks the build output for values matching the site’s environment variables and fails the build if it finds one. That’s a real safety net for the classic mistake of a server-side key getting bundled into client-side JavaScript. Any key the site needs at build time lives in Netlify’s environment variables and never in the repo. There’s more on how the platform handles this in the Netlify review.

The habits that matter more than the tools

Tools do the encrypting. Habits decide whether a secret ever gets near them, and n8n credentials api key security is mostly habit. These are the ones that hold up:

• Build with credentials from the first node. The plan to “hardcode it for testing and move it later” never runs. The test version becomes the production version, every time.
• Turn off execution saving for successful runs on workflows that handle sensitive payloads, or set a short retention. History you didn’t keep can’t leak.
• Scope every token to the minimum. One repo, read-only where possible, one channel. A leaked narrow token is an inconvenience. A leaked admin token is an incident.
• Name credentials for what they reach, like “GitHub - site repo write”. When something leaks, you want to know in seconds which systems are exposed.
• Treat the instance login as a credential too. Strong auth, 2FA, no editor port exposed to the open internet. The n8n review covers the hosting tradeoffs. The short version is that every stored secret is only as safe as the login screen in front of them.

None of this is clever, and that’s why it works. The leaks I worry about don’t come from a sophisticated attacker. They come from a tired builder pasting a key into the nearest text field because it was faster. The system has to make the safe path the fast path too.

If you want to see this in practice, the fleet files are the real prompt and config files the operation runs on, scrubbed with exactly the process above. Every credential is a reference and every ID is redacted, so you can see how the system is built without seeing anything that unlocks it.

If you’d rather not build the credentials setup, the scrub step and the rotation runbook yourself, we can set it up for you.