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

# Environment Variables

> Set the values your app reads from its environment, from the dashboard or over the API. Every one is encrypted at rest and write-only.

Your application reads its configuration from the environment. Antideploy
stores those values, encrypts them, and injects them when the app is released.

<Note>
  There is one store, not two. Every variable you set is encrypted at rest and
  cannot be read back, so there is no separate, weaker place to put
  non-sensitive values, and no decision to make about which to use. See
  [Secrets](/docs/configuration/secrets).
</Note>

## Setting variables from the dashboard

Open your application and scroll to **Environment variables**. Analysis lists
the variable names your code reads, marking which ones it still needs from you,
so the common case is filling in a form that is already labelled.

Enter values and save. They apply on the **next deployment**.

## What Antideploy injects for you

These are set automatically. You do not need to supply them, and if your code
reads them they will be there.

| Variable       | Description                                                          |
| -------------- | -------------------------------------------------------------------- |
| `PORT`         | The port your app must listen on. Bind this, not a fixed number.     |
| `DATABASE_URL` | Connection string for your provisioned Postgres, if one was created. |

When a Postgres database is provisioned, the standard libpq variables are
derived from the same connection string and injected alongside it, for tools
and clients that read those instead of a URL:

`PGHOST` · `PGPORT` · `PGUSER` · `PGPASSWORD` · `PGDATABASE` · `PGSSLMODE`

<Tip>
  If you set a variable with the same name as one Antideploy injects, **your
  value wins**. Deliberately setting `DATABASE_URL` to an external database is
  a normal thing to do, and silently overriding it would be baffling.
</Tip>

## When changes take effect

Every change (added, updated, or removed) applies on the next deployment. A
running container's environment is fixed for the life of that revision, so
there is no way to change a value under a running app.

Redeploy after changing a variable, or the app keeps the value it started with.

## Documenting what your app needs

Commit a `.env.example`. Analysis reads it to work out which variables your app
expects and shows them in the dashboard as fields to fill in.

<Warning>
  Analysis reads the **names** of variables your code and examples reference. It
  never reads values, and a real `.env` is excluded from what gets uploaded.
</Warning>

## Setting variables over the API

Variables can be written with a project API key. They are write-only: nothing,
including a valid key, reads the values back.

```bash theme={null}
curl -X PUT https://antideploy.com/api/v1/secrets \
  -H "Authorization: Bearer $ANTIDEPLOY_KEY" \
  -H "Content-Type: application/json" \
  -d '{"STRIPE_SECRET_KEY":"sk_live_..."}'
```

Send a whole `.env` alongside a deploy:

```bash theme={null}
tar czf - . | curl -X POST https://antideploy.com/api/v1/deploy \
  -H "Authorization: Bearer $ANTIDEPLOY_KEY" \
  -F "archive=@-" -F "env=$(cat .env)"
```

Listing returns key names only, never values:

```bash theme={null}
curl https://antideploy.com/api/v1/secrets \
  -H "Authorization: Bearer $ANTIDEPLOY_KEY"
```

<Card title="Bring your own database" icon="database" href="/docs/infrastructure/databases">
  Pointing the app at Supabase, Neon, or anything else you already run.
</Card>