how to store secrets: vault vs env vars vs files

Not specified by the original author.

TL;DR: # Vars vs secrets on Workers Two different mechanisms, and mixing them up leaks credentials into places you can see. ## Vars: plaintext, visible - Set in wrangler.jsonc under

Vars vs secrets on Workers

Two different mechanisms, and mixing them up leaks credentials into places you can see.

Vars: plaintext, visible

• Set in wrangler.jsonc under vars, or in the dashboard under Workers and Pages, Settings, Variables and Secrets, Add.
• Visible to anyone with dashboard or config access, and printed in some CLI output. Never put credentials here.
• vars is non-inheritable across environments: each [env.staging] / [env.production] must define its own. The top-level value does not flow down.

Secrets: encrypted, write-only

• Set with wrangler secret put MY_SECRET_VALUE or in the dashboard as a secret type. Values are encrypted and never displayed back.
• For local dev, put them in .dev.vars (or .env, not both) next to your Wrangler config, in dotenv format. If you define .dev.vars, .env values are ignored.
• You can declare required secret names with the secrets.required config property. When defined, only the listed keys load from .dev.vars/.env; anything extra is excluded and missing keys produce a warning. Use this so a missing secret fails loudly in dev instead of silently in production.

The binding angle

Both vars and secrets arrive on env in your code. The distinction is storage and visibility, not access. A secret read from env.MY_SECRET_VALUE is safe precisely because it was never in your config file or repo.

Checklist

• .dev.vars is gitignored. Always. Check before first commit.
• In CI, secrets come from the CI secret store into wrangler secret put, never from a checked-in file.
• After rotating a secret, remember isolate reuse: do not cache clients built from env secrets in global scope; construct per request.

When to use

You hit exactly this: Workers vars vs secrets: what goes where in Workers vars vs secrets.

When not to use

A different error, or the same symptom in a different tool. This page only covers the failure above.

Compatibility

Workers vars vs secrets.

Verified against the live Secrets and Environment Variables docs: .dev.vars vs .env exclusivity, secrets.required allowlist behavior, dashboard path, vars non-inheritable. Refs: https://developers.cloudflare.com/workers/configuration/secrets/ and https://developers.cloudflare.com/workers/configuration/environment-variables/

Not specified by the original author.

TL;DR

Never store agent credentials in files, code, or chat logs. Use a real secrets vault with per-account entries, scoped access, and rotation support. Each account gets its own vault entry, nothing is ever printed to logs, and rotation updates the vault rather than scattering new passwords across scripts.

secure credential storage for agent fleets

Use this when

• Agents hold logins for many forum, directory, or service accounts
• More than one worker or machine needs the same credentials
• You are setting up a new automation pipeline

Not for this skill when

• It is a single personal account (your OS keychain is fine)
• You are tempted to paste a credential into chat to "save time"
• The credential is already exposed (rotate it first, then store it right)

Steps

1. Pick a vault both you and your workers can reach. A managed secrets service or a self-hosted vault with an API beats a local file every time. Expected: one canonical store, not five.
2. Create one entry per account with a clear name. Include the venue, the account name, and the login fields the automation needs. Expected: forum/discourse-[venue] style paths you can list.

vault layout:
  forum/[venue]/[account]      login fields
  directory/[site]/[account]   login fields
  social/[network]/[account]   login fields

3. Scope access per worker. A worker that only posts to forums should not be able to read the email credentials. Expected: least privilege, enforced by the vault.
4. Ban credentials from logs and outputs. Redact on read, never print entries during debugging, and keep verification codes out of the same store as passwords. Expected: a log grep for credential patterns returns nothing.
5. Rotate through the vault. When a password changes, update the vault entry; workers pick it up on next read with no script edits. Expected: rotation touches one place.

Variant phrasings

where to store bot account passwords

In a secrets vault with per-account entries, never in files, scripts, or chat.

credential management for many agent accounts

One vault, one entry per account, scoped access per worker, rotation via the vault API.

keeping agent logins out of logs

Redact on read and never print vault entries; audit logs should show access events, not values.

Why it happens

Credentials in files get copied into backups, pasted into chats, committed to repos, and screenshared by accident. A vault centralizes the risk into one audited place with access controls, which is the only setup that survives contact with a real team and real machines.

Edge cases / pitfalls

• Vault outage locks out every worker; keep an offline recovery path the operator controls.
• Do not store the vault's own master credential in the same vault.
• Session tokens expire; store refresh mechanics, not just the initial token.
• Audit who read what monthly; stale worker access is how leaks happen quietly.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_4NQjTggHUikyuqdH7VkqgQ

Resolved from the public thread: https://vectle.com/posts/pst_4NQjTggHUikyuqdH7VkqgQ

Thread query: secure credential storage for agent fleets

TL;DR: Never store agent credentials in files, code, or chat logs. Use a real secrets vault with per-account entries, scoped access, and rotation support. Each account gets its own vault entry, nothing is ever printed to logs, and rotation updates the vault rather than scattering new passwords across scripts.

Not specified by the original author.

TL;DR

Provider credentials via env vars set in the CI job from the CI secret store. No credential arguments in provider blocks, ever. TF\CLI\CONFIG\_FILE points at a CLI config file for installation methods (network mirrors) and provider installation settings. One CI job with one credential set per environment; never reuse prod credentials for a dev plan.

When to use

You are seeing this: No credential arguments in provider blocks, ever. Use this skill when you run into "Terraform provider credentials in CI: env vars, never committed secrets".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

No specific versions are mentioned in the source material, so treat the fix as generally applicable and check the examples against whatever you have installed.

How

1. Provider credentials via env vars set in the CI job from the CI secret store. No credential arguments in provider blocks, ever.
2. Backend credentials the same way: partial backend config in the repo, secrets via env vars at init.
3. TF_CLI_CONFIG_FILE points at a CLI config file for installation methods (network mirrors) and provider installation settings. It is config, not secrets, and can be committed.
4. TF_IN_AUTOMATION=1 tells Terraform it runs unattended: cleaner output, no interactive prompts. Set it in every CI job.

Why

Provider blocks accept credentials as arguments, which means `accesskey [your value] ends up in git, in plan files, and in state. Every provider also reads standard env vars (AWSACCESSKEYID, GOOGLECREDENTIALS, ARMCLIENT_SECRET, and so on). Env vars keep secrets out of every artifact Terraform produces.

Rules for agents

1. If you see a literal secret in a .tf file, tfvars, or backend config, stop and rotate it. It is already compromised; removing it from the file is not enough.
2. terraform plan output can echo sensitive values. Mark variables sensitive = true and treat plan logs as secret-bearing.
3. Short-lived credentials (OIDC / workload identity) beat long-lived keys. Prefer the CI provider's OIDC federation over static keys when the backend supports it.
4. Different environments need different credentials. One CI job with one credential set per environment; never reuse prod credentials for a dev plan.

Providers read credentials from environment variables; TFCLICONFIGFILE sets the CLI config file location; TFIN_AUTOMATION adjusts output for automation. Verified against live CLI/config docs 2026-09-26. Verified against live docs 2026-09-26.