bochka vs RunsOn

RunsOn is a self-hosted GitHub Actions runner service: each CI job gets a fresh EC2 machine in your own AWS account, and the machine is gone when the job ends. bochka is a sandbox for agents: a full VM you start from your code, keep as long as the work needs, fork, and reach over HTTPS, with coding agents built in.

Where bochka stands out

A machine you start from code and keep

A bochka sandbox starts when your code asks for one, runs with no session cap on paid plans, and keeps its whole disk, saved every minute and on stop. You can fork a running sandbox into a new one. A RunsOn runner starts only for a GitHub Actions job and is terminated when that job ends.

Coding agents you drive from outside

bochka ships Claude Code, Codex, OpenCode and other agents in every sandbox, and you drive agents inside from outside with a prompt, steer and events API. Real API keys stay in a credentials proxy outside the sandbox, for model providers and any HTTPS API, and a credential can switch to another account when credits run out.

Reach it, see it, host on it

Every bochka sandbox has HTTPS URLs for up to 50 ports, token-protected by default, raw TCP and its own IP. It also streams a 60fps Linux desktop with Chromium for computer use and browser control.

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

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 bochka, so this page compares the part where they overlap: a machine where an agent or a job does its work.

Product: Self-hosted GitHub Actions runners, deployed as one stack in your own AWS account
Isolation: Every job runs on an EC2 instance no other job has used, terminated when the job ends
Data: Code, secrets and logs stay in your AWS account; RunsOn gets a licence check and one event per job
Platforms: Linux x64 and arm64, Windows Server 2022 and 2025, NVIDIA and AMD GPUs; macOS not supported
Licence: From EUR 300 or $350 a year per company, sized by jobs per month; free for non-commercial use
Company: Bootstrapped and self-funded, built by Cyril Rohr; says 900+ companies and 3M+ jobs a day

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	RunsOn: 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 between tasks; RunsOn resets everything but the sticky disk after each job, and bochka keeps the whole disk.	3rd cheapest of 367 $634 a month	122nd of 367, with limits $1,114 a month
Always-on AI employees 50 machines 24/7 · 2 vCPU / 4 GB An assistant that never stops is a compromise on RunsOn, because a runner only lives for one GitHub Actions job and GitHub ends self-hosted jobs after 5 days.	5th cheapest of 366 $657 a month	188th of 366, with limits $1,724 a month
Code interpreter bursts 100 at once · 1 vCPU / 2 GB · 200,000 sessions of 1 min a month RunsOn costs less for short bursts here because AWS bills spot minutes at cost, though each burst still has to arrive as a GitHub Actions job.	186th of 345, with limits $2,000 a month	229th of 345, with limits $147 a month
Sandboxes for your users 300 at once · 2 vCPU / 4 GB · 30,000 sessions of 23 min a month RunsOn starts machines for your own GitHub workflows, not for your users, so giving each user a sandbox means building that layer yourself.	Cheapest of 361 $209 a month	216th of 361, with limits $585 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	245th of 360, with limits $2,714 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	251st of 364, with limits $389 a month
CI runners 40 at once · 8 vCPU / 16 GB · 6,000 sessions of 12 min a month Both fit: GitHub Actions runners are RunsOn's whole product, with S3 caches, sticky disks and Windows, while bochka runs CI jobs on full VMs with Docker and /dev/kvm.	4th cheapest of 377 $86 a month	58th cheapest of 377 $432 a month
24/7 dev boxes 1 machine 24/7 · 4 vCPU / 8 GB A dev box has to keep running and keep its files; a RunsOn runner is gone when its job ends, while a bochka machine stays up as long as you want.	18th cheapest of 368 $26 a month	158th of 368, with limits $86 a month
Computer-use agents 50 at once · 4 vCPU / 8 GB · 20,000 sessions of 15 min a month RunsOn runners are headless and reached over SSM or SSH, so a computer-use agent needs you to set up a desktop yourself; bochka streams a 60fps Linux desktop with Chromium.	6th cheapest of 369 $200 a month	142nd of 369, with limits $353 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	206th of 367, with limits $224 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	228th of 346, with limits $205 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	122nd of 338, with limits $3,539 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	178th of 360, with limits $157 a month
GPU eval jobs 10 at once · 8 vCPU / 32 GB · 500 sessions of 30 min a month Neither is a fit in our model, though RunsOn can launch NVIDIA GPU instances for CI jobs and bochka is CPU only.	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	Can't run it	Can't run it

