WarpBuild vs GitLab.com hosted runners

Both are CI services that give each job a fresh VM and delete it afterwards. WarpBuild plugs into GitHub Actions and lets a job run for days, while GitLab.com hosted runners serve GitLab pipelines and stop every job at 3 hours.

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.

GitLab.com hosted runners

GitLab.com hosted runners are the machines that run GitLab CI/CD jobs for projects on GitLab.com, paid for in compute minutes.

This is a CI service, not a sandbox API. Each job gets a new VM on Google Cloud (Linux and Windows) or on AWS Mac hardware (macOS), with passwordless sudo, and the VM is deleted right after the job. It is built for building, testing and deploying the code in a GitLab project, and GitLab's Duo Agent Platform also runs Claude Code and Codex agents as CI/CD jobs on these runners.

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 workloadWarpBuild: price rankGitLab.com hosted runners: price rankboat: 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 checkout and caches between tasks, and both wipe the VM after every job.
269th of 367, with limits
$4,343 a month
347th of 367, with limits
$14,454 a month
3rd cheapest of 367
$634 a month
Always-on AI employees
50 machines 24/7 · 2 vCPU / 4 GB
An assistant that lives all month does not fit either: GitHub stops a WarpBuild job after 5 days, and GitLab stops a job after 3 hours.
285th of 366, with limits
$5,650 a month
353rd of 366, with limits
$21,858 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
287th of 345, with limits
$600 a month
320th of 345, with limits
$1,896 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
Sandboxes for your users need a URL into each machine, and both block inbound traffic to their runners.
278th of 361, with limits
$1,890 a month
331st of 361, with limits
$6,133 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
318th of 360, with limits
$29,762 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
330th of 364, with limits
$4,758 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
Both fit: WarpBuild if your code and workflows live on GitHub, GitLab.com hosted runners if your pipelines live in a GitLab project; boat suits CI that needs a warm disk or jobs longer than 3 hours.
94th cheapest of 377
$864 a month
128th cheapest of 377
$2,089 a month
4th cheapest of 377
$86 a month
24/7 dev boxes
1 machine 24/7 · 4 vCPU / 8 GB
A dev box needs a disk that stays; WarpBuild carries state only through cache and disk snapshots, and GitLab only through cache and artifacts.
182nd of 368, with limits
$226 a month
358th of 368, with limits
$805 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 are headless, while boat streams a 60fps desktop with Chromium and computer use on every machine.
264th of 369, with limits
$1,320 a month
342nd of 369, with limits
$4,278 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
144th of 367, with limits
$2,118 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
143rd of 346, with limits
$2,854 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
319th of 338, with limits
$58,429 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
87th of 360, with limits
$1,383 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
GitLab has a Linux runner with an NVIDIA T4 on Premium and Ultimate; WarpBuild and boat have no GPUs.
Can't run itCan't run itCan't run it
macOS agents
5 at once · 4 vCPU / 8 GB · 1,000 sessions of 20 min a month
Both have hosted macOS: WarpBuild on Apple M4 Pro, GitLab on Apple silicon in beta for Premium and Ultimate; boat runs Linux only.
29th of 36, with limits
$1,520 a month
24th of 36, with limits
$1,069 a month
Can't run it

Key features

