Skip to main content

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.

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 variableValue
STRIPE_PUBLIC_KEY{{shared.STRIPE_PUBLIC_KEY}}
API_URLhttps://api.{{shared.BASE_DOMAIN}}
When the project deploys, the runtime container sees: 
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 variableValueResolves to
DATABASE_URL{{@acme-pg-prod.CONNECTION_STRING}}The CONNECTION_STRING variable from the acme-pg-prod project.
INTERNAL_APIhttps://{{@api-gateway.HOSTNAME}}/v1The 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. 
SHARED_API=https://api.{{shared.BASE_DOMAIN}}
Deploying a project that reads ENDPOINT and inherits from the shared environment gives: 
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

Last modified on May 10, 2026