bochka vs Cloudflare Workers for Platforms
These are two different kinds of product. bochka gives each agent a whole Linux machine that keeps its files, while Workers for Platforms runs many small pieces of your customers' JavaScript or Wasm code in V8 isolates, one request at a time.
Where bochka stands out
A whole Linux machine, not a script runner
A bochka sandbox is a full VM with root, systemd, Docker and /dev/kvm, up to 16 vCPU / 32 GB. A Worker is a JavaScript or Wasm program in an isolate with 128 MB of memory and no shell, so it cannot run git, apt, a compiler or a test suite.
A disk that stays, with snapshots and fork
bochka keeps each sandbox's disk, saves a snapshot every minute and on stop, and can fork a running sandbox. A stopped sandbox costs nothing and comes back with its files. A Worker's /tmp lives in memory and is gone after each request.
Coding agents you drive from outside
Claude Code, Codex, OpenCode and others come installed in every bochka sandbox, and one API lets you prompt, steer and follow their events. Real API keys stay outside the sandbox in a credentials proxy, and a credential can switch to another account when it runs out of credits.
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
Cloudflare Workers for Platforms
Workers for Platforms is Cloudflare's way to run untrusted code from your customers or from AI in isolated sandboxes on its global network.
It is a serverless platform, not a VM sandbox. Each of your customers gets their own Worker, a script that runs in a V8 isolate, and your own dispatch Worker decides which customer script handles each request, with an optional outbound Worker that sees every fetch it makes. It is built for SaaS and AI platforms that want to host thousands of small customer apps or code snippets with per-customer CPU limits.
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 | Cloudflare Workers for Platforms: price rank |
|---|---|---|
| Software factory 100 at once · 4 vCPU / 8 GB · 2,200 sessions of 8 h a month A software factory needs git, package managers, Docker and a disk that stays; a Workers isolate has none of these, so only bochka runs this as intended. | 3rd cheapest of 367 $634 a month | 224th of 367, with limits $2,763 a month |
| Always-on AI employees 50 machines 24/7 · 2 vCPU / 4 GB An always-on assistant keeps files, logins and running processes; a Worker forgets everything after each request unless you store it in KV, D1, R2 or Durable Objects. | 5th cheapest of 366 $657 a month | 274th of 366, with limits $4,879 a month |
| Code interpreter bursts 100 at once · 1 vCPU / 2 GB · 200,000 sessions of 1 min a month If the code is JavaScript, TypeScript, Python or Wasm and fits in 128 MB and 30 seconds of CPU, an isolate starts almost at once and costs very little per call. | 186th of 345, with limits $2,000 a month | 293rd of 345, with limits $692 a month |
| Sandboxes for your users 300 at once · 2 vCPU / 4 GB · 30,000 sessions of 23 min a month For letting each user deploy a small web app or function, Workers for Platforms is built for exactly that; for users who need a shell, Docker or a real machine, bochka fits. | Cheapest of 361 $209 a month | 292nd of 361, with limits $2,295 a month |
| RL rollouts 1,000 at once · 2 vCPU / 4 GB · 1,000,000 sessions of 3 min a month Rollouts that are pure JavaScript or Wasm logic can run cheaply as isolates; rollouts that build, test or run tools need a full machine. | 34th of 360, with limits $2,000 a month | 333rd of 360, with limits $104 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 | 361st of 364, with limits $5,778 a month |
| CI runners 40 at once · 8 vCPU / 16 GB · 6,000 sessions of 12 min a month CI jobs install packages, run test suites and build images, which needs a real OS and minutes of CPU, so isolates do not fit this one. | 4th cheapest of 377 $86 a month | 368th of 377, with limits $6,649 a month |
| 24/7 dev boxes 1 machine 24/7 · 4 vCPU / 8 GB | 18th cheapest of 368 $26 a month | 292nd of 368, with limits $197 a month |
| Computer-use agents 50 at once · 4 vCPU / 8 GB · 20,000 sessions of 15 min a month Computer-use agents need a desktop and a browser, which bochka ships with a 60fps stream; a Worker has no screen and no browser inside it. | 6th cheapest of 369 $200 a month | 215th of 369, with limits $778 a month |
| Browser-use agents 50 at once · 2 vCPU / 4 GB · 30,000 sessions of 10 min a month A Worker cannot run Chromium itself; on Cloudflare that is a separate product, while bochka runs Chromium inside the sandbox. | 7th cheapest of 367 $200 a month | 244th of 367, with limits $398 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 | 332nd of 346, with limits $2,308 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 | 316th of 338, with limits $46,098 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 | 342nd of 360, with limits $2,891 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 | Cloudflare Workers for Platforms |
|---|---|---|
| Isolation | Full VM with its own kernel on dedicated AMD Ryzen 9 9950X hosts | V8 isolate per Worker inside a shared runtime, with a second sandbox layer around it |
| What code runs | Anything that runs on Linux: any language, binaries, Docker, systemd | JavaScript, TypeScript, Python and Rust, other languages through WebAssembly |
| Machine size | Up to 16 vCPU / 32 GB, depending on plan | One isolate with up to 128 MB of memory |
| How long code can run | No session cap on paid plans; you set the time to live | Up to 30 seconds of CPU per request (15 minutes for Cron and Queue); wall time not limited while the client stays connected |
| Files between runs | Disk kept; snapshot every minute and on stop; a stopped sandbox costs nothing | Memory-based /tmp, unique to each request; keep state in KV, D1, R2 or Durable Objects |
| Fork | Fork a running sandbox with its disk | No fork; there is no machine to copy |
| Docker, root and nested virtualization | Full Docker, root, systemd and /dev/kvm | No OS access: no shell, no Docker, no root |
| Desktop and browser | 60fps desktop and Chromium, computer-use API, embeddable stream | None inside a Worker |
| Start time | A VM boots per sandbox | Isolates skip the VM boot; Cloudflare says they start about a hundred times faster than a Node process in a VM |
| Inbound traffic | HTTPS URLs for up to 50 ports, token-protected; raw TCP; own IPv6 or IPv4 | HTTP through your dispatch Worker on your domain or customer hostnames; no raw TCP or own IP |
| Outbound control | No provider-side allowlist | An outbound Worker you write sees every fetch and can allow, block, log or change it |
| Keeping keys out of the code | Managed proxy for model providers and any HTTPS API; switch a credential to another account | Your outbound Worker adds credentials to requests, so customer code never sees them; you write and run that code |
| Coding agents | Claude Code, Codex, OpenCode and more built in, with a prompt, steer and events API | None; it runs code you or your customers deploy |
| Regions | EU only: Germany, Finland, France | Cloudflare's global network, hundreds of cities |
| 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 | Cloudflare Workers for Platforms |
|---|---|---|
| Full VM (own kernel) | Yes | No |
| Docker inside | Yes | No |
| Nested virtualization | Yes | No |
| Root | Yes | No |
| Systemd | Yes | No |
| 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 | No |
| Live fork (no pause) | Yes | No |
| Memory fork | No | No |
| Custom image (Docker or snapshot) | Yes | No |
| ≥24 h sessions | Yes | Yes |
| Idle auto-stop | No | Yes |
| Wake on request | No | Yes |
| HTTPS preview URLs | Yes | Yes |
| Raw TCP inbound | Yes | No |
| Public IPv4 | No | No |
| Egress allowlist | No | Yes |
| Secret proxy | Yes | Yes |
| Secret proxy for any API | Yes | Yes |
| 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 | Yes |
| Scoped API keys | Yes | Yes |
| Spend limits | Yes | Not published |
| Usage per sandbox (API) | Yes | No |
| Audit logs | No | Yes |
| SSO | No | Yes |
| SOC 2 | No | Yes |
| HIPAA | No | Yes |
| EU data residency | Yes | Yes |
| Zero data retention | Yes | Not published |
Performance
bochka has a CPU score of 26.69 runs per second on the hpc-sandbox-benchmarks Node.js build-and-test loop at 4 vCPU / 8 GB. Workers for Platforms has no result on that benchmark, and a 128 MB single isolate could not run it, so there is no comparable measurement.
Node.js build-and-test loop at 4 vCPU / 8 GB, higher is better. Measured with the open hpc-sandbox-benchmarks suite. Cloudflare Workers for Platforms 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 | Cloudflare Workers for Platforms, 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 | $261 · Workers for Platforms · with limits |
| One agent that never stops 4 vCPU / 8 GB, 50 GB disk, running 24/7 all month | $26 · $20/mo | $1,027 · Workers for Platforms · 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 | $12,183 · Workers for Platforms · 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 | $3,474 · Workers for Platforms · 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 | $20,847 · Workers for Platforms · with limits |
bochka: You pay a monthly plan from $20, and all of it is usage credit, billed per second while a sandbox runs. A stopped sandbox costs nothing and keeps its disk.
Cloudflare Workers for Platforms: Workers for Platforms costs $25 a month with 20 million requests, 60 million CPU milliseconds and 1,000 scripts included, then $0.30 per million requests, $0.02 per million CPU milliseconds and $0.02 per extra script. Wall time and memory are not billed.
Cloudflare Workers for Platforms: The scenario prices here are an estimate that treats each sandbox as a run of isolates on the $25 Workers for Platforms plan, billed per request and per CPU millisecond. They are only a rough guide, since none of the five scenarios fits a 128 MB isolate.
Limits in those scenarios
Every scenario on this page assumes a machine with several vCPU, gigabytes of memory and a disk that lasts, and a Worker has one isolate with 128 MB of memory and no lasting files, so none of them fit on Workers for Platforms. The 30-second CPU limit per request also rules out long builds and agent steps. On bochka, the 1,000-job burst runs into start limits instead: the $2,000 plan allows 600 starts an hour, and bursts above 90 starts a minute wait in a queue.
| Scenario | bochka | Cloudflare Workers for Platforms |
|---|---|---|
| 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 Cloudflare Workers for Platforms when
your customers or an AI write small JavaScript, Python or Wasm apps that answer web requests, and you want to host thousands of them near users worldwide.
- Thousands of tiny tenants at the edge. Fits platforms that host many small customer apps or functions, started in milliseconds near each user worldwide.
- Billing by request and CPU time. Fits short, request-shaped code: you pay per request and per CPU millisecond, and time spent waiting is free.
- Programmable control around customer code. Platform owners can set per-customer CPU limits and inspect, block or change every outbound request in their own code.
Use bochka when
your agents need a real computer: a shell, packages, Docker, a browser and a disk that keeps their work, running for hours.
- A whole Linux machine, not a script runner. Coding agents spend their day running git, package managers, compilers and tests. None of those run in a 128 MB isolate with no OS, so on Workers for Platforms the agent has nowhere to do its work.
- A disk that stays, with snapshots and fork. An agent that clones a repo and installs packages would lose all of it after one request on Workers. The workaround is writing every file to R2, KV or Durable Objects yourself, which most tools were never built to do.
- Coding agents you drive from outside. Workers for Platforms runs code you deploy; it has no agent to start. Coding agents also need a shell and minutes of CPU per step, past the 30-second CPU limit per request.
Questions people ask
Is Workers for Platforms a sandbox for AI agents?
It is a sandbox for code, not for an agent's whole workspace. It runs JavaScript, TypeScript, Python or Wasm in V8 isolates, one request at a time, with 128 MB of memory. Agents that need a shell, packages or files that last need a full machine like bochka.
Is bochka cheaper than Cloudflare Workers for Platforms?
For the five agent scenarios on this page, the estimate puts bochka lower each time, but none of them actually fit in a Worker. For small request-shaped functions, Workers for Platforms bills per request and CPU millisecond, which is hard to beat.
Can I run Docker or Linux tools in a Worker?
No. A Worker has no shell, no OS and no Docker; it only gets the JavaScript and Wasm APIs Cloudflare exposes. bochka sandboxes are full VMs with root, systemd, Docker and /dev/kvm.
Does a Worker keep files between requests?
No. Its file system lives in memory, and /tmp is unique to each request. You keep state in KV, D1, R2 or Durable Objects. bochka keeps the sandbox disk and snapshots it every minute.
Can I control what customer code connects to?
On Workers for Platforms, yes: an outbound Worker sees every fetch from customer Workers and can block, log or change it. bochka does not offer a provider-side egress allowlist today; it keeps real API keys outside the sandbox with its credentials proxy.
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