Docs / Running tests
Where tests run
The same spec runs on your laptop, on machines you own, on Invariant's cloud workers or on hardware rigs. Invariant schedules the work and makes it fast; it doesn't require you to buy GPUs from us.
Design preview. These docs describe how Invariant is being built. Commands, output and limits are illustrative until release, and stage tags mark what ships first. See the roadmap.
Run targets
| Target | How it works | Best for | Status |
|---|---|---|---|
| Local | Docker on your machine. invariant run laptop | Inner loop, debugging | MVP |
| Your runners | A small agent on any Linux machine you own (CI runner, GPU workstation, on-prem cluster node) pulls jobs over outbound HTTPS. No inbound ports. | Teams with existing GPUs or strict data rules | MVP |
| Invariant cloud | On-demand CPU and GPU workers in Invariant's cloud account, reading logs from your bucket. | Burst capacity, teams without GPUs | Next |
| Your cloud account | Workers launched in your AWS, GCP or Azure account from an Invariant-managed template. | Data that can't leave your account | Later |
| Hardware rigs | The runner agent on a bench or test robot's host machine. Jobs are queued per rig and never run in parallel on one rig. | Timing, drivers, release sign-off | Later |
Resource profiles
| Profile | Shape | Typical use |
|---|---|---|
cpu-8 | 8 vCPU, 32 GB RAM | Log replay, localization, metrics |
gpu-l4 | 8 vCPU, 32 GB RAM, NVIDIA L4 24 GB (RTX) | Isaac Sim, perception models |
gpu-l40s | 8 vCPU, 64 GB RAM, NVIDIA L40S 48 GB (RTX) | Heavy Isaac Sim scenes, multi-camera rendering |
Simulators that render with ray tracing need RTX-class GPUs. Data-center GPUs without RT cores, such as A100 and H100, can't run Isaac Sim (Isaac Sim requirements). These are the Invariant cloud worker shapes Next, priced on the pricing page. On your own runners, use any labels you like, such as cpu-16, jetson-orin or rig-02.
What makes runs fast
For most robotics tests, the slow part isn't the test. It's starting containers, pulling large images, launching simulators and moving logs. Invariant works on each:
- Image caching and lazy loading. Images are cached per runner and pulled lazily, so multi-gigabyte simulator images don't block a run.
- Warm simulators Next. A simulator instance is reused across runs of the same world, resetting state between runs through the simulator interface instead of restarting.
- Sharding. Scenarios and seeds are spread across workers, and the slowest scenarios start first so the suite finishes sooner.
- Data locality. Logs are cached on the runner and jobs are scheduled where the data already is.
- Baseline reuse Next. If the baseline already ran on the same scenarios and seeds, those runs are reused.
- Early stopping Next. Sequential testing stops adding runs once a result is clear.
Cost controls
- Budgets per suite in GPU-hours, CPU-hours or minutes. When a budget runs out, the suite reports what it covered and what it skipped.
- Spot or preemptible capacity for cloud workers, with automatic retry. A preempted run is an
error, never a failure. - Bring your own compute on any tier. You pay your cloud provider directly for runners in your account.
- Cost per run is recorded in the run record, so reports can show the cost of each suite and each regression caught.