bochka vs WarpBuild

WarpBuild is a fast, drop-in replacement for GitHub Actions runners: each job gets a fresh VM that is destroyed when the job ends. bochka gives an agent its own VM that keeps its disk, serves apps on HTTPS and ships coding agents you drive from outside.

Where bochka stands out

A machine that keeps its work

A bochka sandbox keeps its disk, snapshots it every minute and on stop, and a stopped sandbox costs nothing. You can fork a running sandbox and there is no session cap on paid plans. A WarpBuild runner's disk is destroyed when the job ends.

Apps your agent can show

bochka gives every sandbox HTTPS URLs on up to 50 ports, raw TCP and a 60fps desktop with Chromium you can embed. WarpBuild runners block all inbound traffic by design, because the runner only polls GitHub for work.

Coding agents you drive from outside

bochka ships Claude Code, Codex, OpenCode and other agents in every sandbox, with a prompt, steer and events API to drive agents inside from outside. Its credentials proxy keeps real AI keys out of the sandbox and can switch to another account when one runs out of credits. WarpBuild hosts only Anthropic's Claude Managed Agents, on stock runners.

The companies and products

bochka

bochka.xyz runs sandboxes for AI agents: each one is a full Linux VM with its own kernel.

You start a machine with one command or one API call, then SSH in, run Docker, open a desktop, or let a built-in agent (Claude Code, Codex, OpenCode and others) work in it. The disk stays between sessions, and a stopped sandbox costs nothing.

Isolation: Full VM per sandbox, own kernel
Hardware: Dedicated AMD Ryzen 9 9950X (Zen 5) hosts
Regions: EU: Germany, Finland, France
Plans: From $20 a month, all of it usage credit, 7-day trial

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.

Kind of product: GitHub Actions runners and remote Docker builders, billed per minute
Isolation: Each runner runs in its own virtual machine, created on demand and destroyed after each build
Platforms: Ubuntu on x86-64 and arm64, Windows Server 2022 and 2025, macOS 14, 15 and 26 on Apple M4 Pro
Where it runs: WarpBuild's cloud, or BYOC in your own AWS, GCP or Azure account
Concurrency: Unlimited on Linux and Windows; high macOS concurrency through support
SSO: SAML SSO with Okta, Azure AD or Google Workspace, $250 a month
Compliance: Says it is SOC 2 Type 2 compliant

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. “3rd cheapest of 367” means 2 of the other 366 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	bochka: price rank	WarpBuild: 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 files between tasks; WarpBuild runners are wiped after every job.	3rd cheapest of 367 $634 a month	269th of 367, with limits $4,343 a month
Always-on AI employees 50 machines 24/7 · 2 vCPU / 4 GB An assistant that lives for weeks does not fit a job runner that GitHub stops after 5 days and that keeps no disk.	5th cheapest of 366 $657 a month	285th of 366, with limits $5,650 a month
Code interpreter bursts 100 at once · 1 vCPU / 2 GB · 200,000 sessions of 1 min a month Both are a compromise for one-minute code runs: WarpBuild bills whole minutes per job, and bochka's start limits slow very large bursts.	186th of 345, with limits $2,000 a month	287th of 345, with limits $600 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 to reach their apps; WarpBuild runners block all inbound traffic.	Cheapest of 361 $209 a month	278th of 361, with limits $1,890 a month
RL rollouts 1,000 at once · 2 vCPU / 4 GB · 1,000,000 sessions of 3 min a month	34th of 360, with limits $2,000 a month	281st of 360, with limits $9,000 a month
Agent evals 250 at once · 4 vCPU / 8 GB · 15,000 sessions of 20 min a month	10th cheapest of 364 $200 a month	294th of 364, with limits $1,440 a month
CI runners 40 at once · 8 vCPU / 16 GB · 6,000 sessions of 12 min a month WarpBuild is built for this: switch a runs-on label and GitHub sends the job to it, while on bochka you set up the runner on your own machines.	4th cheapest of 377 $86 a month	94th cheapest of 377 $864 a month
24/7 dev boxes 1 machine 24/7 · 4 vCPU / 8 GB A dev box needs a disk that stays; WarpBuild's disk goes away with the job, so only snapshots and cache carry state over.	18th cheapest of 368 $26 a month	182nd of 368, with limits $226 a month
Computer-use agents 50 at once · 4 vCPU / 8 GB · 20,000 sessions of 15 min a month WarpBuild has no desktop or computer-use API; bochka streams a 60fps desktop with Chromium on every machine.	6th cheapest of 369 $200 a month	264th of 369, with limits $1,320 a month
Browser-use agents 50 at once · 2 vCPU / 4 GB · 30,000 sessions of 10 min a month	7th cheapest of 367 $200 a month	280th of 367, with limits $720 a month
Scraping & bots (startup scale) 50 at once · 1 vCPU / 2 GB · 100,000 sessions of 3 min a month	6th cheapest of 346 $90 a month	306th of 346, with limits $878 a month
Mass scraping & bots (undetectable) 1,000 at once · 1 vCPU / 2 GB · 3,000,000 sessions of 2 min a month	71st of 338, with limits $1,800 a month	275th of 338, with limits $17,550 a month
Parallel red teaming 200 at once · 2 vCPU / 4 GB · 5,000 sessions of 30 min a month	2nd cheapest of 360 $200 a month	264th of 360, with limits $435 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
macOS agents 5 at once · 4 vCPU / 8 GB · 1,000 sessions of 20 min a month Only WarpBuild fits: it has macOS runners on Apple M4 Pro, and bochka runs Linux only.	Can't run it	29th of 36, with limits $1,520 a month