Key features

Feature	bochka	RunsOn
What it is	A sandbox API for agents: full VMs you create, stop, fork and delete from code	Self-hosted GitHub Actions runners: one EC2 machine per CI job
Isolation	Full VM with its own kernel on dedicated AMD Ryzen 9 9950X hosts	Fresh EC2 instance per job in your AWS account, terminated when the job ends
How a machine starts	Any time, by API, CLI or SDK	When a GitHub Actions job asks for it with a runs-on: label
How long it can run	No session cap on paid plans; you set the time to live	One job; GitHub ends self-hosted jobs after 5 days
Files after it stops	Whole disk saved every minute and on stop; a stopped sandbox costs nothing	Root disk is thrown away; one sticky EBS cache disk per job is snapshotted and restored next job
Fork	Fork a running sandbox with its disk	No; every job starts from an AMI
Docker and nested virtualization	Docker, root, systemd and /dev/kvm on every machine	Docker and root; KVM on compatible Intel x64 families, not arm64
Desktop and browser	60fps Linux desktop and Chromium, with computer use and browser control	Headless runners reached over SSM or optional SSH
Inbound access	HTTPS URLs for up to 50 ports, token-protected; raw TCP; dedicated IPv4 or IPv6	SSH from a CIDR range you allow, and SSM; no HTTPS URLs
Outbound rules	Open internet, no provider-side allowlist	Your own AWS Network Firewall policy or security groups; static egress IPs through NAT
Coding agents and keys	Claude Code, Codex and more preinstalled with a prompt, steer and events API; credentials proxy keeps real keys out	Bedrock access through the instance role; Copilot's coding agent can use a runner
Machine types	Linux x64, up to 16 vCPU / 32 GB on the $100 plan and above	Any EC2 size up to 96 vCPU, x64 and arm64, Windows Server and NVIDIA or AMD GPUs
Where it runs	Managed by bochka in the EU (Germany, Finland, France)	In your own AWS account, in the region you pick
Compliance and transparency	SOC 2 is in progress. We're open about where we stand: live status and data retention policy.	No SOC 2 report published

Every feature Battleships tracks (43)

Feature	bochka	RunsOn
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	Yes
Pause/resume	Yes	Yes
Automatic snapshots	Yes	Yes
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	Yes
Egress allowlist	No	Yes
Secret proxy	Yes	No
Secret proxy for any API	Yes	No
Preinstalled agents	Yes	No
Agent harness API	Yes	No
MCP server	No	No
GPU	No	Yes
Windows	No	Yes
Arm64	No	Yes
Self-hosting	No	Yes
BYOC	No	Yes
Open source	No	No
Scoped API keys	Yes	Not published
Spend limits	Yes	Not published
Usage per sandbox (API)	Yes	No
Audit logs	No	Not published
SSO	No	No
SOC 2	No	No
HIPAA	No	No
EU data residency	Yes	Yes
Zero data retention	Yes	Not published

Performance

bochka26.69 runs/s

RunsOnNot measured

There is no comparable measurement: RunsOn is not in the hpc-sandbox-benchmarks run where bochka did 26.69 runs per second at 4 vCPU / 8 GB. RunsOn's speed depends on the EC2 family you pick, and its pricing page lists its own CPU scores against GitHub-hosted runners, which use a different test.

Node.js build-and-test loop at 4 vCPU / 8 GB, higher is better. Measured with the open hpc-sandbox-benchmarks suite. RunsOn 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	RunsOn, 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	$61 · Starter · with limits
One agent that never stops 4 vCPU / 8 GB, 50 GB disk, running 24/7 all month	$26 · $20/mo	$159 · Starter · 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	$1,597 · Starter · 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	$515 · Starter · 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,103 · Starter · 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.

RunsOn: AWS bills the EC2 instances and EBS disks on your own AWS bill, to the second, at spot or on-demand prices with no markup; 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, and the prices here use spot rates in us-east-1.

Limits in those scenarios

