> secrets & env vars

Secrets are encrypted, write-only values (API keys, DB passwords, Hyperdrive/Postgres credentials, tokens) bound to a Worker at the edge, while non-sensitive config lives in plaintext `vars` in your Wrangler config. Wrangler's `secret` subcommands push these to Cloudflare per Worker and per environment — you can set, bulk-upload, list, and delete them, but you can never read a value back. For local `wrangler dev`, secrets come from a `.dev.vars` file that never leaves your machine.

// secrets & env vars

8 commands

// faq

What's the difference between a secret and a var in Wrangler?

`vars` in your wrangler.jsonc/toml are plaintext environment variables baked into the deploy — fine for non-sensitive config like feature flags or a public base URL. Secrets are encrypted, write-only, and set out-of-band with `wrangler secret put`, so they never appear in your repo or config. Both surface on `env` inside the Worker; don't reuse one name for both a var and a secret.

Can I read a secret's value back after setting it?

No. Secrets are write-only — `wrangler secret list` returns only names and types, never values. If you've lost a value, you can't recover it; rotate it by running `wrangler secret put <KEY>` again with the new value.

How do I provide secrets to local dev without pushing them to production?

Create a `.dev.vars` file (KEY=VALUE lines) in your project root; `wrangler dev` loads it automatically and never uploads it — gitignore it. Use `.dev.vars.<environment>` (e.g. `.dev.vars.staging`) for per-environment local values, selected with `wrangler dev --env staging`.