FeatureWarpBuildGitLab.com hosted runnersboat
Kind of productGitHub Actions runners, picked with a runs-on labelGitLab CI/CD runners, used by a project's .gitlab-ci.ymlSandbox API: create, stop, fork and reach machines from your code
IsolationIts own VM per job, destroyed after the buildNew VM per job on Google Compute Engine, deleted right afterFull VM with its own kernel on dedicated AMD Ryzen 9 9950X hosts
How long a job can runUp to 5 days, GitHub's cap for self-hosted runnersUp to 3 hours, whatever the project settingNo session cap on paid plans
Files after the jobDisk destroyed; cache and disk snapshots (deleted after 15 days) carry state overVM deleted; shared cache (5 GB per archive) or artifacts carry state overDisk stays, saved every minute and on stop; a stopped sandbox costs nothing
ForkNo; a later runner can boot from a saved snapshot in 45 to 60 secondsNo; every job starts from a fresh VM and imageFork a running sandbox with its disk
Docker and nested virtualizationDocker; /dev/kvm on Linux x86-64, turned on with a labelDocker-in-Docker in privileged mode; nested virtualization not documentedDocker, root, systemd and /dev/kvm on every machine
Reaching the machineInbound traffic blocked; SSH into failed jobs for debuggingInbound traffic blocked; no web terminal on hosted runnersSSH, HTTPS URLs on up to 50 ports, raw TCP
Desktop and computer useNoneNone; headless runners60fps desktop with Chromium, computer use API, embeddable stream
Coding agentsHosts Claude Managed Agents sessions on stock runnersDuo Agent Platform runs Claude Code, Codex and others from issues and merge requestsSeven agents preinstalled, driven from outside with a prompt, steer and events API
Keeping keys out of the machineGitHub secrets are passed into the runnerManaged credentials for the Claude and Codex agents only; other secrets enter as CI/CD variablesCredentials proxy for model providers and any HTTPS API; real keys never enter the sandbox
Operating systems and GPUsLinux x86-64 and arm64, Windows Server, macOS on Apple M4 ProLinux x64 and Arm64, Windows (beta), macOS on Apple silicon (beta), NVIDIA T4Linux x86-64, no GPUs
Running in your own infrastructureBYOC in your AWS, GCP or Azure account, with static egress IPsOpen-source GitLab Runner on your own machines, using no compute minutesHosted only, in the EU
RegionsIts cloud, an EU region on enterprise, or your own cloud regionUS (Google Cloud us-east1 by default)EU only (Germany, Finland, France)
How you payPer minute while a job runs, no plan feeCompute minutes included per group, extra packs of 1,000 bought aheadMonthly plan from $20, all of it usage credit spent per second
Every feature Battleships tracks (43)
FeatureWarpBuildGitLab.com hosted runnersboat
Full VM (own kernel)YesYesYes
Docker insideYesYesYes
Nested virtualizationYesNoYes
RootYesYesYes
SystemdNot publishedNoYes
Desktop GUINoNoYes
BrowserNoYesYes
Computer-use APINoNoYes
SSHYesNoYes
Persistent diskNoNoYes
Pause/resumeNoNoYes
Automatic snapshotsNoNoYes
Fork/cloneNoNoYes
Live fork (no pause)NoNoYes
Memory forkNoNoNo
Custom image (Docker or snapshot)YesYesYes
≥24 h sessionsYesNoYes
Idle auto-stopYesYesNo
Wake on requestYesNoNo
HTTPS preview URLsNoNoYes
Raw TCP inboundNoNoYes
Public IPv4NoNoNo
Egress allowlistYesNoNo
Secret proxyNoYesYes
Secret proxy for any APINoNoYes
Preinstalled agentsYesYesYes
Agent harness APINoYesYes
MCP serverYesNoNo
GPUNoYesNo
WindowsYesYesNo
Arm64YesYesNo
Self-hostingNoYesNo
BYOCYesNoNo
Open sourceNoYesNo
Scoped API keysYesNot publishedYes
Spend limitsNot publishedNot publishedYes
Usage per sandbox (API)YesNoYes
Audit logsNot publishedYesNo
SSOYesYesNo
SOC 2YesYesNo
HIPAANoNoNo
EU data residencyYesNoYes
Zero data retentionNot publishedNot publishedYes

Performance

WarpBuildNot measured
GitLab.com hosted runnersNot measured
boat26.69 runs/s

There is no comparable measurement for either WarpBuild or GitLab.com hosted runners: neither was part of StarSling's public sandbox benchmark. boat did 26.69 Node.js build-and-test runs per second there at 4 vCPU / 8 GB, on dedicated AMD Ryzen 9 9950X hosts.

Node.js build-and-test loop at 4 vCPU / 8 GB, higher is better. Measured with the open hpc-sandbox-benchmarks suite. WarpBuild and GitLab.com hosted runners 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.

ScenarioWarpBuild, a monthGitLab.com hosted runners, a monthboat, 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$119 · Premium · 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$805 · Premium · 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$9,491 · Premium · 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$2,658 · Premium · 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$5,896 · Premium · with limits$2,000 · $2000/mo · with limits

WarpBuild: WarpBuild bills per minute while a job runs, with no plan fee, from $0.003 a minute for 2 vCPU; Windows costs twice the Linux x86-64 rate and macOS $0.08 a minute. Cache, snapshots and BYOC runners are billed extra.

GitLab.com hosted runners: GitLab counts compute minutes as run time times a cost factor, from 1 for small Linux up to 12 for the biggest machines. Plans include minutes per group (10,000 on Premium, $29 per user a month billed yearly), and extra minutes cost $10 per 1,000, bought ahead.

GitLab.com hosted runners: Plans start at $20 a month, and the whole fee is usage credit spent per second while a sandbox runs. A stopped sandbox costs nothing and keeps its disk.

Limits in those scenarios

Neither fits any of the five agent scenarios, because both keep no disk after a job. GitLab cuts every job at 3 hours, and when a group's minutes run out new jobs stop until you buy more. WarpBuild jobs can run 5 days, so an always-on agent still needs restarts, and its egress price is not published. Neither confirms 300 or 1,000 machines at once, and boat queues starts above 90 a minute in the 1,000-job burst.

ScenarioWarpBuildGitLab.com hosted runnersboat
One coding agent, workdays
  • missing persistent disk
  • different kind of product: CI runner
  • egress price not published
  • Premium: sessions capped at 3 h
  • missing persistent disk
  • different kind of product: CI runner
  • no persistent disk: files lost when it stops or sleeps
None that bite
One agent that never stops
  • missing persistent disk
  • different kind of product: CI runner
  • sessions end after 120 h: needs restarts to run 24/7
  • egress price not published
  • Premium: sessions capped at 3 h
  • missing persistent disk
  • different kind of product: CI runner
  • no persistent disk: files lost when it stops or sleeps
