Skip to content
Docs

Variables

Your app's settings and secrets, like APP_KEY or DATABASE_URL. Stored encrypted, hidden until you show one, and given to builds and every process.

Updated 17 Oct 20263 min read

Variables are your app's settings and secrets: an API key, a mail password, APP_KEY, DATABASE_URL. They're stored encrypted, hidden on screen until you show one, and given to your app's build and to every process it runs: its web process, its workers, its scheduled tasks and one-off commands. Changes apply on the next deploy.

Add a variable

  1. Open your project, then the Variables tab.

  2. Choose the app under App.

  3. Choose Add a variable, type its Name and Value, and Save.

  4. The page says Redeploy to apply. Choose Redeploy when you're ready: the app restarts with the new values, without downtime.

Until you redeploy, the live version keeps the variables it started with. That's on purpose: you can change several, then apply them together.

Paste a .env file

Moving from another host? Choose Paste a .env file and paste its lines. Comments, export and quotes are understood, and a variable with the same name as one you have replaces it:

Terminal
# From your old host
MAIL_HOST=smtp.example.com
MAIL_PORT=587
export MAIL_FROM_ADDRESS="shop@duka.co.tz"

Choose Add them, then Redeploy.

Names and limits

  • A name has letters, digits and _, and doesn't start with a digit: APP_KEY, STRIPE_SECRET, S3_BUCKET.

  • PORT and HOME are ours: your app's PORT is always 8080.

  • Up to 200 variables an app, 64 KB in all.

Who sees a value

Values are hidden until someone chooses Show, and each time a value is shown, it's recorded in the project's activity: who, and which variable. Values are sent to your app only when a build or deploy starts, and never written into a log.

Variables a database adds

When you attach a database to an app, its connection details become variables, like DB_HOST, DB_PASSWORD and DATABASE_URL. They show From and the database's name, and you change them on the database's page, not here: that's how a new database password reaches every attached app by itself. See Connect an app to a database.

Example: Asha's shop

Asha's app web in project duka has these, besides the ones her MySQL database added:

NameWhat it's for
APP_KEYLaravel's encryption key, from php artisan key:generate --show
APP_URLhttps://duka.co.tz
MAIL_HOST, MAIL_USERNAME, MAIL_PASSWORDHer email provider
STRIPE_SECRETHer shop's own payments

She adds STRIPE_SECRET, sees Redeploy to apply, and chooses Redeploy. Once the new deployment is live, it has the new variables.

Builds read variables too

Next.js and Vite write some variables into the built files (like NEXT_PUBLIC_… and VITE_…). Change one of those, and a redeploy isn't enough: deploy a new build, from a push or Build again.

Shared variables for every environment

A project with staging or other environments can share variables between them. On the project's Environments page, Shared variables are set once for every environment. An app's own variable with the same name wins.

Previews get none of production's variables, unless you mark one Also for previews in this tab. That keeps a stranger's pull request away from your real secrets. See Environments and previews.

Remove a variable

Choose Remove next to it. The live version keeps it until the next deploy.

PreviousThe settings file, tanzahost.jsonNextWorkers