The Deployer documentation
Creating & deploying a project

Environment variables

Most apps need a few settings to run — things like a database address, an API key for a payment service, or a secret password. These are called environment variables: named settings your app reads when it starts. This step is where you provide them, and an AI helper makes sure each one ends up in the right place.

What environment variables are

Think of them as labelled sticky notes your app looks for at startup, written as NAME=value. Some are harmless (a feature toggle); others are secrets (a database password, an API key) that must be kept private. During Analysis, the app already read your code and listed the variable names it expects — so you usually just fill in the values.

Adding your variables

  1. On the Environment tab, you'll see a box for the service you chose to deploy. Any names detected from your code are shown as hints.
  2. Paste your settings as KEY=value lines — one per line — into the box for that service. For example:
    • DATABASE_URL=postgresql://…
    • STRIPE_SECRET_KEY=sk_live_…
  3. Repeat for each service that needs settings. A small badge shows configured or skipped so you can see your progress at a glance.
  4. Click Save draft at any time to keep what you've typed without moving on, or Continue — review my code when you're done.

The Deployer writes these values into the correct place, in the correct folder, before your app is built — so your app finds them exactly where it expects.

You can skip for now

Providing values is optional. Click Skip for now (or Skip this service) and you can add them later — including from Chat or the Dashboard once your app is live. Some common values are also wired up automatically: if your app needs a database or cache, its connection settings (like DATABASE_URL and REDIS_URL) are filled in for you when those are provisioned.

The Env Doctor: help placing your settings

Getting a setting into the right service and file matters — a backend key placed on the frontend simply won't work. An AI helper called the Env Doctor takes the guesswork out of this. It reads your project and suggests exactly which service and file each variable belongs in.

Crucially, it protects your secrets: the Env Doctor only ever sees the variable names (the keys), never the secret values. The values aren't sent to the Env Doctor — they're stored encrypted and placed into your app's configuration when it's deployed.

Applying changes to a live app

Once your app is already running, you can revisit its environment settings from the Dashboard. There, changing a value and clicking Apply triggers a targeted redeploy — The Deployer updates just what's needed and restarts your app with the new settings, without disturbing the rest. For apps running on your own servers the redeploy is a health-gated rolling update, so the old version keeps serving until the new one passes its health check; managed hosting uses the provider's own rollout (more on that in launching & reading the logs).

History: who changed what, and undoing a change

Every change to a project's environment variables is kept. Open Environment variables on the Dashboard and switch to History to see a timeline: who made each change, when, and which variables were added, changed or removed. Changes made for you, like attaching a database, are listed too. Under each variable in the editor you'll also see when it last changed and by whom. When you save, you can leave a short note, such as "rotate the Stripe key", and it appears in the timeline.

Values stay hidden in the timeline. Click the eye beside a variable to see its old and new value; each time someone does, it's recorded.

To go back, click Undo on the newest change, or Restore on an older one. The Deployer shows exactly what will change compared with what's set now. Then choose Restore and redeploy to put the old values live, or Restore without redeploying to save them for the next deploy. A restore is itself a new entry in the history, so you can undo it too.

The newest 20 versions can be restored. Older entries keep the record of who changed what, but no longer hold the values.

Keeping variables in a Git file

A service can take its variables from a file in a repository, such as config/api.env. When someone changes that file, The Deployer picks up the new values and redeploys the service.

  1. Open Environment variables on the Dashboard and switch to Source.
  2. Click Sync from a Git file on the service. The repository and branch are already filled in with the project's own; change them to use a separate settings repository.
  3. Click one of the env files found in the repository, or type its path. The Deployer shows what connecting would do, variable by variable (new, changing, unchanged), without showing any values.
  4. Click Connect and deploy.

How it behaves:

  • Only private repositories. Values are read only from a repository the code host confirms is private, checked again on every change. A public file, like .env.example, can still add the variable names for you to fill in.
  • The file owns what it lists. Those variables are read-only in the dashboard; change them in the file. Variables you set in the dashboard stay yours, and the file never touches them. Removing a line from the file removes that variable.
  • It never empties your app. If the file disappears, can't be read, turns empty, or the repository becomes public, the sync stops, your app keeps its current values, and the project owner gets an email.
  • One push, one redeploy. A push that changes your code and the file redeploys once, with the new values. A change to only the file rebuilds just the service it feeds. Each change appears in History with the commit and its author.
  • Restoring pauses the sync. Restoring an older version from History pauses the Git sync, so the file doesn't overwrite what you restored. Click Resume in Source when you're ready.

Use Sync now to pick up a change straight away, Pause to stop for a while, or Disconnect to stop syncing and keep the values as they are.

Keeping variables in a secret manager

If your passwords and keys live in AWS Secrets Manager, Google Secret Manager or Azure Key Vault, a service can read them from there on every deploy, so a rotated secret reaches your app without anyone pasting it. See Environment from a secret manager.

A note on safety

  • Never share your secret values with anyone who doesn't need them. The Deployer stores them encrypted and only writes them into your own app, in your own cloud.
  • You can leave any value blank for now and fill it in later — your app just won't use that setting until you do.

When your variables look right, continue to Code Readiness checks.