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

# Environments

> Run the same test against staging, production, or a pull-request preview.

An environment is a named override applied to a run: a different base address,
extra HTTP headers, and cookies.

The point is that one saved test covers every deployment you have. You do not
keep a staging copy of a production test.

## Creating one

Project settings → **Environments**.

| Field        | Notes                                                                       |
| ------------ | --------------------------------------------------------------------------- |
| **Name**     | How you pick it at run time: `staging`, `production`, `preview`.            |
| **Base URL** | Replaces the project's address for this run. Same private-host rules apply. |
| **Headers**  | Sent with every request the browser makes.                                  |
| **Cookies**  | Set on the browser context before the run starts.                           |
| **Default**  | One environment can be the project's default.                               |

## Using one

Pick it when triggering a run: from the app, from a schedule, or via the API
and CLI. Without one, the run uses the project's own address.

For a one-off address change and nothing else, a base-URL override is simpler:

```bash theme={null}
testorim run <procedure-id> --base-url https://preview-42.staging.example.com
```

## Headers

Headers are the right place for an API token, a preview-deployment bypass
header, or a feature flag.

<Warning>
  Some headers are refused: `Authorization`, `Cookie`, `Host`,
  `Metadata-Flavor`, and any `X-Forwarded-*`. They either let a request escape
  the address the project is pinned to, or forge an identity the browser should
  be establishing itself.

  For an authenticated session, use a **cookie** or a
  [login-setup test](/test-creation/reusable-flows#login-and-auth-mode).
</Warning>

## Cookies

A cookie's domain must match the project's base address host. You cannot set a
cookie for a site the project does not test.

Cookies are **encrypted at rest**, which makes them the correct place for a
session token, unlike [variables](/projects/variables-and-secrets), which are
plain configuration.

A project may hold up to 50 cookies per environment.

## Other per-run overrides

Beyond address, headers and cookies, an environment can pin the browser's
timezone, locale and geolocation, so a date-formatting or currency test is
checking the site rather than the machine it ran on.

## A typical setup

<CardGroup cols={3}>
  <Card title="production" icon="globe">
    The project's own address. Scheduled nightly. Alerts to Slack.
  </Card>

  <Card title="staging" icon="flask-conical">
    Staging base URL plus a bypass header. Run on demand.
  </Card>

  <Card title="preview" icon="git-pull-request">
    Base URL supplied per run by the GitHub PR bot, plus the same bypass
    header.
  </Card>
</CardGroup>


## Related topics

- [Create a project](/getting-started/create-a-project.md)
- [Authentication and API keys](/developers/authentication.md)
- [CLI](/developers/cli.md)
- [FAQ](/resources/faq.md)
- [Support](/resources/support.md)