# Environments Run the same test against staging, production, or any other copy of your site, each with its own base URL and variables. An environment is a named target for your runs, such as Staging or Production. It has a base URL and a set of variables, and it belongs to the whole workspace. Pick an environment when you start a run and the test runs against that site with those values, without you editing a single step. One test can cover staging before a release and production after it. Create environments from Environments in the sidebar. Each one needs a unique name. The base URL and the variables are both optional. Environments are available on every plan. ## How the base URL is applied The base URL replaces the scheme, host, and port of the test's target URL. The path, query string, and fragment of the target URL are kept. If the base URL has a path of its own, that path is put in front of the test's path. The base URL must start with http:// or https:// and cannot contain a username, password, query string, or fragment. ```text Test target URL: https://www.example.com/checkout?plan=pro Environment base: https://staging.example.com:8443/preview Run opens: https://staging.example.com:8443/preview/checkout?plan=pro ``` Navigate steps that use an absolute URL on the same origin as the test's target URL are rewritten the same way. A navigate step to a different site, such as a payment provider or an identity provider, is left alone. For an API test, the rewritten target URL is the base that relative request paths resolve against. If the test has no target URL, the run uses the base URL as it is. Leave the base URL empty to keep each test's own URL and only override variables. ## Variables and precedence An environment can define [variables](https://testsnag.com/docs/building-blocks/variables.md) that override everything else during runs in that environment. When the same name is defined in several places, the most specific one wins, in this order: 1. Global variables, the workspace defaults. 2. Block variables, the defaults a block carries for its own steps. 3. Test variables, set in the recorder. 4. Environment variables, which win over all of the above. A typical setup keeps {{username}} and {{password}} as test variables for local work, then gives Staging and Production their own values for the same names. Steps never change, only the environment you pick. ## Secret values Mark an environment variable secret for passwords and API keys. Once saved, a secret value is never sent back to your browser, so the edit dialog shows that a value exists without showing it. To change it, type a new value. Leaving it untouched keeps the stored one. Secret values are masked in run results, and AI assistants connected over MCP cannot read them either. ## Enabling an environment on a test A test only runs in environments you have enabled for it. Open the test settings, find the Environments section on the General tab, tick the environments it should support, and save. A test with no enabled environments behaves exactly as it did before environments existed. The Environments page lists which tests use each environment. ## Choosing an environment for a run Once a test has at least one enabled environment, its Run button becomes a dropdown. The Tests list, the recorders, and the API builder all use the same menu: - **No environment**: runs with the test's own URL and variables. - **One environment**: runs once against that environment. - **All enabled**: shown when more than one environment is enabled. Starts one run per enabled environment. > **Note:** Each environment run uses one run from your monthly allowance. Quota is all or nothing: if you choose All enabled with three environments and only two runs are left, no runs start. ## The recorder picker The web, API, and mobile recorders have an environment picker in the header. It sets the environment for the recording session, including step previews and replays, and starts on the test's first enabled environment. Choose No environment to work against the test's own URL and variables. A live run from the API builder runs in one environment at a time. Choosing All enabled there starts one background run per environment instead and opens the test's runs list in a new tab. ## Schedules and suites Test schedules and suites both have an environment setting with three options: No environment, Selected, or All enabled. A test schedule can only pick from the environments enabled for that test, and each scheduled run starts one run per environment. If none of the chosen environments is still enabled for the test when the schedule comes due, nothing runs. A suite starts one suite run per environment, and each suite run only includes the tests enabled for that environment. A test that is not enabled for Production is simply left out of the Production suite run rather than failing it. See [Suites](https://testsnag.com/docs/running-tests/suites.md) for the details. ## Webhooks, the API, MCP, and GitHub - **Trigger URLs**: add ?environment=Staging or ?environments=all to the query string. An unknown environment returns a 422 and starts nothing. An environment field in the JSON body is recorded as metadata but does not select an environment. See [webhook triggers](https://testsnag.com/docs/running-tests/webhook-triggers.md). - **Public API and MCP**: the public API start-run endpoint accepts environment or environments. Over MCP, run_test, run_suite, and trigger_schedule_now accept the same parameters, as an id, a name, a list, or all, and assistants can list, create, update, and delete environments. See [AI clients and MCP](https://testsnag.com/docs/running-tests/ai-clients-mcp.md). - **GitHub deployments**: when the deployment environment name matches an environment enabled for the test, ignoring case, the run uses that environment. A deployment to "staging" runs in your Staging environment. See [Running tests from GitHub](https://testsnag.com/docs/notifications/github-actions.md). ## Results and analytics Every run made in an environment shows an environment badge on the run page, and the Runs list can be filtered by environment, including No environment. Analytics has the same filter, and flakiness is measured per test per environment, so a test that is stable on Production but flaky on Staging shows up as a Staging problem. Outbound webhook payloads include run.environment, and issue trackers keep one open issue per test per environment. ## What a run freezes Each run copies its environment's name, base URL, and variables at the moment it starts. Editing the environment afterwards does not change runs that are already queued or running, and deleting an environment stops tests, schedules, and suites from targeting it while past runs keep the environment name they ran with. A schedule or suite set to Selected that loses its last selected environment switches to No environment.