Compare
Compare runners on your own jobs.
Price lists don’t run your test suite. These are the six things worth checking when you weigh Bowse against any runner or sandbox — and a one-week test that settles it.
Matched hardware
Compare a 2 vCPU · 8 GB runner with another 2 vCPU · 8 GB runner. Cheaper per minute on a smaller box isn’t a saving if the job runs twice as long.
Whole-job cost
Count boot, setup, cache restore, and cleanup — not just your steps. Bowse meters from boot to shutdown, so the bill matches the wall clock.
Cache behaviour
Check that actions/cache, setup-* caches, and Docker layer caches restore on the new runner. A cold cache can hide a fast machine.
Isolation
Ask what separates your job from the next customer’s: a shared kernel with namespaces, or a separate microVM per job.
Billing model
Per-minute or per-second, seats, platform fees, minimums, and what a stopped sandbox costs when nothing runs.
Agent fit
For agent sandboxes: does the disk survive a stop, is there a browser and desktop, can you publish a port, and is there an MCP server?
- 01Pick one job you run often — the main test suite is usually it.
- 02Run it on your current runner and on a matched Bowse size for the same week.
- 03Compare median duration and minutes × rate. The estimator does the arithmetic.
Run the test on one job.
Switch a single job to runs-on: bowse for a week and compare the numbers yourself.