Manage where your tests run — bring-your-own cloud machines, device grids, and CI pipelines — as a shared team resource instead of a per-laptop config file.

Infrastructure answers "where do my tests run?" — a question that now has a platform-level answer instead of a file on one person's laptop. It's the first item in the header nav after Test Runs, ahead of Monitoring.

Machines (AWS / Azure / GCP)

Grids (BrowserStack, TestMu AI)

CI (GitHub Actions, GitLab CI)

Placement decides where a run goes

Test run

Bring-your-own, still rolling out

Infrastructure is TestRelic-hosted compute's management plane, not TestRelic-hosted compute itself — there is no TestRelic-run fleet yet. Today it manages execution targets you already own: your own cloud accounts, your own device grid, or your own CI pipeline. Bring-your-own execution targets are a Pro-and-above entitlement and are rolling out gradually — if you don't see Infrastructure in your navigation, it may not be enabled for your organization yet.

Three kinds of execution target

Infrastructure treats these as genuinely different things, not variations on one "runner" concept — the console reflects that difference rather than papering over it:

Machines

Cloud compute you connect directly — AWS, Azure, or Google Cloud — that TestRelic provisions and tears down to run browser tests. Because TestRelic controls provisioning, capacity is a real number: how many machines are up right now.

Grids

Managed device/browser grids — BrowserStack and TestMu AI Cloud Farm — where the vendor hosts the browsers and TestRelic reports against their published concurrency.

CI

Your own GitHub Actions workflow or GitLab CI pipeline (including self-managed GitLab instances), used to run your whole suite rather than a specific browser instance. This is deliberately not treated as a machine or a grid:

Connecting a CI target provisions nothing — no compute is created on your behalf.
Capacity is reported as "parallelism decided by your workflow", not a number TestRelic invents.
Cost is your CI minutes, never estimated by TestRelic.
Disconnecting a CI target deletes nothing on your CI provider.

Before a GitHub Actions or GitLab CI target can be saved, TestRelic verifies the workflow or pipeline can actually be triggered — catching a misconfigured workflow (for example, one missing the required dispatch trigger) at connect time instead of failing every run later.

Connecting a target

From the Infrastructure console:

Open the connect wizard and choose Machines, Grids, or CI.
Provide the credentials or connection details for that target type — a cloud account, a grid API key, or a repository and CI provider.
TestRelic verifies the connection before saving it.
The target appears in your fleet, ready to be selected for runs.

Each connected target has a detail drawer with Overview, Activity, and Settings tabs, plus a Rules panel for controlling how and when it's used.

Credentials and placement

Credentials are stored encrypted, in a store separate from the target's own record — no API response ever returns a credential, only whether one is configured.
Placement — which target a given run actually uses — is decided server-side and recorded on the run, so "where did this run go, and why" has one authoritative answer instead of depending on whichever machine happened to pick it up.
Tearing down a machine only removes resources TestRelic's own record confirms it created — a target's teardown can't reach resources it doesn't recognize as its own.

Why this replaced the per-laptop config

Before Infrastructure, an execution target lived in a local config file and that machine's keychain. In practice, that meant a team could end up connecting the same cloud account multiple times — once per person who set it up — and a runner would silently stop working the day the person who configured it left. Infrastructure makes the target, its credentials, and its rules a property of the workspace, not any one laptop.

Infrastructure