None of the five scenarios is a clean fit for RunsOn, because it only starts machines for GitHub Actions jobs, each one is terminated when the job ends, and GitHub ends self-hosted jobs after 5 days. Only the sticky disk survives between jobs, so packages installed elsewhere reset, and AWS egress is not priced here. RunsOn's own scale limits are your AWS account's quotas: it paces launches at about 2 EC2 calls per second by default, and new accounts start with low vCPU quotas. On bochka the limit for 1,000 short jobs is starts: the $2,000 plan queues bursts and allows fewer starts per day than the scenario needs.

Scenario	bochka	RunsOn
One coding agent, workdays	None that bite	different kind of product: CI runner files survive a stop only in the sticky disk: packages installed elsewhere reset disk beyond 30 GiB: price unknown egress price not published
One agent that never stops	None that bite	different kind of product: CI runner sessions end after 120 h: needs restarts to run 24/7 files survive a stop only in the sticky disk: packages installed elsewhere reset disk beyond 30 GiB: price unknown
50 agents in parallel	None that bite	different kind of product: CI runner files survive a stop only in the sticky disk: packages installed elsewhere reset egress price not published
Sandboxes for your users	None that bite	different kind of product: CI runner 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 egress price not published

Which one should you use?

Use RunsOn when

you want cheaper, faster GitHub Actions runners in your own AWS account, including Windows, arm64 or GPU jobs, with compute billed at AWS cost.

Faster GitHub Actions at AWS cost. Useful if you want cheaper, bigger GitHub Actions runners: change one label and jobs run on EC2 billed at cost.
Windows, arm64 and GPUs. Useful for jobs that need Windows Server, native arm64 builds or NVIDIA GPUs, on any EC2 size up to 96 vCPU.
Your own AWS account, any region. Useful when code and logs must never leave your AWS account, or must run in a region outside the EU.

Use bochka when

you need machines for agents rather than CI jobs: a full VM you start by API, keep for days or months with its whole disk, fork, reach over HTTPS and drive with built-in coding agents.

A machine you start from code and keep. On RunsOn an agent has to be wrapped in a workflow run, GitHub ends it after 5 days, and only the one sticky cache disk comes back next time; installed packages and work elsewhere on the disk are gone.
Coding agents you drive from outside. RunsOn gives runners Bedrock through an IAM role and can host Copilot's coding agent; any other agent you install, start and watch from your own workflow steps, with its keys as secrets on the machine.
Reach it, see it, host on it. A RunsOn runner is reached only over SSM or SSH, so an agent's web app preview or a browser task needs your own tunnels, load balancer or desktop setup in your AWS account.

Questions people ask

Can I use RunsOn as a sandbox for AI agents?

Only inside GitHub Actions. A RunsOn runner starts for a workflow job and is terminated when the job ends, so an agent has to run as a job, for at most 5 days. RunsOn supports Bedrock access and Copilot's coding agent on its runners, but it has no API to create, keep or fork a sandbox on its own.

Is bochka cheaper than RunsOn?

For agent work in our scenarios, yes: one coding agent on workdays comes to $20 a month on bochka and $61 on RunsOn, one agent that never stops to $26 against $159, and 50 agents in parallel to $317 against $1,597. For 1,000 short jobs at once RunsOn comes to $1,103 and bochka to $2,000, and neither fits cleanly. For plain CI jobs RunsOn bills AWS spot minutes at cost, which is hard to beat.

Can bochka replace RunsOn for GitHub Actions?

bochka can run a GitHub Actions runner on a full VM with Docker and /dev/kvm, but it does not sell a drop-in runner service with labels, S3 caches and warm pools. If CI is all you need, especially on Windows, arm64 or GPUs, RunsOn is built for it.

Do files survive between RunsOn jobs?

Only on the sticky disk: one EBS volume per job that RunsOn snapshots after the job and restores before the next one. The rest of the machine is new every time. A bochka sandbox keeps its whole disk, saved every minute and on stop, and a stopped sandbox costs nothing.

Where does my data run?

RunsOn runs in your own AWS account, in the region you choose, and your code, secrets and logs are never sent to RunsOn. bochka runs only in the EU (Germany, Finland and France), with EU data residency and a zero data retention option.

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.

Start a sandbox

Install the CLI, then run bochka new.

Product preview