Key features

Feature	bochka	WarpBuild
Kind of product	A machine for an agent, kept as long as you want	A GitHub Actions runner that lives for one job
Isolation	Every sandbox is a full VM with its own kernel	Every job gets its own VM, never reused
How long a machine lives	No session cap on paid plans; stop and start it when you like	Until the job ends; GitHub stops a self-hosted runner job after 5 days
Files after a stop	The disk stays, with snapshots every minute and on stop; a stopped sandbox costs nothing	The disk is destroyed after each build; cache and disk snapshots (Ubuntu cloud runners, deleted after 15 days) carry state over
Fork	Fork a running sandbox into copies	No fork; a later runner can boot from a saved disk snapshot in 45 to 60 seconds
Docker and nested virtualization	Docker, root, systemd and /dev/kvm on every machine	Docker on runners; /dev/kvm only on Linux x86-64, turned on with a label
Desktop and computer use	60fps desktop and Chromium, computer use and browser control, embeddable stream	None; runners have no desktop stream
Reaching the machine	HTTPS URLs for up to 50 ports, token-protected; raw TCP; SSH	All inbound traffic blocked; SSH into failed jobs for debugging
Coding agents	Claude Code, Codex, OpenCode and more preinstalled, with a prompt, steer and events API	Runs Claude Managed Agents sessions on stock Linux and macOS runners, driven through Anthropic's API
Keeping keys out of the machine	AI credentials proxy for model providers and any HTTPS API you register; real keys never enter the sandbox	GitHub secrets are passed into the runner environment
Operating systems and chips	Linux on x86-64 (AMD Ryzen 9 9950X hosts)	Linux x86-64 and arm64, Windows Server, macOS on Apple M4 Pro
GitHub Actions	No managed runner service; you run the GitHub runner on a sandbox yourself	Drop-in: change runs-on and jobs start on WarpBuild, with fast cache and Docker builders
Your own cloud and network rules	Hosted in the EU only; open internet, no provider-side allowlist	BYOC in AWS, GCP or Azure with security-group egress rules and static egress IPs
Compliance and transparency	SOC 2 is in progress. We're open about where we stand: live status and data retention policy.	SOC 2

Every feature Battleships tracks (43)

Feature	bochka	WarpBuild
Full VM (own kernel)	Yes	Yes
Docker inside	Yes	Yes
Nested virtualization	Yes	Yes
Root	Yes	Yes
Systemd	Yes	Not published
Desktop GUI	Yes	No
Browser	Yes	No
Computer-use API	Yes	No
SSH	Yes	Yes
Persistent disk	Yes	No
Pause/resume	Yes	No
Automatic snapshots	Yes	No
Fork/clone	Yes	No
Live fork (no pause)	Yes	No
Memory fork	No	No
Custom image (Docker or snapshot)	Yes	Yes
≥24 h sessions	Yes	Yes
Idle auto-stop	No	Yes
Wake on request	No	Yes
HTTPS preview URLs	Yes	No
Raw TCP inbound	Yes	No
Public IPv4	No	No
Egress allowlist	No	Yes
Secret proxy	Yes	No
Secret proxy for any API	Yes	No
Preinstalled agents	Yes	Yes
Agent harness API	Yes	No
MCP server	No	Yes
GPU	No	No
Windows	No	Yes
Arm64	No	Yes
Self-hosting	No	No
BYOC	No	Yes
Open source	No	No
Scoped API keys	Yes	Yes
Spend limits	Yes	Not published
Usage per sandbox (API)	Yes	Yes
Audit logs	No	Not published
SSO	No	Yes
SOC 2	No	Yes
HIPAA	No	No
EU data residency	Yes	Yes
Zero data retention	Yes	Not published

Performance

bochka26.69 runs/s

WarpBuildNot measured

There is no comparable measurement. WarpBuild was not part of StarSling's public sandbox benchmark, where bochka did 26.69 Node.js build-and-test runs per second at 4 vCPU / 8 GB, and WarpBuild's own speed claims compare its runners with GitHub's, not with bochka.

