Skip to main content
Live. This area is documented as current, user-reliable behavior.

​
Goal

Help users avoid confusing local runtime variables with broader environment configuration.

​
Prerequisites

  • An account with settings access

​
Workflow

1
Use global env only when the scope really is broader than a single runtime resource.
2
Prefer resource-local configuration when the value only belongs to one app or service.

​
Precedence and usage

  • Global variables are inherited by projects by default.
  • Project-specific variables override global values with the same key.
  • This surface is best for cross-project shared configuration, not one-off runtime secrets.

​
When to use global vs local

Use a global variable when the same value genuinely belongs to many projects — a shared region, a common API base, an org-wide flag. Keep anything that belongs to a single app (its own database URL, its own keys) as project-local config, so an override is intentional rather than accidental. Because project values win on a key clash, a stray global with a common name can quietly shadow a project value if you are not deliberate.

​
Expected result

Env-var scope is chosen more deliberately.

Project environment, domains, and previews

Configure the project surfaces that most often decide whether a deployment works after it builds, including runtime shape, domains, previews, and storage.