> ## Documentation Index
> Fetch the complete documentation index at: https://bruno-a6972042-mintlify-53b1251c.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.
# Environment Variables
Environment variables are variables that are scoped to an environment, such as local development or production. They are useful for storing variables that can be re-used across the collection that are different depending on the environment. An example would be the host url of the server you want to test.
## Creating an Environment Variable
1. Go to environments (top right) and press **No environment**.
2. If there are no environments, you will be prompted to create one.
3. Add your variable name, value, and an optional description for what the variable represents.
4. Save your changes.
## Using an Environment Variable
Just like other variables you can use the `{{varName}}` syntax to use an environment variable in a request. On the top-right, you can see which environment you are currently using and select a different one.
## Searching environment variables
When working with a large number of environment variables, you can use the search feature to quickly find specific variables.
1. Open your environment settings.
2. Click the search icon in the environment details panel.
3. Type your query to filter variables by name or value.
The search filters the variable list in real time. If you click on a variable row while searching, that row stays visible even if it no longer matches the query, so you can edit it without losing your place. The row unpins automatically after a short delay.
The search feature is also available for [global environment variables](/variables/global-environment-variables).
## Default environment
You can set a **default environment** for a collection so teammates and new sessions start with the right environment selected, without picking it manually every time.
The default is stored in the collection > **Presets** and travels with the collection when you share, export, or import it.
### Set a default environment
1. Go to **Collection > Presets** tab.
2. Select the collection environment you want as the default
3. Click **Save** button.
Bruno marks that environment as the collection default and saves it to the collection config.
### How the default is applied
| Situation | What Bruno uses |
| ----------------------------------------------------------------------------------------------- | ---------------------------------------------------------- |
| You open a collection and already have a recently selected environment saved in the UI snapshot | The saved selection (default does **not** override it) |
| You open or import a collection with no recent environment selected | The configured default environment |
| You run requests in the app with no environment selected | The default environment, if one is configured |
| You run the collection with Bruno CLI and omit `--env` | The collection's default environment, if one is configured |
The default environment is shareable with the collection. Setting it updates collection config (`bruno.json` or OpenCollection YAML), not only your local UI state.
### Persistence and export
The default environment is persisted in the collection configuration and included when you export the collection:
* **Bruno native** - stored in `bruno.json`
* **OpenCollection YAML** - stored in `opencollection.yml`
On import or when opening a collection, if no recent environment is selected from the UI snapshot, Bruno falls back to this configured default.
### Example config
After you set **Local** as the default, the collection config includes that choice. Exact field placement depends on format:
```json title="bruno.json" theme={null}
{
"version": "1",
"name": "my-api",
"defaultEnvironment": "Local"
}
```
```yaml title="opencollection.yml" theme={null}
opencollection: 1.0.0
info:
name: my-api
extensions:
bruno:
defaultEnvironment: Local
```
## Environment inheritance
An environment can inherit variables from another environment in the same scope and override only the names it redefines. Use this to define shared values (host, common headers, feature flags) in a base environment, then layer environment-specific overrides on top.
Inheritance is supported for collection environments and workspace (global) environments, in both `.bru` and `.yml`, and applies in the app and in Bruno CLI.
### Set a parent environment
1. Open the environment you want to extend from another.
2. In the environment editor, choose a **parent environment** from the same scope.
3. Save.
Inherited variables appear in a collapsible **Inherited** section above the environment's own variables. Each inherited row shows its source environment and is read-only. To change an inherited value, redefine the variable in the current environment; the override wins at resolve time.
Bruno warns you when a parent environment is missing or excluded from the collection so the reference is not silently dropped. The unresolved parent name is preserved on save, so re-adding the parent restores inheritance.
### Resolution and precedence
* Variables defined in the current environment override same-named variables inherited from a parent.
* Inheritance resolves at request time, so requests, scripts, collection runs, code generation, and CLI runs all see the merged variables.
* A single parent is declared as one name; multiple parents can be declared as a list (later entries take precedence over earlier ones).
* Secret values and unchanged inherited values are not rewritten to the child environment file on save.
### Declaring `extends` in files
The parent reference is stored in the environment file so it travels through import, export, rename, and version control.
```bash title="production.bru" theme={null}
extends: base
vars {
host: https://api.example.com
}
```
Declare multiple parents with an array:
```bash theme={null}
extends [
base,
shared
]
vars {
host: https://api.example.com
}
```
Parent names may contain spaces. Wrap a name in double quotes if it contains a comma or brackets. A parent name cannot contain `/`.
```yaml title="production.yml" theme={null}
name: production
extends: base
variables:
- name: host
value: https://api.example.com
enabled: true
secret: false
```
Declare multiple parents with a list:
```yaml theme={null}
name: production
extends:
- base
- shared
variables: []
```
## Using the ./environment directory
Environment variables are synced with the `/environments` directory inside your collection. You can also create and manage environments there.
Each environment is saved in a `.bru` file or a `.yml` file depending on the format in use.
**BRU format** (`local.bru`)
```bash theme={null}
vars {
@description('''Base URL for the local server''')
host: http://localhost:8787
@description('''
JWT token obtained after login.
Expires in 24 hours.
''')
token: abc123
noDesc: plain-value
}
```
Use `@description` before a variable to document what it represents. Descriptions are optional, always go on the line immediately before the variable, and support multiline text using triple quotes (`'''`).
**YAML format** (`production.yml`)
```yaml theme={null}
name: Production
variables:
- name: host
value: https://api.example.com
enabled: true
secret: false
description: Single-line description
- name: token
value: abc123
enabled: true
secret: false
description: |-
Multiline description.
Supports multiple lines.
Third line here.
- name: apiKey
value: ''
enabled: true
secret: true
description: Secret API key stored encrypted
- name: disabledVar
value: old-value
enabled: false
secret: false
description: This variable is disabled
- name: ''
value: ''
enabled: true
secret: false
description: Orphaned description becomes an empty-name row
```
The `description` field is optional. Use the block scalar `|-` for multiline descriptions to preserve line breaks. A variable with an empty `name` and `value` is treated as an orphaned description row in the UI.
For information on importing and exporting environment variables, see the [Import/Export Environments](/get-started/import-export-data/import-export-environments) guide.