WarpBuild vs RunsOn
WarpBuild and RunsOn both replace GitHub-hosted runners: you change the runs-on label and each job gets a fresh VM that is gone when the job ends. WarpBuild hosts the machines for you, including macOS on Apple M4 Pro, while RunsOn is a stack you install in your own AWS account, where AWS bills the EC2 time at cost.
The companies and products
WarpBuild
WarpBuild sells hosted GitHub Actions runners: you change the runs-on label and your CI jobs run on its machines.
WarpBuild is a CI service, not an agent sandbox. Each GitHub Actions job runs in its own VM on Linux (x86-64 or arm64), Windows or macOS on Apple M4 Pro, and the VM and its disk are destroyed after the build. It also sells remote Docker builders, can run the same runners inside your own AWS, GCP or Azure account, and can host Claude Managed Agents sessions on its stock runners.
RunsOn
RunsOn is self-hosted GitHub Actions runners on AWS: one CloudFormation or Terraform stack in your account, a yearly licence, and compute billed by AWS at cost.
You install RunsOn in your own AWS account, change the runs-on: label in your workflows, and every job then starts on a new EC2 instance that is terminated when the job ends. It covers Linux on x64 and arm64, Windows Server and GPU instances, with caches in S3 and sticky EBS disks. It is a CI runner, a different kind of product from boat, so this page compares the part where they overlap: a machine where an agent or a job does its work.
Which use cases each one fits
For each use case, Battleships prices every sandbox provider on the same workload and sorts them from the cheapest monthly bill up. “94th cheapest of 377” means 93 of the other 376 providers run that workload, with every feature it needs, for less. “With limits” means the provider runs it but misses something, so it is listed after every full match. Open a use case for its whole ranking and what each provider misses.
| Use case and its workload | WarpBuild: price rank | RunsOn: price rank | boat: price rank |
|---|---|---|---|
| Software factory 100 at once · 4 vCPU / 8 GB · 2,200 sessions of 8 h a month A software factory needs machines that keep their work; WarpBuild wipes the disk after each job and RunsOn keeps only the sticky disk, while boat keeps the whole disk. | 269th of 367, with limits $4,343 a month | 122nd of 367, with limits $1,114 a month | 3rd cheapest of 367 $634 a month |
| Always-on AI employees 50 machines 24/7 · 2 vCPU / 4 GB An assistant that never stops does not fit either, because both runners live for one job and GitHub ends self-hosted jobs after 5 days. | 285th of 366, with limits $5,650 a month | 188th of 366, with limits $1,724 a month | 5th cheapest of 366 $657 a month |
| Code interpreter bursts 100 at once · 1 vCPU / 2 GB · 200,000 sessions of 1 min a month Short code runs cost less on RunsOn ($147 a month) than on WarpBuild ($600 a month), but on both each run has to arrive as a GitHub Actions job. | 287th of 345, with limits $600 a month | 229th of 345, with limits $147 a month | 186th of 345, with limits $2,000 a month |
| Sandboxes for your users 300 at once · 2 vCPU / 4 GB · 30,000 sessions of 23 min a month Both start machines for your own GitHub workflows, not for your users, and neither gives a URL into the machine; boat gives each sandbox HTTPS URLs. | 278th of 361, with limits $1,890 a month | 216th of 361, with limits $585 a month | Cheapest of 361 $209 a month |
| RL rollouts 1,000 at once · 2 vCPU / 4 GB · 1,000,000 sessions of 3 min a month | 281st of 360, with limits $9,000 a month | 245th of 360, with limits $2,714 a month | 34th of 360, with limits $2,000 a month |
| Agent evals 250 at once · 4 vCPU / 8 GB · 15,000 sessions of 20 min a month | 294th of 364, with limits $1,440 a month | 251st of 364, with limits $389 a month | 10th cheapest of 364 $200 a month |
| CI runners 40 at once · 8 vCPU / 16 GB · 6,000 sessions of 12 min a month This is what both are built for; RunsOn comes to $432 a month here against $864 on WarpBuild, and boat can run the GitHub runner on its VMs but sells no managed runner service. | 94th cheapest of 377 $864 a month | 58th cheapest of 377 $432 a month | 4th cheapest of 377 $86 a month |
| 24/7 dev boxes 1 machine 24/7 · 4 vCPU / 8 GB A dev box has to stay up and keep its files, and both runners are gone when the job ends; a boat machine stays as long as you want. | 182nd of 368, with limits $226 a month | 158th of 368, with limits $86 a month | 18th cheapest of 368 $26 a month |
| Computer-use agents 50 at once · 4 vCPU / 8 GB · 20,000 sessions of 15 min a month Both runners are headless, so a computer-use agent needs a desktop you set up yourself; boat streams a 60fps Linux desktop with Chromium. | 264th of 369, with limits $1,320 a month | 142nd of 369, with limits $353 a month | 6th cheapest of 369 $200 a month |
| Browser-use agents 50 at once · 2 vCPU / 4 GB · 30,000 sessions of 10 min a month | 280th of 367, with limits $720 a month | 206th of 367, with limits $224 a month | 7th cheapest of 367 $200 a month |
| Scraping & bots (startup scale) 50 at once · 1 vCPU / 2 GB · 100,000 sessions of 3 min a month | 306th of 346, with limits $878 a month | 228th of 346, with limits $205 a month | 6th cheapest of 346 $90 a month |
| Mass scraping & bots (undetectable) 1,000 at once · 1 vCPU / 2 GB · 3,000,000 sessions of 2 min a month | 275th of 338, with limits $17,550 a month | 122nd of 338, with limits $3,539 a month | 71st of 338, with limits $1,800 a month |
| Parallel red teaming 200 at once · 2 vCPU / 4 GB · 5,000 sessions of 30 min a month | 264th of 360, with limits $435 a month | 178th of 360, with limits $157 a month | 2nd cheapest of 360 $200 a month |
| GPU eval jobs 10 at once · 8 vCPU / 32 GB · 500 sessions of 30 min a month | Can't run it | Can't run it | Can't run it |
| macOS agents 5 at once · 4 vCPU / 8 GB · 1,000 sessions of 20 min a month Only WarpBuild fits: it runs macOS on Apple M4 Pro, while RunsOn and boat have no macOS. | 29th of 36, with limits $1,520 a month | Can't run it | Can't run it |
Key features
| Feature | WarpBuild | RunsOn | boat |
|---|---|---|---|
| Kind of product | Hosted GitHub Actions runners and remote Docker builders, in WarpBuild's cloud | Self-hosted GitHub Actions runners, deployed as one stack in your own AWS account | A sandbox API for agents: full VMs you create, stop, fork and delete from code |
| Where it runs | WarpBuild's cloud, or BYOC in your own AWS, GCP or Azure account; a hosted EU region on the enterprise tier | Always in your own AWS account, in the region you pick | Managed by boat in the EU (Germany, Finland, France) |
| Isolation | Each job gets its own VM, destroyed after the build | Each job gets an EC2 instance no other job has used, terminated when the job ends | Full VM with its own kernel on dedicated AMD Ryzen 9 9950X hosts |
| How a machine starts | When a GitHub Actions job asks for it with a runs-on label | When a GitHub Actions job asks for it with a runs-on: label | Any time, by API, CLI or SDK |
| How long a machine lives | One job; GitHub ends self-hosted jobs after 5 days | One job; GitHub ends self-hosted jobs after 5 days | No session cap on paid plans; stop and start it when you like |
| Files after the job | Disk destroyed; cache and disk snapshots (Ubuntu cloud runners, deleted after 15 days) carry state over | Root disk thrown away; one sticky EBS disk per job is snapshotted and restored next job | Whole disk saved every minute and on stop; a stopped sandbox costs nothing |
| Fork | No fork; a later runner can boot from a saved snapshot in 45 to 60 seconds | No fork; every job starts from an AMI | Fork a running sandbox with its disk |
| Docker and nested virtualization | Docker on runners; /dev/kvm only on Linux x86-64, turned on with a label | Docker and root; KVM on compatible Intel x64 families, not arm64 | Docker, root, systemd and /dev/kvm on every machine |
| Desktop and browser | None; runners have no desktop stream | None; headless runners reached over SSM or SSH | 60fps Linux desktop and Chromium, with computer use and browser control |
| Reaching the machine | All inbound traffic blocked; SSH into failed jobs for debugging | SSH from a CIDR range you allow, and SSM; no HTTPS URLs | HTTPS URLs for up to 50 ports, token-protected; raw TCP; SSH |
| Coding agents and keys | Hosts Claude Managed Agents sessions on stock runners; GitHub secrets are passed into the runner | Bedrock through the instance role; Copilot's coding agent can use a runner | Claude Code, Codex, OpenCode and more preinstalled, with a prompt, steer and events API; a credentials proxy keeps real keys out |
| Operating systems and chips | Linux x86-64 and arm64, Windows Server, macOS on Apple M4 Pro; no GPUs | Linux x64 and arm64, Windows Server, NVIDIA and AMD GPUs; no macOS | Linux on x86-64 only, CPU only |
| How many at once | Unlimited on Linux and Windows; higher macOS concurrency through support | Your AWS account's quotas; launches paced at about 2 EC2 calls per second by default | Set by your plan, with limits on starts per minute, hour and day |
| Network rules | With BYOC, your security-group egress rules and static egress IPs | Your own AWS Network Firewall policy or security groups; static egress IPs through NAT | Open internet, no provider-side allowlist |
Every feature Battleships tracks (43)
| Feature | WarpBuild | RunsOn | boat |
|---|---|---|---|
| Full VM (own kernel) | Yes | Yes | Yes |
| Docker inside | Yes | Yes | Yes |
| Nested virtualization | Yes | Yes | Yes |
| Root | Yes | Yes | Yes |
| Systemd | Not published | Not published | Yes |
| Desktop GUI | No | No | Yes |
| Browser | No | No | Yes |
| Computer-use API | No | No | Yes |
| SSH | Yes | Yes | Yes |
| Persistent disk | No | Yes | Yes |
| Pause/resume | No | Yes | Yes |
| Automatic snapshots | No | Yes | Yes |
| Fork/clone | No | No | Yes |
| Live fork (no pause) | No | No | Yes |
| Memory fork | No | No | No |
| Custom image (Docker or snapshot) | Yes | Yes | Yes |
| ≥24 h sessions | Yes | Yes | Yes |
| Idle auto-stop | Yes | Yes | No |
| Wake on request | Yes | Yes | No |
| HTTPS preview URLs | No | No | Yes |
| Raw TCP inbound | No | No | Yes |
| Public IPv4 | No | Yes | No |
| Egress allowlist | Yes | Yes | No |
| Secret proxy | No | No | Yes |
| Secret proxy for any API | No | No | Yes |
| Preinstalled agents | Yes | No | Yes |
| Agent harness API | No | No | Yes |
| MCP server | Yes | No | No |
| GPU | No | Yes | No |
| Windows | Yes | Yes | No |
| Arm64 | Yes | Yes | No |
| Self-hosting | No | Yes | No |
| BYOC | Yes | Yes | No |
| Open source | No | No | No |
| Scoped API keys | Yes | Not published | Yes |
| Spend limits | Not published | Not published | Yes |
| Usage per sandbox (API) | Yes | No | Yes |
| Audit logs | Not published | Not published | No |
| SSO | Yes | No | No |
| SOC 2 | Yes | No | No |
| HIPAA | No | No | No |
| EU data residency | Yes | Yes | Yes |
| Zero data retention | Not published | Not published | Yes |
Performance
There is no comparable measurement for WarpBuild or RunsOn: neither is in the StarSling hpc-sandbox-benchmarks run where boat did 26.69 Node.js build-and-test runs per second at 4 vCPU / 8 GB. Both publish their own speed claims against GitHub-hosted runners, and RunsOn's speed depends on the EC2 family you pick.
Node.js build-and-test loop at 4 vCPU / 8 GB, higher is better. Measured with the open hpc-sandbox-benchmarks suite. WarpBuild and RunsOn have no published run in this suite yet, so there is no like-for-like number to compare.
Pricing in five scenarios
Each bill is priced from the providers' public price lists by the open Battleships engine, with the cheapest plan that runs the scenario.
| Scenario | WarpBuild, a month | RunsOn, a month | boat, a month |
|---|---|---|---|
| One coding agent, workdays 4 vCPU / 8 GB, 50 GB disk, 8 hours a day, 22 days a month, files kept between days | $57 · Pay as you go · with limits | $61 · Starter · with limits | $20 · $20/mo |
| One agent that never stops 4 vCPU / 8 GB, 50 GB disk, running 24/7 all month | $237 · Pay as you go · with limits | $159 · Starter · with limits | $26 · $20/mo |
| 50 agents in parallel 50 machines of 4 vCPU / 8 GB at once, 8-hour sessions, 1,100 sessions a month, Docker inside | $2,851 · Pay as you go · with limits | $1,597 · Starter · with limits | $317 · $20/mo × 3 seats |
| Sandboxes for your users 2 vCPU / 4 GB, 30,000 sessions of 10 minutes a month, up to 300 at once | $810 · Pay as you go · with limits | $515 · Starter · with limits | $200 · $100/mo × 2 seats |
| 1,000 short jobs at once 2 vCPU / 4 GB, 1,000 at once, 3 minutes each, 200,000 jobs a month | $1,800 · Pay as you go · with limits | $1,103 · Starter · with limits | $2,000 · $2000/mo · with limits |
WarpBuild: WarpBuild bills runners per minute while a job runs, with no plan fee, from $0.003 a minute for 2 vCPU on arm64; Windows costs twice the Linux x86-64 rate and macOS $0.08 a minute. Cache, snapshot storage and restores are extra, and BYOC runners cost $0.002 a minute on top of your own cloud bill.
RunsOn: AWS bills the EC2 instances and EBS disks on your own AWS bill at spot or on-demand prices with no markup, and S3 cache traffic and data transfer are extra. RunsOn charges one licence a year per company, from EUR 300 or $350 for under 50,000 jobs a month.
RunsOn: You pick a monthly plan from $20, and all of it becomes usage credit spent per second on running sandboxes. A stopped sandbox costs nothing and keeps its disk.
Limits in those scenarios
None of the five agent scenarios fits WarpBuild or RunsOn as sold, because both start a machine only for a GitHub Actions job and end it with the job, and GitHub ends self-hosted jobs after 5 days. WarpBuild keeps no disk at all, and RunsOn keeps only the sticky disk, priced only up to 30 GiB in our model. WarpBuild's 300 and 1,000 machine counts are not confirmed, and RunsOn's real limit is your AWS account's quotas. On boat, the 1,000-job burst is limited by starts per minute and per day, so it gets queued even on the $2,000 plan.
| Scenario | WarpBuild | RunsOn | boat |
|---|---|---|---|
| One coding agent, workdays |
|
| None that bite |
| One agent that never stops |
|
| None that bite |
| 50 agents in parallel |
|
| None that bite |
| Sandboxes for your users |
|
| None that bite |
| 1,000 short jobs at once |
|
|
|
Which one should you use?
Use WarpBuild when
you want faster GitHub Actions without running anything yourself, or you need macOS runners, or your cloud is GCP or Azure.
- macOS on Apple M4 Pro. Useful if you build iPhone or Mac apps: WarpBuild runs macOS 14, 15 and 26 runners, and RunsOn has no macOS.
- Nothing to run yourself. Useful if you want faster CI without an AWS stack to look after: WarpBuild hosts the runners, with unlimited Linux and Windows concurrency.
- Any of three clouds. Useful if your company is on GCP or Azure: WarpBuild's BYOC runs in AWS, GCP or Azure, while RunsOn is AWS only.
Use RunsOn when
you want GitHub Actions runners in your own AWS account at AWS cost, including Windows, arm64 or GPU jobs, with your code never leaving the account.
- Compute at AWS cost. Useful if CI minutes are a big bill: AWS bills the EC2 time with no markup, and RunsOn charges one flat licence a year.
- GPUs and big machines. Useful for jobs that need NVIDIA or AMD GPUs, from T4 up to H200, or any EC2 size up to 96 vCPU.
- Everything stays in your account. Useful when code, secrets and logs must never leave your AWS account; RunsOn only gets a licence check and one event per job.
Where boat fits
If what you are really running is CI, pick between WarpBuild and RunsOn; boat is not a managed runner service. If what you are really running is agents, both make you wrap the agent in a GitHub Actions job on a machine that disappears afterwards. boat gives each agent a full VM you start from code, keep for as long as the work needs, fork, and reach over HTTPS.
A machine that keeps its work
Both runners end with the job, and GitHub stops self-hosted jobs after 5 days. WarpBuild snapshots are billed per hour and deleted after 15 days, and RunsOn brings back only the sticky disk, so packages installed elsewhere are gone.
A way into the machine
WarpBuild blocks all inbound traffic, and RunsOn is reached only over SSM or SSH, so an agent's app preview or browser task needs your own tunnels or load balancer. boat gives HTTPS URLs on 50 ports, raw TCP and a 60fps desktop.
Agents driven from outside, keys kept out
WarpBuild hosts only Claude Managed Agents, and RunsOn offers Bedrock and Copilot's coding agent; any other agent you start from workflow steps, with its keys as secrets on the machine. boat preinstalls the agents and keeps real keys in a proxy.
Use boat when you need machines for agents rather than CI jobs: a full VM you start by API, keep with its whole disk, fork, reach over HTTPS and drive with built-in coding agents. Compare it one to one: boat vs WarpBuild and boat vs RunsOn.
Questions people ask
Is WarpBuild cheaper than RunsOn?
Usually not in our model. For CI runners RunsOn comes to $432 a month against $864 on WarpBuild, because AWS bills the EC2 spot time at cost and RunsOn adds a flat yearly licence. WarpBuild is a little lower for one coding agent on workdays, at $57 against $61, and boat comes to $20 for that.
Which is faster, WarpBuild or RunsOn?
There is no comparable measurement. Neither is in the public benchmark where boat did 26.69 runs per second, and both compare themselves with GitHub-hosted runners. RunsOn's speed depends on which EC2 family you pick.
Does RunsOn support macOS like WarpBuild?
No. RunsOn covers Linux on x64 and arm64, Windows Server and GPU instances, but not macOS. WarpBuild runs macOS 14, 15 and 26 on Apple M4 Pro. boat runs Linux only.
Can WarpBuild and RunsOn run Docker?
Yes, both run Docker on their runners. Nested virtualization is narrower: WarpBuild offers /dev/kvm on Linux x86-64 with a label, and RunsOn offers KVM on compatible Intel x64 families, not arm64. boat has Docker, root, systemd and /dev/kvm on every machine.
Can I use WarpBuild or RunsOn as a sandbox for AI agents?
Only inside GitHub Actions. WarpBuild can host Claude Managed Agents sessions and RunsOn supports Bedrock and Copilot's coding agent, but each machine lives for one job, at most 5 days, and neither has an API to create, keep or fork a sandbox. boat is built for that.
Where does my data run?
RunsOn always runs in your own AWS account and region, and your code, secrets and logs are never sent to RunsOn. WarpBuild runs in its own cloud, with a hosted EU region on its enterprise tier, or in your AWS, GCP or Azure account. boat runs only in the EU (Germany, Finland and France).
Try boat
Install the CLI, then run boat new.
7-day free trial