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

# Reference shared and cross-project variables

> A variable's value can include references to other variables.

A variable's value can include references to other variables. References resolve at deploy time, so the running container sees the final string, not the `{{...}}` syntax.

Two kinds of references exist:

* `{{shared.NAME}}` pulls a value from a **shared environment** the project inherits from.
* `{{@project-slug.NAME}}` pulls a value from another project in the same workspace.

References are useful when the same value (an API base URL, a feature-flag key, a third-party token) needs to be in many projects without copy-pasting and rotating in N places.

## Shared variables

A workspace can have a **shared environment**, a set of variables defined once and inherited by any project that opts in.

When a project inherits from a shared environment, you can reference any of its variables from within a project-level variable using `{{shared.NAME}}`.

### Set up shared variables

1. In the dashboard, open the project.
2. Go to **Environments** (the tab next to **Environment**).
3. Edit the active environment and set **Inherit from** to a shared environment.

Now the project's variables can reference shared values:

| Project variable    | Value                                |
| ------------------- | ------------------------------------ |
| `STRIPE_PUBLIC_KEY` | `{{shared.STRIPE_PUBLIC_KEY}}`       |
| `API_URL`           | `https://api.{{shared.BASE_DOMAIN}}` |

When the project deploys, the runtime container sees:

```bash theme={null}
STRIPE_PUBLIC_KEY=pk_live_...
API_URL=https://api.example.com
```

If the shared variable doesn't exist, the reference is left as-is in the resolved value (`{{shared.MISSING}}` stays literal). The deployment logs a warning so you can spot it.

## Cross-project references

You can pull a variable from another project in the same workspace by prefixing the slug with `@`:

| Project variable | Value                                  | Resolves to                                                       |
| ---------------- | -------------------------------------- | ----------------------------------------------------------------- |
| `DATABASE_URL`   | `{{@acme-pg-prod.CONNECTION_STRING}}`  | The `CONNECTION_STRING` variable from the `acme-pg-prod` project. |
| `INTERNAL_API`   | `https://{{@api-gateway.HOSTNAME}}/v1` | The hostname from the `api-gateway` project.                      |

Cross-project references follow these rules:

* **Same workspace only.** A team project can only reference other team projects (under the same team). A personal project can only reference your other personal projects. There's no cross-workspace reference.
* **Slug-based.** The `@` prefix is the project's slug (the lowercase, dash-separated form of its name). Brimble normalizes the slug before lookup, so casing doesn't matter.
* **One-way and resolved at deploy time.** If you change the source variable, the consuming project doesn't redeploy automatically, its env stays at the previous value until it redeploys.

## Combining and chaining references

References can be embedded in a longer string and can chain, a referenced value that itself contains a reference will resolve, too.

```bash theme={null}
SHARED_API=https://api.{{shared.BASE_DOMAIN}}
```

Deploying a project that reads `ENDPOINT` and inherits from the shared environment gives:

```bash theme={null}
ENDPOINT=https://api.example.com/v1
```

The resolver guards against cycles, if `A` references `B` and `B` references `A`, both resolve to their last-known string instead of looping.

## Limits

* References don't escape `{{...}}`, there's no syntax for "literal `{{shared.X}}` in a value." If your real value contains those braces, refactor or store the value in a way that doesn't need them at deploy time.
* References resolve every deploy. The resolver caches per request, so a deploy with many references is fast, but it's not free. Don't fan out into hundreds of references unless you need to.
* The resolver uses your secret store as the source of truth, references read live values, not snapshots.

## Next steps

* [Manage environment variables](/environments/environment-variables), adding, editing, and inheriting variables.
* [Environments](/environments/overview), the inheritance model.