Runloop vs Deno Sandbox
Runloop gives each coding agent a devbox it can keep for hours, with Docker-in-Docker, a desktop and arm64. Deno Sandbox gives short, locked-down runs in a 2 vCPU microVM that starts in under 200 ms and lives up to 30 minutes.
The companies and products
Runloop
Runloop is a US platform of sandboxes, called devboxes, for building, running and testing AI coding agents.
You get Linux devboxes built from Dockerfile-style blueprints, disk snapshots, HTTPS tunnels, agent gateways that hide API keys, and Axons, event streams that drive agents such as Claude Code. Each devbox runs in a micro-VM on Runloop's own bare-metal hypervisor, with a container layer inside. It is built for teams shipping coding agents, plus evaluation and RL fine-tuning work on the Enterprise plan.
- Compliance
- SOC 2 Type 2
- Architectures
- x86_64 and arm64 base blueprints
- Own-cloud deploy
- Deploy to VPC on AWS, GCP and Azure (Enterprise)
- Regions
- Not documented or selectable
- Company
- Runloop AI, Inc.
Deno Sandbox
Deno Sandbox is part of Deno Deploy, the hosting platform from the company behind the Deno runtime, and runs untrusted or AI-generated code in Linux microVMs.
Each sandbox is a Firecracker microVM with 2 vCPU, up to 4 GB of memory and a 10 GB disk that is wiped when it ends, created from a TypeScript or Python SDK. Outbound traffic goes through a proxy that can enforce a host allowlist and swap placeholder secrets for real ones. It is built for short runs of agent or user code, and a sandbox can be promoted to a Deno Deploy app.
- Isolation
- Firecracker microVM per sandbox
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. “20th cheapest of 367” means 19 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 | Runloop: price rank | Deno Sandbox: price rank | bochka: price rank |
|---|---|---|---|
| Software factory 100 at once · 4 vCPU / 8 GB · 2,200 sessions of 8 h a month Runloop fits a software factory; Deno's 30-minute lifetime and fixed 2 vCPU shape cut builds short, and bochka adds nested virtualization and faster CPUs. | 20th cheapest of 367 $8,152 a month | 290th of 367, with limits $5,665 a month | 3rd cheapest of 367 $634 a month |
| Always-on AI employees 50 machines 24/7 · 2 vCPU / 4 GB An assistant that lives on its machine all month fits Runloop with an idle policy, while a Deno sandbox ends after 30 minutes and wipes its disk. | 32nd cheapest of 366 $10,194 a month | 287th of 366, with limits $5,803 a month | 5th cheapest of 366 $657 a month |
| Code interpreter bursts 100 at once · 1 vCPU / 2 GB · 200,000 sessions of 1 min a month Short code runs suit both: Deno starts in under 200 ms and bills CPU only while code runs, and Runloop ranks 44th here, well above bochka. | 44th cheapest of 345 $525 a month | 141st of 345, with limits $329 a month | 186th of 345, with limits $2,000 a month |
| Sandboxes for your users 300 at once · 2 vCPU / 4 GB · 30,000 sessions of 23 min a month Deno Builder caps you at 20 sandboxes at once per region, while Runloop publishes no concurrency cap for paid plans and bochka's plans go to hundreds. | 26th cheapest of 361 $3,301 a month | 148th of 361, with limits $1,863 a month | Cheapest of 361 $209 a month |
| RL rollouts 1,000 at once · 2 vCPU / 4 GB · 1,000,000 sessions of 3 min a month Runloop ranks 4th for RL rollouts: it starts large waves without published start limits and sells RL fine-tuning on Enterprise. | 4th cheapest of 360 $15,922 a month | 122nd of 360, with limits $7,963 a month | 34th of 360, with limits $2,000 a month |
| Agent evals 250 at once · 4 vCPU / 8 GB · 15,000 sessions of 20 min a month | 81st cheapest of 364 $2,562 a month | 296th of 364, with limits $1,563 a month | 10th cheapest of 364 $200 a month |
| CI runners 40 at once · 8 vCPU / 16 GB · 6,000 sessions of 12 min a month Runloop runs Docker-in-Docker for CI jobs, Deno does not document Docker, and bochka's faster CPUs finish builds sooner. | 121st cheapest of 377 $1,554 a month | 304th of 377, with limits $731 a month | 4th cheapest of 377 $86 a month |
| 24/7 dev boxes 1 machine 24/7 · 4 vCPU / 8 GB | 113th cheapest of 368 $410 a month | 179th of 368, with limits $200 a month | 18th cheapest of 368 $26 a month |
| Computer-use agents 50 at once · 4 vCPU / 8 GB · 20,000 sessions of 15 min a month Runloop and bochka both ship a desktop and a browser your agent can control; Deno Sandbox has no desktop. | 39th cheapest of 369 $2,306 a month | 280th of 369, with limits $1,583 a month | 6th cheapest of 369 $200 a month |
| Browser-use agents 50 at once · 2 vCPU / 4 GB · 30,000 sessions of 10 min a month | 40th cheapest of 367 $1,153 a month | 284th of 367, with limits $783 a month | 7th cheapest of 367 $200 a month |
| Scraping & bots (startup scale) 50 at once · 1 vCPU / 2 GB · 100,000 sessions of 3 min a month | 68th cheapest of 346 $781 a month | 286th of 346, with limits $573 a month | 6th cheapest of 346 $90 a month |
| Mass scraping & bots (undetectable) 1,000 at once · 1 vCPU / 2 GB · 3,000,000 sessions of 2 min a month | 266th of 338, with limits $15,611 a month | 247th of 338, with limits $11,923 a month | 71st of 338, with limits $1,800 a month |
| Parallel red teaming 200 at once · 2 vCPU / 4 GB · 5,000 sessions of 30 min a month Runloop and Deno both lock a sandbox to a host allowlist; Runloop runs longer, and bochka gives each sandbox a full kernel with nested virtualization. | 10th cheapest of 360 $770 a month | 251st of 360, with limits $367 a month | 2nd cheapest of 360 $200 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 | 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 | Can't run it |
Key features
| Feature | Runloop | Deno Sandbox | bochka |
|---|---|---|---|
| Isolation | Micro-VM on a custom bare-metal hypervisor, plus a container layer | Firecracker microVM with its own kernel | Full VM with its own kernel on dedicated AMD Ryzen 9 9950X hosts |
| Machine size | 4 vCPU / 8 GiB sizes available, disk up to 64 GiB | 2 vCPU fixed, 768 MB to 4 GB memory, 10 GB disk | 4 vCPU / 8 GB by default, up to 16 vCPU / 32 GB on the $100 plan and above |
| Session length | Fixed lifetime 1 hour by default, 48 hours max; an idle policy replaces it | Up to 30 minutes; longer work can be promoted to a Deno Deploy app | No cap on paid plans; you set the time to live |
| Keeping files | Disk kept through suspend (Pro plan) or manual disk snapshots; shutdown ends the devbox | Root disk wiped when the sandbox ends; opt-in volumes of 300 MB to 20 GB, Chicago only | The whole disk is kept, saved every minute and on stop, on every plan; a stopped sandbox costs nothing |
| Docker and nested virtualization | Docker-in-Docker on the dnd blueprints, as root; nested virtualization not documented | Root access; Docker and nested virtualization not documented | Docker, systemd and /dev/kvm for Android emulators and VMs |
| Images | Blueprints built from Dockerfiles, plus disk snapshots | Read-only snapshots of a volume that new sandboxes can boot from | Templates from named snapshots, no Dockerfile builds |
| CPU architecture | x86_64 and arm64 | x86_64 | x86_64 only |
| Desktop and browser | Desktop and browser your agent can control | No desktop; a VS Code editor in the browser and SSH | Linux desktop streamed at 60fps, Chromium and computer use built in |
| Start time | Fast boot; no published start time | Under 200 ms | Boots a full VM |
| Inbound access | One HTTPS tunnel per devbox, open or bearer token; SSH through a TLS proxy; no public IP | HTTPS URL per exposed port, public without authentication; SSH | HTTPS URLs for up to 50 ports, token-protected by default, raw TCP, dedicated IPv6 or IPv4 |
| Outbound rules | Hostname allowlist with wildcards, or block all | Host allowlist per sandbox (allowNet), enforced by a proxy outside the VM | Open internet, no provider-side allowlist |
| Keeping API keys out of the sandbox | Agent gateways for any API endpoint with bearer, header or basic auth | Secrets swapped in on outbound requests to approved hosts | Credentials proxy for model providers and any HTTPS API; switch a credential to another account when credits run out |
| Coding agents | Claude Code, Codex, OpenCode, Gemini CLI, DeepAgents, driven through Axons and Broker | A root image with Claude Code, run through the shell command API | Seven agents preinstalled, with a prompt, steer and events API |
| Where it runs | Regions not documented; Deploy to VPC on AWS, GCP or Azure (Enterprise) | Amsterdam and Chicago | EU only (Germany, Finland, France), EU data residency |
Every feature Battleships tracks (43)
| Feature | Runloop | Deno Sandbox | bochka |
|---|---|---|---|
| Full VM (own kernel) | Yes | Yes | Yes |
| Docker inside | Yes | Not published | Yes |
| Nested virtualization | No | No | Yes |
| Root | Yes | Yes | Yes |
| Systemd | Not published | Not published | Yes |
| Desktop GUI | Yes | No | Yes |
| Browser | Yes | No | Yes |
| Computer-use API | Yes | No | Yes |
| SSH | Yes | Yes | Yes |
| Persistent disk | Yes | Yes | Yes |
| Pause/resume | Yes | No | Yes |
| Automatic snapshots | Yes | No | Yes |
| Fork/clone | Yes | No | Yes |
| Live fork (no pause) | Yes | No | Yes |
| Memory fork | No | No | No |
| Custom image (Docker or snapshot) | Yes | Yes | Yes |
| ≥24 h sessions | Yes | No | Yes |
| Idle auto-stop | Yes | No | No |
| Wake on request | Yes | No | No |
| HTTPS preview URLs | Yes | Yes | Yes |
| Raw TCP inbound | No | No | Yes |
| Public IPv4 | No | No | No |
| Egress allowlist | Yes | Yes | No |
| Secret proxy | Yes | Yes | Yes |
| Secret proxy for any API | Yes | Yes | Yes |
| Preinstalled agents | Yes | Yes | Yes |
| Agent harness API | Yes | No | Yes |
| MCP server | Yes | No | No |
| GPU | No | No | No |
| Windows | No | No | No |
| Arm64 | Yes | No | No |
| Self-hosting | No | No | No |
| BYOC | Yes | No | No |
| Open source | No | No | No |
| Scoped API keys | Yes | Not published | Yes |
| Spend limits | Not published | Yes | Yes |
| Usage per sandbox (API) | No | No | Yes |
| Audit logs | Not published | Not published | No |
| SSO | Yes | No | No |
| SOC 2 | Yes | Yes | No |
| HIPAA | Not published | Yes | No |
| EU data residency | No | Yes | Yes |
| Zero data retention | Not published | Not published | Yes |
Performance
On the StarSling hpc-sandbox-benchmarks Node.js build-and-test loop at 4 vCPU / 8 GB (run 36498291449, 2026-09-29), bochka scored 26.69 runs a second and Runloop 8.29, about 3.2 times apart. Deno Sandbox has no comparable measurement: it is not in that benchmark, and its fixed 2 vCPU shape could not run the 4 vCPU test as set up.
Node.js build-and-test loop at 4 vCPU / 8 GB, higher is better. Measured with the open hpc-sandbox-benchmarks suite. Deno Sandbox 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 | Runloop, a month | Deno Sandbox, a month | bochka, 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 | $113 · Basic | $53 · Pro · with limits | $20 · $20/mo |
| One agent that never stops 4 vCPU / 8 GB, 50 GB disk, running 24/7 all month | $429 · Basic | $200 · Builder · with limits | $26 · $20/mo |
| 50 agents in parallel 50 machines of 4 vCPU / 8 GB at once, 8-hour sessions, 1,100 sessions a month, Docker inside | $5,268 · Basic | $2,779 · Builder · with limits | $317 · $20/mo × 3 seats |
| Sandboxes for your users 2 vCPU / 4 GB, 30,000 sessions of 10 minutes a month, up to 300 at once | $1,441 · Basic | $783 · Builder · with limits | $200 · $100/mo × 2 seats |
| 1,000 short jobs at once 2 vCPU / 4 GB, 1,000 at once, 3 minutes each, 200,000 jobs a month | $3,184 · Basic | $1,563 · Builder · with limits | $2,000 · $2000/mo · with limits |
Runloop: Runloop bills per second for the CPU and memory you allocate, including while a devbox starts, suspends or resumes, and bills disk for the devbox's whole life. Basic has no plan fee; Pro adds $250 a month that is not usage credit and unlocks suspend and resume.
Deno Sandbox: Sandboxes need the Pro plan at $20 a month or Builder at $200 a month; the fee is not credit but includes CPU, memory and egress allowances shared with Deno Deploy apps. Past those, CPU costs $0.10 per hour of active CPU time and memory $0.025 per GiB-hour for the sandbox's whole life.
Deno Sandbox: Plans start at $20 a month and the whole fee is usage credit, billed per second while a sandbox runs. A stopped sandbox costs nothing and keeps its disk.
Limits in those scenarios
Runloop fits all five scenarios; its fixed lifetime tops out at 48 hours, but an idle policy replaces it, and it publishes no egress price. Deno Sandbox fits none of them as written: a sandbox lives up to 30 minutes and is fixed at 2 vCPU with up to 4 GB of memory, and Builder allows 20 sandboxes at once per region, short of 50 agents or 300 users. bochka fits four of five; at 1,000 short jobs at once its top plan queues starts above 90 a minute.
| Scenario | Runloop | Deno Sandbox | bochka |
|---|---|---|---|
| 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 Runloop when
your coding agents need a devbox for hours with Docker, a desktop, arm64 or Dockerfile images, or you launch very large bursts or want devboxes in your own cloud.
- Agents that run for hours. Useful for long agent tasks: a devbox runs up to 48 hours, or all month with an idle policy, not 30 minutes.
- A fuller dev machine. Fits coding agents that need Docker, a desktop, arm64 or Dockerfile images, none of which Deno Sandbox offers.
- Large bursts and your own cloud. Useful at scale: Runloop fits 1,000 jobs at once, and Enterprise can run devboxes in your own AWS, GCP or Azure account.
Use Deno Sandbox when
you run short pieces of untrusted code that must start in milliseconds, reach only the hosts you allow, or run in the US, especially if you already deploy on Deno Deploy.
- Fast starts and active-CPU billing. Good for short bursts of code: a sandbox starts in under 200 ms and CPU bills only while code runs.
- Known regions, US and EU. Fits teams who must know where code runs: sandboxes run in Chicago or Amsterdam, while Runloop does not document regions.
- A path to Deno Deploy. Fits teams already on Deno Deploy: a sandbox can be promoted to a Deploy app on the same meters.
Where bochka fits
If your agents do real work for hours, look at bochka. It gives each agent a full VM with its own kernel, on CPUs about three times faster than Runloop's in the same test, with the disk kept on every plan and no 30-minute cap.
Emulators, VMs and raw TCP
Neither Runloop nor Deno documents nested virtualization, so an Android emulator or a VM will not start. Both reach sandboxes through HTTPS only, so a raw TCP server has no way in. bochka gives /dev/kvm and raw TCP.
Files kept, no time limit
A Deno sandbox ends at 30 minutes and wipes its disk. A Runloop devbox loses its disk at shutdown unless you pay for the $250 Pro plan to suspend it or write snapshot code. bochka saves every minute and stops for free.
About three times the CPU speed
On the same Node.js build-and-test loop at 4 vCPU / 8 GB, bochka ran 26.69 runs a second and Runloop 8.29. Deno is fixed at 2 vCPU, so builds and tests that want more simply wait longer.
Use bochka when your agents do real work for hours: installs, builds, tests, Docker, emulators and a browser, on faster CPUs, with a disk that is still there tomorrow on every plan. Compare it one to one: bochka vs Runloop and bochka vs Deno Sandbox.
Questions people ask
Is Runloop cheaper than Deno Sandbox?
Deno's bills come out lower, but it does not fit our scenarios as written. One coding agent on workdays is $113 a month on Runloop and $53 on Deno, but Deno can only offer 2 vCPU and 30-minute sessions. On bochka the same agent costs $20 a month on a full 4 vCPU / 8 GB machine.
Which is faster, Runloop or Deno Sandbox?
Deno starts a sandbox in under 200 ms. For CPU work there is no shared measurement: Runloop scored 8.29 runs a second on the Node.js build-and-test benchmark at 4 vCPU / 8 GB, and Deno's 2 vCPU shape is not in it. bochka scored 26.69 on the same test.
Can Runloop or Deno Sandbox run Docker?
Runloop runs Docker-in-Docker on its dnd blueprints, as root. Deno's docs do not say Docker works inside a sandbox. Neither documents nested virtualization; bochka runs Docker and systemd and exposes /dev/kvm for Android emulators and VMs.
How long can a sandbox run on each?
A Deno sandbox lives up to 30 minutes and can be promoted to a Deno Deploy app for longer work. A Runloop devbox runs up to 48 hours on its lifetime timer, or longer with an idle policy. A bochka sandbox has no lifetime cap on paid plans.
Can I limit which hosts a sandbox can reach?
Yes on both. Runloop network policies allow only the hostnames you list, with wildcards, or block all traffic, and Deno enforces a host allowlist at a proxy outside the VM. bochka has no provider-side egress allowlist, so you filter inside the VM.
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.
Try bochka
Install the CLI, then run bochka new.
Product preview