bochka vs Sandbox as a Service
Sandbox as a Service gives every job a locked-down VM that runs as a user without root and is destroyed within 24 hours. bochka gives every sandbox a full VM you own as root, with Docker, a disk that persists and coding agents built in.
Where bochka stands out
A machine the agent can set up
On bochka the agent is root, with sudo, systemd, Docker and /dev/kvm on every machine. On Sandbox as a Service your code runs as a user with no sudo, so apt-get fails, there is no Docker and nothing can open /dev/kvm. You install with pip --user or npm and stay inside those bounds.
Work that survives the day
A bochka sandbox has no session cap on paid plans. Its disk is snapshotted every minute and on stop, and a stopped sandbox costs nothing until you resume it. A Sandbox as a Service machine is destroyed with its disk when its timer ends, 24 hours after creation at the latest, or when the balance hits zero.
Coding agents and keys built in
bochka ships Claude Code, Codex, OpenCode and other agents in every sandbox, and you drive them from outside with a prompt, steer and events API. Its credentials proxy keeps real AI keys out of the sandbox and can switch to another account when one runs out of credits. On Sandbox as a Service you start each program yourself through exec calls and pass secrets as environment variables.
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
- Regions
- EU: Germany, Finland, France
Sandbox as a Service
Sandbox as a Service is a small German service that rents disposable Linux VMs for AI agents and code execution, run through a REST API, SDKs and an MCP server.
Each sandbox is a dedicated VM with its own kernel, booted from a prepared Ubuntu 24.04 image in one of three fixed sizes. Your commands run as an unprivileged user with no sudo, there is no SSH and no inbound port, and the machine and its disk are destroyed when its timer runs out, at the latest 24 hours after creation. It is built for agents and apps that run short pieces of code and then throw the machine away.
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 | Sandbox as a Service: price rank |
|---|---|---|
| Software factory 100 at once · 4 vCPU / 8 GB · 2,200 sessions of 8 h a month A software factory needs Docker, root installs and a disk that lasts past a day; Sandbox as a Service gives none of the three, so it is a compromise there. | 3rd cheapest of 367 $634 a month | 281st of 367, with limits $4,928 a month |
| Always-on AI employees 50 machines 24/7 · 2 vCPU / 4 GB An always-on assistant hits the 24-hour lifetime cap on Sandbox as a Service and has to be rebuilt on a new machine each day. | 5th cheapest of 366 $657 a month | 244th of 366, with limits $3,285 a month |
| Code interpreter bursts 100 at once · 1 vCPU / 2 GB · 200,000 sessions of 1 min a month Sandbox as a Service suits short code runs better: no plan fee, no minimum and a billing meter that starts only once the machine is ready. | 186th of 345, with limits $2,000 a month | 136th of 345, with limits $300 a month |
| Sandboxes for your users 300 at once · 2 vCPU / 4 GB · 30,000 sessions of 23 min a month Sandbox as a Service allows 20 sandboxes at once per account by default, so serving hundreds of users needs a raised limit. | Cheapest of 361 $209 a month | 111th of 361, with limits $1,046 a month |
| RL rollouts 1,000 at once · 2 vCPU / 4 GB · 1,000,000 sessions of 3 min a month Rollouts at scale run into the 20-sandbox limit and 40 creations a minute on Sandbox as a Service, and bochka's start limits also queue big bursts. | 34th of 360, with limits $2,000 a month | 79th of 360, with limits $4,500 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 | 168th of 364, with limits $1,400 a month |
| CI runners 40 at once · 8 vCPU / 16 GB · 6,000 sessions of 12 min a month CI jobs that build containers need Docker and root, which Sandbox as a Service does not give the sandbox user. | 4th cheapest of 377 $86 a month | 170th of 377, with limits $660 a month |
| 24/7 dev boxes 1 machine 24/7 · 4 vCPU / 8 GB | 18th cheapest of 368 $26 a month | 298th of 368, with limits $204 a month |
| Computer-use agents 50 at once · 4 vCPU / 8 GB · 20,000 sessions of 15 min a month Sandbox as a Service is headless, with no desktop, browser or screenshot API, while bochka streams a 60fps desktop with Chromium. | 6th cheapest of 369 $200 a month | 269th of 369, with limits $1,400 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 | 253rd of 367, with limits $450 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 | 275th of 346, with limits $450 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 | 225th of 338, with limits $9,000 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 | 211th of 360, with limits $225 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 | Can't run it | Can't run it |
Key features
| Feature | bochka | Sandbox as a Service |
|---|---|---|
| Isolation | Every sandbox is a full VM with its own kernel | Every sandbox is a dedicated VM with its own kernel |
| Root, Docker and systemd | Root, sudo, systemd and Docker on every machine | Commands run as an unprivileged user with no sudo; apt-get install fails; no Docker |
| Nested virtualization | /dev/kvm on every standard machine, so emulators and microVMs run | Not offered: no root and no /dev/kvm |
| How long a sandbox can live | No session cap on paid plans; stop and resume as often as you like | 15 minutes by default, 24 hours at most, then the machine is destroyed |
| Files after the work stops | Snapshots every minute and on stop; a stopped sandbox costs nothing and keeps its disk | No stop state and no persistent volume: the disk is destroyed with the machine |
| Snapshots and fork | Fork a running sandbox in one call; named snapshots as templates, 10 free | Snapshot a running sandbox, then restore it into a new one; kept 7 days, at most 3 per account, REST only |
| Reaching the sandbox | SSH; HTTPS URLs for up to 50 ports, token-protected; raw TCP; its own IP | No SSH or inbound port; HTTP and WebSocket preview URLs anyone with the link can open |
| Desktop and computer use | 60fps desktop and Chromium, computer use and browser control, embeddable stream | Headless only: no desktop, no browser |
| Coding agents | Claude Code, Codex, OpenCode and more preinstalled, with a prompt, steer and events API | None preinstalled; you run commands through exec calls |
| Keeping keys out of the sandbox | AI credentials proxy for model providers and any HTTPS API; real keys never enter the sandbox | Secrets go in as environment variables on each command, so they enter the sandbox |
| MCP server | No hosted MCP server; CLI, SDK and REST API | Remote MCP server with no install, exposing the same operations as tools |
| Billing model | Monthly plan from $20, all of it usage credit spent per second | Prepaid credit packs by the second, no subscription, credit never expires |
| Regions | EU only: Germany, Finland, France | One data centre in Germany |
| 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 | Sandbox as a Service |
|---|---|---|
| Full VM (own kernel) | Yes | Yes |
| Docker inside | Yes | No |
| Nested virtualization | Yes | No |
| Root | Yes | No |
| Systemd | Yes | Not published |
| Desktop GUI | Yes | No |
| Browser | Yes | No |
| Computer-use API | Yes | No |
| SSH | Yes | No |
| Persistent disk | Yes | No |
| Pause/resume | Yes | No |
| Automatic snapshots | Yes | No |
| Fork/clone | Yes | Yes |
| Live fork (no pause) | Yes | Yes |
| Memory fork | No | No |
| Custom image (Docker or snapshot) | Yes | Yes |
| ≥24 h sessions | Yes | Yes |
| Idle auto-stop | No | No |
| Wake on request | No | No |
| HTTPS preview URLs | Yes | Yes |
| Raw TCP inbound | Yes | Not published |
| Public IPv4 | No | No |
| Egress allowlist | No | No |
| Secret proxy | Yes | No |
| Secret proxy for any API | Yes | No |
| Preinstalled agents | Yes | No |
| Agent harness API | Yes | No |
| MCP server | No | Yes |
| GPU | No | No |
| Windows | No | No |
| Arm64 | No | No |
| Self-hosting | No | No |
| BYOC | No | No |
| 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
There is no comparable CPU measurement for Sandbox as a Service, so we do not compare speed. bochka did 26.69 runs per second in the hpc-sandbox-benchmarks run at 4 vCPU / 8 GB on dedicated AMD Ryzen 9 9950X (Zen 5) hosts. Sandbox as a Service publishes its own start times: about a second when its warm pool of one small machine is free, about 24 to 47 seconds on its standard path, and about 160 seconds when it falls back.
Node.js build-and-test loop at 4 vCPU / 8 GB, higher is better. Measured with the open hpc-sandbox-benchmarks suite. Sandbox as a Service 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 | Sandbox as a Service, 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 | $49 · Prepaid · with limits |
| One agent that never stops 4 vCPU / 8 GB, 50 GB disk, running 24/7 all month | $26 · $20/mo | $204 · Prepaid · 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,464 · Prepaid · 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 | $450 · Prepaid · 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 | $900 · Prepaid · 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.
Sandbox as a Service: Sandbox as a Service bills each sandbox per second at a fixed hourly rate for its size, from the moment it is ready until it is destroyed, idle or busy. You pay from prepaid credit; network transfer and API calls are free, and snapshot storage is billed at a rate the site does not publish.
Limits in those scenarios
Sandbox as a Service allows 20 sandboxes at once per account by default, so 50 agents, 300 user sandboxes and 1,000 short jobs all need a raised limit you ask for. Its 24-hour lifetime cap rules out one agent that never stops, and with no persistent disk, a workday agent starts from an empty machine each morning unless you restore a snapshot. On bochka the limit is a sandbox count by plan plus starts per minute, so the 1,000-job burst gets queued and needs more starts per day than the $2,000 plan allows.
| Scenario | bochka | Sandbox as a Service |
|---|---|---|
| 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 Sandbox as a Service when
you run short, untrusted code jobs that fit in a day, want the least power inside the sandbox, and prefer prepaid credit with no subscription.
- Pay only for what you run. Useful for small or uneven use: prepaid credit by the second, no subscription, no minimum, and credit that never expires.
- A small surface by default. Useful for running code nobody reviewed: no root, no SSH, no inbound port, and the machine is gone within a day.
- An MCP server with no install. Useful if your agent talks to tools over MCP: a hosted MCP server exposes sandbox create, exec, files and ports.
Use bochka when
your agents do real work for hours or days: root installs, Docker and emulators on a full VM whose disk survives stops, with a desktop and coding agents built in.
- A machine the agent can set up. Agents fix real projects by installing system packages, running docker compose and starting databases. Without root those steps fail, and the only workaround is to change the project so it never needs them.
- Work that survives the day. A coding agent that stops at night loses its checkout, installs and build cache. The workaround is a manual snapshot, kept 7 days with at most 3 per account, or copying files out to your own storage before the timer runs out.
- Coding agents and keys built in. Exec calls stop after 10 minutes at most, so a long agent run has to be started in the background and watched by your own code. Keys passed as environment variables sit inside the machine the agent controls.
Questions people ask
Is bochka cheaper than Sandbox as a Service?
For long-running work, yes: one agent running all month comes to $26 on bochka and $204 on Sandbox as a Service, and 50 agents in parallel come to $317 against $2,464, if its limits were raised. For 1,000 short jobs at once, Sandbox as a Service comes to $900 against $2,000 on bochka, though neither fits without higher limits.
Can I run Docker or apt-get in Sandbox as a Service?
No. Your commands run as an unprivileged user with no sudo, so apt-get install fails and there is no Docker daemon. You install Python packages with pip --user or a virtualenv, and npm works as is. On bochka you are root, with Docker and systemd ready.
How long can a Sandbox as a Service sandbox run?
15 minutes by default, and you can extend it up to 1,440 minutes (24 hours) after creation. Then the machine and its disk are destroyed. A bochka sandbox has no session cap on paid plans, and you can stop it for free and resume it later with its disk.
Do both run in the EU?
Yes. Sandbox as a Service runs in one data centre in Germany. 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. Sandbox as a Service lists its own certifications, or their absence, on its security page.
Start a sandbox
Install the CLI, then run bochka new.
Product preview