Vars and Secrets

An App’s code reads configuration from env. Plain values, such as a support address or a feature setting, go in vars in the wrangler.json file. Credentials, such as API keys, go in Secrets, which the platform stores outside the source. Code reads both kinds of value the same way, as env.NAME.

Define vars

Add plain-text values under the vars key in the wrangler.json file. Each value must be a string. Otherwise, deploy refuses the file.

wrangler.json

{
  "name": "app",
  "main": "index.js",
  "compatibility_date": "2026-09-17",
  "vars": {
    "SUPPORT_EMAIL": "support@example.com",
    "SIGNUPS_OPEN": "true"
  }
}

vars are plain text in the source. Anyone who can read the source can read them. Never put credentials in vars, in code, or in other files. Use a Secret instead.

Read a value

Code reads vars and Secrets from env.NAME. Pass env to your functions as a parameter. Don’t keep it in a module variable.

index.js

export default {
  async fetch(request, env, ctx) {
    if (env.SIGNUPS_OPEN !== "true") return new Response("Signups are closed.", { status: 403 });
    return createAccount(request, env);
  },
};

async function createAccount(request, env) {
  const res = await fetch("https://api.example.com/v1/accounts", {
    method: "POST",
    headers: { authorization: `Bearer ${env.EXAMPLE_API_KEY}` },
    body: await request.text(),
    signal: AbortSignal.timeout(30_000),
  });
  return new Response(res.body, { status: res.status });
}

In this example, SIGNUPS_OPEN is a var, and EXAMPLE_API_KEY is a Secret.

Use Secrets

You set Secrets through the platform, not in the source. A Secret’s name uses uppercase letters, digits, and underscores, and can’t start with a digit. If you work with the in-product agent, it asks you for the Secrets that the App needs, by name. For more information, see Secrets. An App has one set of Secrets, which the dev server and production share.

How Secrets reach your code

The App’s Secrets reach your code in the following ways:

In production: at deploy, Judt adds the Secrets to the vars of the deployed copy of the wrangler.json file. The values don’t reach the source, Git, or the build.
On the dev server: Judt writes the Secrets to a .dev.vars file in the sandbox, and celld, the Judt runtime, gives them to your code.

In both places, a Secret replaces a var that has the same name.

When a change takes effect

The dev server of a running sandbox gets a change to a Secret at once. Production gets the change at the next deploy. For more information, see Deployments.

Limitations

Secrets have the following limitations:

The build gets no Secrets, at deploy or on the dev server.
Commands in the sandbox get no Secrets in their environment. Only the dev server gets them. Command output shows a Secret value as [secret:NAME].
On the dev server, a Secret with a multi-line value doesn’t reach your code. In production, it does.
The .dev.vars and .env files are reserved paths. You can’t write them, and deploy refuses a source that contains them. To give the App a value, set a var or a Secret.

Get started

Project

Storage

Background work

Advanced

Reference