Skip to main content
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.

​
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:

​
Headers

Headers are the right place for an API token, a preview-deployment bypass header, or a feature flag.
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.

​
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, 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

production

The project’s own address. Scheduled nightly. Alerts to Slack.

staging

Staging base URL plus a bypass header. Run on demand.

preview

Base URL supplied per run by the GitHub PR bot, plus the same bypass header.