> ## Documentation Index
> Fetch the complete documentation index at: https://docs.judt.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Vars and Secrets

> Read configuration values and credentials from env in App code.

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](https://docs.judt.ai/manage/secrets.md), 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.

```json wrangler.json theme={null}
{
  "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.

```js index.js theme={null}
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](https://docs.judt.ai/manage/secrets.md).

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](https://docs.judt.ai/manage/concepts/deployments.md).

### 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.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.