Use vars for plain configuration and secrets for anything sensitive. A Worker reads both the same way through its env object, but a secret's value is hidden in Wrangler and the Cloudflare dashboard once you define it, while a var sits in plain text in your configuration file.
The same mechanism, different visibility
Cloudflare's documentation states that secrets are environment variables. The difference is visibility: after you create a secret, its value is not shown in Wrangler or the dashboard. Your Worker sees no difference between the two.
Environment variables defined in the Wrangler configuration, under vars, are not encrypted. They can be text or JSON values, and the documentation warns not to use plaintext environment variables for sensitive information. Because they live in a file you commit, anything placed there ends up in version control.
How to set a secret
- With Wrangler, run wrangler secret put followed by the key name. This creates a new Worker version and deploys it immediately.
- If you use gradual deployments, run wrangler versions secret put and deploy the version separately.
- In the dashboard, open the Worker, go to Settings, then Variables and Secrets, add one and choose the Secret type.
- For many values, a secrets file can upload up to 100 secrets alongside your code during deploy or version upload.
Local development
Locally, put secrets in a .dev.vars or .env file next to your Wrangler configuration, using dotenv syntax. Use only one of the two: if .dev.vars exists, .env values are ignored. Add both patterns to .gitignore so they are never committed. For different environments, files named with the environment suffix are supported.
A decision table in words
- Public hostname, feature flag, log level: vars.
- API key, token, signing key, database password: secret.
- Access to another Cloudflare resource such as a KV namespace or R2 bucket: neither. Use a binding, which needs no key at all (see bindings instead of API keys).
Pitfalls
- Vars are not inherited between Wrangler environments, so each environment needs its own block. A missing value then shows up as undefined at runtime, which can silently disable a check.
- A secret that was once committed in a vars block is exposed in history even after you move it. Rotate it.
- Changing a secret creates a new version. Plan for that when you use gradual deployments.
- Do not log the whole env object while debugging.
Quick check
Can I read a secret back from the dashboard later?
No. Its value is hidden in Wrangler and the dashboard after you set it. Keep the source of truth in your password manager or secrets store.
Is a var safe for a public API base URL?
Yes. Vars are fine for non-sensitive configuration. Just remember they are stored unencrypted.
Safeguard's free scan can check the packages your Worker bundles for known vulnerabilities.
Sources
Last reviewed: 19 October 2026.
