Environment variables

Your app's settings — API keys for other services, feature switches, anything you would otherwise hard-code — live on the app's Environment tab. They reach your app as ordinary environment variables, so a framework that reads its configuration from the environment picks them up with no code from you.

What we set for you

These arrive on every deploy without you doing anything.

Variable	What it is
ROAR_API_KEY	An AI key of the app's own. Calls it makes bill to your workspace and are attributed to that app, so you can see what each one costs.
ROAR_BASE_URL	The gateway address to send those calls to.
DATABASE_URL	Connection string for the app's managed Postgres, if you turned one on. See Databases.
APP_NAME, APP_URL	The app's own name and public web address.

What you can set

Anything else. The usual case is a credential for a service your app talks to — a payment provider, an email provider, a third-party API.

APP_NAME and APP_URL are yours to override if you want different values; setting them replaces ours. DATABASE_URL is the same, if you would rather point the app at a database of your own than the one we provision.

Names you cannot use

A few names are reserved, because we set them and an edited copy would put your app into a state that disagrees with itself:

• ROAR_API_KEY and ROAR_BASE_URL — your app already has both.
• ROAR_CRON_SECRET — filled in for you when you set up a scheduled run on the Jobs tab.
• The port your app listens on, and a small number of names the hosting layer uses internally.

Try to set one and the console says so, and tells you what the app already has rather than only refusing.

Changing one

Every change redeploys the app. There is no separate "restart" — a new version is built and takes over, and the previous one keeps serving until it does. That means:

• A change is live within a deploy's time, not instantly.
• A batch of changes is better made together than one at a time, since each one costs a deploy.
• If the new version fails to build, the old one stays up with the old values. See When a deploy fails.

Two things worth knowing

Some frameworks need a variable at BUILD time, not just at run time. Anything baked into a compiled front-end is read while the app is being built, so a variable added after a build is not in it until the next one. If a setting looks correct on the Environment tab and your app still cannot see it, this is usually why — redeploy.

Secrets belong here, not in your repository. A key committed to GitHub is a key you have to rotate, whatever the repository's visibility. Putting it on this tab keeps it out of your history and out of anything your team clones.