Test the commit, not whatever happens to be deployed.

For any branch, pull request or commit the platform stands up a real copy of your application: cloned from your repository, built the way you say, patched for testability, seeded with data, health-checked, and driven over a private connection. When the run ends the environment is gone.

In the dashboard
Environments · Projects
Feature specs
33, 51, 62, 67
Testing a shared staging URL compared with testing an isolated environment
Testing a shared staging URLTesting an isolated environment
Whatever was deployed last, by anyoneExactly the commit under review, pinned by SHA
One team's test data trampled by another'sFresh seed per environment, or a project reset script between runs
Sign-in through the real identity providerA patch swaps in a test-auth bypass; the real provider is untouched
Outbound email goes to real inboxes, or nowhereA mail catcher runs beside the app and the agent reads it
A failed deploy blocks every testerA failed boot blocks one job, with the app's own log attached

You describe the app once.

The environment definition is part of the project: how to start the app, which port answers, what healthy means, how long to wait, which patches to apply, which uploads to place on the box, what memory, CPU and disk it needs. Three run modes cover most stacks: native install on a plain box, docker compose, or a prebuilt image.

Patches are ordered unified diffs applied to the throwaway clone, so you never fork your app for testing. When upstream moves and a patch no longer applies, the run fails fast with a machine-readable reason, and an agent task can repair the patch, prove a box boots with it, and resubmit the job.

Project → isolated environment (IsNull fixture)
enabled:     true
ref:         main            # PR suites override with the head SHA
startup:     docker compose up --build
port:        8080
healthcheck: GET / → 200
patches:
  - add-patched-page.diff  # test-only page applied to the clone
resources:   configured per project
The Environments view listing live isolated environments with ref, age, health and a tear-down action.

What happens around the box.

  • Private by default: each environment runs in its own namespace with default-deny networking and mutual TLS on the worker-to-app hop; only the assigned worker can reach it.
  • Secure context for real auth: the worker reaches the app over a deterministic loopback port, so Web Crypto, MSAL and magic-link redirects behave as they do in production.
  • Reuse when it is safe: a branch's environment stays warm for its next run after a liveness probe and, if the project defines one, a reset script that returns the data to seeded state.
  • A ledger, always: no box exists without a record; a boot-time and periodic reconcile tears down anything the store no longer knows.
  • Dependency cache: keyed by lockfile content, so the second boot of a monorepo skips the install.
  • Watch it live: a gateway link from the Environments view lets a developer open a private box in their own browser while a run is on it.

Where it stops today

  • The cluster backend runs on the platform's own Kubernetes estate. "Bring your own cluster" is not a supported story yet.
  • A monorepo build is minutes, not seconds. Warm reuse and the dependency cache help; the first boot of a new commit does not get faster than the app's own build.
  • Agent-triggered mid-run reset of a shared environment is switched off in production pending a durability fix; the between-runs reset script is what ships.
  • Uploads and patches are copied into preview deployments from main at boot; a project created only on a preview starts empty.