Environment variables

Scopes

Every variable belongs to one or more scopes. A deploy reads the scope that matches its target, so the same key can hold a different value in each.

• production — deploys made with rivet deploy --prod or merged to your production branch.
• preview — every preview environment, one per branch or pull request.
• development — values written to .env.local by rivet env pull.

Set a variable

Use rivet env set from a linked project directory. Pass --secret for credentials: the value is encrypted at rest, masked in logs and cannot be read back from the dashboard.

$ rivet env set DATABASE_URL "postgres://[email protected]:5432/storefront" --env production✓ Set DATABASE_URL for production (storefront)$ rivet env set TALLYBIRD_SECRET_KEY --env production,preview --secret? Value: ••••••••••••••••✓ Set TALLYBIRD_SECRET_KEY for production, preview (storefront) · secret

Defaults in rivetlane.toml

Non-secret defaults can live in the repository, next to the code that reads them. Values under [env.preview] override [env] for preview deploys only.

[env]NODE_ENV = "production"LOG_LEVEL = "info" [env.preview]LOG_LEVEL = "debug"

Build time and runtime

Variables are available to your build command and to the running app. Keys prefixed with PUBLIC_ are also inlined into client bundles, so treat them as public.

Pull variables locally

Write the development scope to .env.local so local runs match your deploys. Secrets are included only for members with the Developer role or higher.

$ rivet env pull --env development✓ Wrote 7 variables to .env.local (2 secrets)

Precedence

When the same key is defined in more than one place, the first match wins:

1. A value set with rivet env set for the deploy's scope.
2. The [env.<scope>] table in rivetlane.toml.
3. The [env] table in rivetlane.toml.