Node.js build-and-test loop at 4 vCPU / 8 GB, higher is better. Measured with the open hpc-sandbox-benchmarks suite. WarpBuild has 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	bochka, a month	WarpBuild, 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	$20 · $20/mo	$57 · Pay as you go · with limits
One agent that never stops 4 vCPU / 8 GB, 50 GB disk, running 24/7 all month	$26 · $20/mo	$237 · Pay as you go · with limits
50 agents in parallel 50 machines of 4 vCPU / 8 GB at once, 8-hour sessions, 1,100 sessions a month, Docker inside	$317 · $20/mo × 3 seats	$2,851 · Pay as you go · with limits
Sandboxes for your users 2 vCPU / 4 GB, 30,000 sessions of 10 minutes a month, up to 300 at once	$200 · $100/mo × 2 seats	$810 · Pay as you go · with limits
1,000 short jobs at once 2 vCPU / 4 GB, 1,000 at once, 3 minutes each, 200,000 jobs a month	$2,000 · $2000/mo · with limits	$1,800 · Pay as you go · with limits

bochka: 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.

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 snapshot restores are billed extra, and BYOC runners cost $0.002 a minute on top of your own cloud bill.

Limits in those scenarios

None of the five scenarios fits WarpBuild as it is sold, because a runner exists only while a GitHub Actions job runs and keeps no disk afterwards. An agent that must run all month also hits GitHub's 5 day cap on a job, so it needs restarts. WarpBuild advertises unlimited concurrency on Linux and Windows, but the scenarios still mark the 300 and 1,000 machine counts as unconfirmed, and egress pricing is not published. On bochka, 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	bochka	WarpBuild
One coding agent, workdays	None that bite	missing persistent disk different kind of product: CI runner egress price not published
One agent that never stops	None that bite	missing persistent disk different kind of product: CI runner sessions end after 120 h: needs restarts to run 24/7 egress price not published
50 agents in parallel	None that bite	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)
Sandboxes for your users	None that bite	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
1,000 short jobs at once	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)	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

Which one should you use?

Use WarpBuild when

you want faster GitHub Actions CI, on macOS, Windows or Linux, in its cloud or your own.

macOS and Windows runners. Useful if you build iPhone, Mac or Windows apps: WarpBuild runs macOS on Apple M4 Pro and Windows Server.
Drop-in GitHub Actions. Useful if your goal is faster CI: change one runs-on label and your GitHub jobs start on WarpBuild.
Runners in your own cloud. Useful if CI must run in your own AWS, GCP or Azure account, with your network rules and fixed IPs.

Use bochka 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.

A machine that keeps its work. An agent that clones a repo, installs packages and builds for hours loses all of it when a WarpBuild job ends. The workaround is cache uploads or disk snapshots that cost per hour, expire after 15 days and take 45 to 60 seconds to boot.
Apps your agent can show. Without a URL into the machine, nobody can open the app an agent just built or watch its browser. On WarpBuild the only way in is a debug SSH session into a job.
Coding agents you drive from outside. On WarpBuild your keys and GitHub secrets live inside the runner, where agent-written code can read them. You are also tied to one harness, with no custom images for agent sessions yet.

Questions people ask

Is WarpBuild a sandbox for AI agents?

Not in the usual sense. WarpBuild sells GitHub Actions runners: each job gets a fresh VM that is destroyed when the job ends. It can also host Claude Managed Agents sessions on its stock runners, but each session gets a fresh VM that is torn down afterwards.

Is bochka cheaper than WarpBuild?

For agent work, yes in four of the five scenarios we priced: one coding agent on workdays comes to $20 a month on bochka and $57 on WarpBuild, and 50 agents in parallel come to $317 versus $2,851. For 1,000 short jobs at once, WarpBuild is lower at $1,800 against $2,000 on bochka. None of the WarpBuild prices fit as it is sold, since its runners live only for one CI job.

Can I run GitHub Actions on bochka?

bochka is not a managed runner service, so there is no runs-on label to switch. You can install the GitHub runner on a sandbox yourself, and you get Docker, root and /dev/kvm there. If you want CI that works with one line changed, WarpBuild is built for that.

Does bochka have macOS or Windows like WarpBuild?

No. bochka runs Linux VMs on dedicated AMD Ryzen 9 9950X hosts and has no macOS or Windows guests. WarpBuild has macOS on Apple M4 Pro and Windows Server runners.

Where does my data run?

bochka runs only in the EU (Germany, Finland and France), with EU data residency and a zero data retention option. WarpBuild offers a hosted EU region on its enterprise tier, or runners in an EU region of your own AWS or GCP account.

Is bochka SOC 2 compliant?

SOC 2 is in progress. We're open about where we stand: live status at status.bochka.xyz and our data retention policy at docs.bochka.xyz/data-retention. WarpBuild says it is SOC 2 Type 2 compliant.

Start a sandbox

Install the CLI, then run bochka new.

Product preview