> ## Documentation Index
> Fetch the complete documentation index at: https://docs.stackshift.cloud/llms.txt
> Use this file to discover all available pages before exploring further.

# Global environment variables

> Understand the global env surface and how it differs from project- or stack-specific runtime configuration.

<Tip>
  **Live.** This area is documented as current, user-reliable behavior.
</Tip>

## Goal

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

## Prerequisites

* An account with settings access

## Workflow

<Steps>
  <Step>
    Use global env only when the scope really is broader than a single runtime resource.
  </Step>

  <Step>
    Prefer resource-local configuration when the value only belongs to one app or service.
  </Step>
</Steps>

## 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

<Check>
  Env-var scope is chosen more deliberately.
</Check>

## Related guides

<CardGroup cols={2}>
  <Card title="Project environment, domains, and previews" href="/projects/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.
  </Card>
</CardGroup>