bochka vs Heroku
Heroku is a platform for hosting web apps: your code runs in dynos, non-root containers that restart every day and start again from a clean copy of your code. bochka gives each agent a full VM with root, Docker and a disk that stays, with a desktop and coding agents you drive from outside.
Where bochka stands out
A disk that stays
A bochka sandbox keeps its disk when it stops, saves it every minute and on stop, and costs nothing while stopped. A Heroku dyno gets a fresh copy of your code each time it starts, and any file it writes is gone when it stops or restarts. Heroku restarts every dyno at least once a day.
A full VM with root and Docker
Every bochka sandbox is a VM with its own kernel, root, systemd, Docker and /dev/kvm. Heroku runs your code in hardened containers as a non-root user, so you can deploy a Docker image there but not run Docker, install system packages or boot an emulator inside it.
Coding agents you drive from outside
bochka ships Claude Code, Codex, OpenCode and other agents in every sandbox, and your app can prompt them, steer them mid-task and stream their events through an API. Its credentials proxy keeps real AI keys outside the sandbox and can switch to another account when one 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
Heroku
Heroku is a platform as a service (PaaS) owned by Salesforce: you push code and it runs your web apps, workers and databases.
You deploy an app with git or a Docker image, and Heroku runs it in dynos, hardened Linux containers that run as a non-root user and get a fresh filesystem on every start. It also sells managed Postgres, Key-Value Store, Kafka and a marketplace of add-ons, plus Private Spaces with their own network in ten regions. It is built for teams hosting web apps and APIs, not for handing a machine to an agent, so this page compares the parts where the two overlap.
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 | Heroku: 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 installs and half-done work; a dyno discards its files on every restart and restarts at least once a day. | 3rd cheapest of 367 $634 a month | 305th of 367, with limits $6,023 a month |
| Always-on AI employees 50 machines 24/7 · 2 vCPU / 4 GB An always-on assistant on Heroku lives in a worker dyno that is restarted daily from a clean copy of your code, so its memory and files must live in Postgres or an add-on. | 5th cheapest of 366 $657 a month | 311th of 366, with limits $7,450 a month |
| Code interpreter bursts 100 at once · 1 vCPU / 2 GB · 200,000 sessions of 1 min a month Heroku's MCP server can run code in a one-off dyno and clean it up, which suits short scripts, but there is no root, Docker or desktop inside. | 186th of 345, with limits $2,000 a month | 310th of 345, with limits $1,157 a month |
| Sandboxes for your users 300 at once · 2 vCPU / 4 GB · 30,000 sessions of 23 min a month Giving each of your users their own machine on Heroku means one app or dyno per user in a shared container platform, with no per-user disk to keep. | Cheapest of 361 $209 a month | 311th of 361, with limits $3,144 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 | 289th of 360, with limits $11,359 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 | 317th of 364, with limits $2,667 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 Heroku dynos run as a non-root user with no Docker inside. | 4th cheapest of 377 $86 a month | 310th of 377, with limits $833 a month |
| 24/7 dev boxes 1 machine 24/7 · 4 vCPU / 8 GB A dev box needs a home directory that survives the night; on Heroku every restart wipes it, and SSH through Heroku Exec is not available on Fir or Shield apps. | 18th cheapest of 368 $26 a month | 195th of 368, with limits $500 a month |
| Computer-use agents 50 at once · 4 vCPU / 8 GB · 20,000 sessions of 15 min a month Heroku dynos are headless containers with no desktop to stream or drive, so computer-use agents fit only as a compromise. | 6th cheapest of 369 $200 a month | 318th of 369, with limits $2,500 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 | 334th of 367, with limits $1,750 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 | 323rd of 346, with limits $1,542 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 | 244th of 338, with limits $11,833 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 | 327th of 360, with limits $1,495 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 | Heroku |
|---|---|---|
| Kind of product | Sandboxes for agents: one full VM per sandbox | App platform: you deploy code and it runs web and worker processes |
| Isolation | Every sandbox is a full VM with its own kernel | Hardened OS containers that share a kernel; some tiers get a dedicated compute instance |
| Root, Docker and nested virtualization | Root, systemd, Docker and /dev/kvm on every machine | Containers run without root; you can deploy a Docker image, but not run Docker inside a dyno |
| Files after a stop or restart | The disk is kept, with snapshots every minute and on stop; a stopped sandbox costs nothing | Ephemeral filesystem: files are discarded when the dyno stops or restarts; no volumes |
| How long one machine runs | No session cap on paid plans; a sandbox can run for weeks | Every dyno, one-off dynos too, is restarted at most 24 hours plus 216 minutes after its last restart |
| Fork and snapshots | Fork a running sandbox; named snapshots to start new ones (disk only, no memory) | No dyno snapshot or fork; new dynos start from the deployed release |
| Reaching the machine | HTTPS URLs for up to 50 ports, token-protected; raw TCP; dedicated IPv6 or IPv4 | One HTTP port per app on the web process, custom domains; no raw TCP inbound or public IP per dyno |
| Shell access | SSH and a command API on every sandbox | Heroku Exec SSH tunnels on Cedar apps; not available on Fir apps or in Shield spaces |
| Desktop and computer use | 60fps desktop and Chromium, computer use and browser control, embeddable stream | Headless containers only |
| Coding agents | Claude Code, Codex, OpenCode and more preinstalled, with a prompt, steer and events API | An MCP server lets agents deploy, scale and run code in one-off dynos; no coding agents inside dynos |
| Keeping keys out of the machine | AI credentials proxy for model providers and any HTTPS API you register; switch a credential to another account when credits run out | Secrets are config vars, exposed to the code as environment variables |
| Managed databases and add-ons | No hosted databases; run your own inside a sandbox | Managed Postgres, Key-Value Store and Kafka, plus a marketplace of add-ons |
| Biggest machine | 8 vCPU / 16 GB on the $20 plan, 16 vCPU / 32 GB from $100 | Up to 32 vCPU / 64 GB (Fir) or 126 GB of memory (Performance-2XL) |
| Regions | EU only: Germany, Finland, France | US and Europe, plus Private Spaces in ten cities across the Americas, Europe, Asia and Australia |
| 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 | Heroku |
|---|---|---|
| Full VM (own kernel) | Yes | No |
| 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 | 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 | Yes |
| Raw TCP inbound | Yes | No |
| 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 | Yes |
| 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 | Yes |
| Audit logs | No | Not published |
| SSO | No | Yes |
| SOC 2 | No | Yes |
| HIPAA | No | Yes |
| EU data residency | Yes | Yes |
| Zero data retention | Yes | Not published |
Performance
There is no comparable measurement. bochka did 26.69 Node.js build-and-test runs per second at 4 vCPU / 8 GB in StarSling's public benchmark, but Heroku has no result in that benchmark, so we cannot say which is faster.
Node.js build-and-test loop at 4 vCPU / 8 GB, higher is better. Measured with the open hpc-sandbox-benchmarks suite. Heroku 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 | Heroku, 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 | $1,066 · Private Space · with limits |
| One agent that never stops 4 vCPU / 8 GB, 50 GB disk, running 24/7 all month | $26 · $20/mo | $1,270 · Private Space · 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 | $4,300 · Private Space · 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 | $1,937 · Private Space · 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 | $3,072 · Private Space · 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.
Heroku: Heroku bills each dyno per second of wall-clock time while it is scaled above zero, capped at its monthly price. Dynos with a published vCPU count, like the 4 vCPU / 8 GB Fir dyno priced here, only run inside a Private Space, which has its own fee on top, so our bills include that fee. Disk is not sold because the filesystem is wiped on restart.
Limits in those scenarios
Heroku is marked as not a clean fit in every scenario because it is an app platform, and its dynos have no disk that survives a stop or the daily restart. That restart also caps any one run at about a day, which is why the always-on agent does not fit. For 1,000 short jobs at once, a Private Space allows at most 500 dynos. On bochka, the 1,000-job burst is queued above 90 starts a minute and needs more starts per day than the $2,000 plan allows.
| Scenario | bochka | Heroku |
|---|---|---|
| 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 Heroku when
you are hosting a web app or API with managed Postgres and add-ons, or you need regions in the US, Asia or Australia.
- Apps and databases in one place. Useful if you host a web app: Heroku runs it next to managed Postgres, Key-Value Store, Kafka and many add-ons.
- Regions around the world. Useful if your users are far from Europe: Private Spaces run in ten cities, from Oregon and Virginia to Tokyo and Sydney.
- Small apps that sleep. Useful for hobby web apps: Eco dynos sleep after 30 minutes without traffic and wake on the next request.
Use bochka when
an agent needs a machine of its own: a full VM with root and Docker that keeps its disk for weeks, with a desktop and coding agents you drive from outside.
- A disk that stays. An agent that cloned a repo, installed packages and left work half done loses all of it at the next daily restart on Heroku. The workaround is to push every file to Postgres or S3 yourself.
- A full VM with root and Docker. Agents install things with apt, run docker compose for tests and start Android emulators. On a dyno each of those fails, because there is no root and no Docker inside.
- Coding agents you drive from outside. Heroku's MCP server helps an agent deploy apps, but running the agent itself in a dyno means wiring it up yourself, with its API key in a config var that any code in the dyno can read.
Questions people ask
Can I run AI agents on Heroku?
You can run an agent's code in a worker or one-off dyno, and Heroku's MCP server lets agents deploy and run code there. But a dyno is a non-root container with no Docker inside, and its files are wiped on every restart, at least once a day. On bochka each agent gets a full VM that keeps its disk.
Is bochka cheaper than Heroku?
In every scenario we priced, yes. One coding agent on workdays comes to $20 a month on bochka and $1,066 on Heroku, and 50 agents in parallel come to $317 versus $4,300. Heroku's numbers use a 4 vCPU / 8 GB dyno, which needs a Private Space and its fee; small Common Runtime dynos cost much less but do not publish a vCPU count.
Do Heroku dynos keep their files?
No. Each dyno gets an ephemeral filesystem with a fresh copy of your deployed code, and any file it writes is discarded when it stops or restarts. Heroku points you to S3 or a database add-on for anything you want to keep. A bochka sandbox keeps its disk and saves it every minute.
Is a Heroku dyno a VM or a container?
A container. Heroku says it uses OS containerization with custom hardening, and some tiers get their own dedicated compute instance. Containers run without root. On bochka, every sandbox is a full VM with its own kernel.
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. Heroku runs regular apps in the US or Europe and Private Spaces in ten cities, including Dublin, Frankfurt and London in Europe.
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. Heroku sells Shield Private Spaces for HIPAA and PCI workloads.
Start a sandbox
Install the CLI, then run bochka new.
Product preview