None that bite
50 agents in parallel
  • missing persistent disk
  • different kind of product: CI runner
  • egress price not published
  • how many machines can run at once: limit not published, probably fine at 50 (the typical published limit is 50)
  • Premium: sessions capped at 3 h
  • missing persistent disk
  • different kind of product: CI runner
  • no persistent disk: files lost when it stops or sleeps
None that bite
Sandboxes for your users
  • different kind of product: CI runner
  • not confirmed: how many machines can run at once (you need 300; the typical published limit is 50)
  • egress price not published
  • different kind of product: CI runner
  • not confirmed: how many machines can run at once (you need 300; the typical published limit is 50)
  • egress price not published
None that bite
1,000 short jobs at once
  • different kind of product: CI runner
  • not confirmed: how many machines can run at once (you need 1,000; the typical published limit is 50)
  • egress price not published
  • different kind of product: CI runner
  • not confirmed: how many machines can run at once (you need 1,000; the typical published limit is 50)
  • egress price not published
  • max 2,400 starts/day (needs ~6,667)
  • max 600 starts/hour (needs ~1,000)
  • bursts above 90 starts/min are queued (a burst of 333 takes ~4 min to start)

Which one should you use?

Use WarpBuild when

your code is on GitHub and you want faster Actions runners on Linux, Windows or macOS, in its cloud or your own.

  • Faster GitHub Actions. For teams on GitHub: change one runs-on label and jobs start on WarpBuild, with fast cache and Docker builders.
  • Long jobs and macOS on M4 Pro. For long builds or Apple work: jobs can run up to 5 days, and macOS runs on Apple M4 Pro.
  • Runners in your own cloud. For teams whose CI must stay in their AWS, GCP or Azure account, with their own network rules and fixed IPs.

Use GitLab.com hosted runners when

your code lives on GitLab.com and you want CI that works from the first pipeline, including a T4 GPU or your own free runners.

  • Native CI for GitLab projects. For code on GitLab.com: runners are on by default, so the first pipeline just runs with no extra service.
  • A GPU and more platforms. For CI that needs an NVIDIA T4, Arm64, Windows or macOS, GitLab hosts a runner for each.
  • Your own runners, free of minutes. For teams with spare machines: the open-source GitLab Runner runs there and uses no compute minutes.

Where boat fits

WarpBuild and GitLab.com hosted runners are both CI services, and they are good at it. If what you are really running is agents, both hand you a machine that is wiped when the job ends and cannot be reached from outside. boat gives each agent a full VM that keeps its disk, takes inbound traffic and runs coding agents you drive from outside.

A machine that keeps its work

On both, an agent reclones and reinstalls everything each job. The workarounds cost: WarpBuild snapshots are billed per hour and expire after 15 days, GitLab's cache tops out at 5 GB per archive. boat saves the disk every minute and lets you fork it.

Apps and desktops you can open

Both block inbound traffic, so nobody can open the app an agent built or watch its browser. boat gives HTTPS URLs on up to 50 ports, raw TCP, SSH and a 60fps desktop with computer use.

Agents you drive, keys kept out

WarpBuild hosts only Claude Managed Agents and GitLab runs agents from issues and merge requests, and other secrets sit inside the job. boat drives seven agents from any program, and its credentials proxy keeps real keys for any HTTPS API out.

Use boat when agents need a machine that stays: one that keeps its files, serves the apps they build, shows a desktop and runs coding agents you drive from outside. Compare it one to one: boat vs WarpBuild and boat vs GitLab.com hosted runners.

Questions people ask

Is WarpBuild cheaper than GitLab.com hosted runners?

In our CI runners use case, WarpBuild comes to $864 a month against $2,089 on GitLab, and one workday agent comes to $57 against $119. GitLab's included plan minutes can make plain CI on a GitLab project cheaper than these rates. boat comes to $86 a month for the same CI use case.

Which is faster, WarpBuild or GitLab runners?

We have no comparable CPU measurement for either. boat did 26.69 runs per second on StarSling's sandbox benchmark at 4 vCPU / 8 GB.

Can WarpBuild or GitLab runners run Docker?

Yes, both run Docker in jobs: WarpBuild on its runners, GitLab through Docker-in-Docker in privileged mode. WarpBuild also offers /dev/kvm on Linux x86-64; GitLab does not document nested virtualization. boat has Docker, systemd and /dev/kvm on every machine.

How long can a job run on each?

A WarpBuild job can run up to 5 days, GitHub's cap for self-hosted runners. A GitLab.com hosted runner job stops after 3 hours. A boat sandbox has no session cap on paid plans.

Can I use WarpBuild or GitLab runners as a sandbox for AI agents?

Only inside CI. WarpBuild hosts Claude Managed Agents sessions and GitLab's Duo Agent Platform runs Claude Code and Codex as CI jobs, but each gets a fresh VM that keeps no disk and takes no inbound traffic.

Is boat SOC 2 compliant?

SOC 2 is in progress. We're open about where we stand: live status at status.ascii.dev and our data retention policy at docs.boat.dev/data-retention.

Try boat

Install the CLI, then run boat new.

7-day free trial

More comparisons