Beam vs Deno Sandbox
Beam is a serverless GPU platform whose gVisor sandboxes can run until you stop them, with separate CPU VMs that keep their disk. Deno Sandbox gives short runs of untrusted code a locked-down 2 vCPU Firecracker microVM that starts in under 200 ms and lives up to 30 minutes.
The companies and products
Beam
Beam is a serverless cloud for GPU inference, sandboxes and background jobs, built on its open-source runtime Beta9.
Beam runs functions, REST endpoints, task queues, pods, sandboxes and VMs on CPUs and GPUs, all from a Python or TypeScript SDK. A sandbox is a container isolated with gVisor that starts in a second or two, lives until you terminate it or its time to live runs out, and can be saved as a filesystem image or a memory snapshot. Beam VMs are a separate CPU product: a microVM with its own kernel, systemd and a root disk that stays when it stops. Much of Beam is a GPU serverless platform for AI teams.
- Bring your own cloud
- Management fee per vCPU and GB of RAM, on top of your own cloud bill
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. “8th cheapest of 345” means 7 of the other 344 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 | Beam: 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 A software factory runs installs, builds and Docker for hours, which outlasts Deno's 30-minute lifetime; Beam sandboxes can run that long but have no systemd or /dev/kvm, which bochka gives every sandbox. | 69th of 367, with limits $551 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 | 115th of 366, with limits $651 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 Beam fits this well, with sandboxes that start in a second or two and end on their own when the timer runs out; Deno starts faster but caps Builder at 20 sandboxes at once per region. | 8th cheapest of 345 $117 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 Beam and bochka both fit a sandbox per user; Deno caps Builder at 20 at once per region, and its public URLs have no built-in auth. | 3rd cheapest of 361 $290 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 | 341st of 360, with limits $939 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 | 13th cheapest of 364 $251 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 Both Beam and bochka fit CI jobs, but builds that need Android emulators or VM images need /dev/kvm, which only bochka documents. | 12th cheapest of 377 $171 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 Beam VMs and bochka both keep their disk while stopped, so either works as a dev box; a Deno sandbox wipes its root disk when it ends. | 13th cheapest of 368 $21 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 Neither Beam nor Deno has a desktop or browser product; bochka streams a Linux desktop at 60fps with Chromium for computer use. | 111th of 369, with limits $237 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 | 195th of 367, with limits $176 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 | 200th of 346, with limits $131 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 | 42nd of 338, with limits $923 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 | 175th of 360, with limits $155 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 Only Beam has GPUs here, from RTX 4090 up to H100 and B200; Deno Sandbox and bochka are CPU only. | Cheapest of 98 $458 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 | Can't run it |
Key features
| Feature | Beam | Deno Sandbox | bochka |
|---|---|---|---|
| Isolation | gVisor container by default for sandboxes; separate Beam VMs are CPU microVMs with their own kernel | Firecracker microVM with its own kernel | Full VM with its own kernel on dedicated AMD Ryzen 9 9950X hosts |
| Machine size | You request CPU cores and memory; one billed core is two vCPU; maximum size not published | 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 |
| Lifetime | Default 10 minutes; set -1 to run until you terminate it | Up to 30 minutes; longer work can be promoted to a Deno Deploy app | No session cap on paid plans; you set the time to live |
| Disk between runs | A sandbox ends with its time to live unless you save an image or use a volume; a Beam VM keeps a 50 GiB root disk while stopped | Root disk wiped when the sandbox ends; opt-in volumes of 300 MB to 20 GB, Chicago only | The whole disk is saved every minute and on stop, and a stopped sandbox keeps it for free |
| Snapshots and fork | Memory snapshot of a running sandbox with its processes, restored into new sandboxes | Read-only snapshots of a volume that new sandboxes can boot from; no fork of a running sandbox | Automatic disk snapshots; fork a running sandbox with its disk |
| Docker, systemd and nested virtualization | Docker inside sandboxes with docker_enabled; systemd only in Beam VMs; no /dev/kvm documented | Root access; Docker, systemd and nested virtualization not documented | Docker, systemd, root and /dev/kvm for Android emulators and VMs |
| GPUs | GPU sandboxes and serverless GPUs up to H100, H200 and B200 | No, CPU only | No, CPU only |
| Desktop and browser | No desktop or browser product | No desktop; a VS Code editor in the browser and SSH | Linux desktop streamed at 60fps with Chromium and computer use |
| Inbound access | A public HTTPS URL per exposed port with no built-in auth; no raw TCP or dedicated IP | A public HTTPS URL per exposed port without authentication; SSH | HTTPS URLs for up to 50 ports, token-protected by default; raw TCP; dedicated IPv4 or IPv6 |
| Outbound rules | Block all outbound traffic, or allow up to 10 CIDR ranges, changeable while running | 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 | Secrets are exposed as environment variables inside the sandbox | Secrets swapped in on outbound requests to approved hosts; the sandbox only sees a placeholder | Credentials proxy for model providers and any HTTPS API; switch a credential to another account when credits run out |
| Coding agents | None preinstalled; you install and run them through process exec | A root image with Claude Code, run through the shell command API | Seven agents preinstalled, driven from outside with a prompt, steer and events API |
| Start time | Cold boot in 1 to 3 seconds, by Beam's own guide | Under 200 ms | Boots a full VM |
| Regions | US only; no other region is listed | Amsterdam and Chicago | EU only (Germany, Finland, France) |
Every feature Battleships tracks (43)
| Feature | Beam | Deno Sandbox | bochka |
|---|---|---|---|
| Full VM (own kernel) | No | Yes | Yes |
| Docker inside | Yes | Not published | Yes |
| Nested virtualization | No | No | Yes |
| Root | Yes | Yes | Yes |
| Systemd | No | Not published | Yes |
| Desktop GUI | No | No | Yes |
| Browser | No | No | Yes |
| Computer-use API | No | No | Yes |
| SSH | Yes | Yes | Yes |
| Persistent disk | Yes | Yes | Yes |
| Pause/resume | No | No | Yes |
| Automatic snapshots | No | No | Yes |
| Fork/clone | Yes | No | Yes |
| Live fork (no pause) | Yes | No | Yes |
| Memory fork | Yes | No | No |
| Custom image (Docker or snapshot) | Yes | Yes | Yes |
| ≥24 h sessions | Yes | No | Yes |
| Idle auto-stop | No | No | No |
| Wake on request | No | 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 | No | Yes | Yes |
| Secret proxy for any API | No | Yes | Yes |
| Preinstalled agents | No | Yes | Yes |
| Agent harness API | No | No | Yes |
| MCP server | Yes | No | No |
| GPU | Yes | No | No |
| Windows | No | No | No |
| Arm64 | No | No | No |
| Self-hosting | Yes | No | No |
| BYOC | Yes | No | No |
| Open source | Yes | No | No |
| Scoped API keys | Not published | Not published | Yes |
| Spend limits | Not published | Yes | Yes |
| Usage per sandbox (API) | No | No | Yes |
| Audit logs | Not published | Not published | No |
| SSO | No | No | No |
| SOC 2 | Yes | Yes | No |
| HIPAA | Yes | Yes | No |
| EU data residency | Not published | Yes | Yes |
| Zero data retention | Not published | Not published | Yes |
Performance
There is no comparable measurement for either: neither Beam nor Deno Sandbox has a result on the StarSling hpc-sandbox-benchmarks CPU test, so we cannot say which runs CPU work faster. bochka did 26.69 runs per second on that test at 4 vCPU / 8 GB. For start time, Deno says its sandboxes start in under 200 ms, and Beam's guide says its sandboxes cold-boot in 1 to 3 seconds.
Node.js build-and-test loop at 4 vCPU / 8 GB, higher is better. Measured with the open hpc-sandbox-benchmarks suite. Beam and Deno Sandbox have 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 | Beam, 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 | $5 · Developer | $53 · Pro · with limits | $20 · $20/mo |
| One agent that never stops 4 vCPU / 8 GB, 50 GB disk, running 24/7 all month | $22 · Developer | $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 | $410 · Team | $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 | $191 · Team | $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 | $259 · Team | $1,563 · Builder · with limits | $2,000 · $2000/mo · with limits |
Beam: Beam sandboxes bill per second for each CPU core (one core is two vCPU) and each GiB of RAM you request, until you terminate them or their time to live ends, so an idle tail is billed too. Developer has no fee; Team costs $89 a month plus usage, with no usage credit, and there are no egress fees.
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 your Deno Deploy apps. Past those, CPU costs $0.10 per hour of active CPU time and memory $0.025 per GiB-hour for the whole life of the sandbox.
Deno Sandbox: Plans start at $20 a month, and the whole fee is usage credit. You pay per second while a sandbox runs, and a stopped sandbox costs nothing and keeps its disk.
Limits in those scenarios
Deno Sandbox fits none of the five scenarios as written: a sandbox lives up to 30 minutes, is fixed at 2 vCPU with up to 4 GB of memory, and Builder allows 20 at once per region. Beam fits all five, though its Developer plan allows 30 CPU containers at once, so 50 parallel agents need Team, and Beam publishes no disk price, so the scenarios count no disk cost for it. bochka fits four of the five; at 1,000 short jobs at once its top plan queues starts.
| Scenario | Beam | 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 Beam when
your work needs GPUs, when sandboxes must run longer than half an hour, when you want CPU VMs that keep their disk in the US, or when you must self-host.
- GPUs in the same platform. For work that needs a GPU, Beam offers GPU sandboxes and serverless GPUs from RTX 4090 to H100, H200 and B200.
- Sandboxes that run as long as you need. A Beam sandbox can run until you terminate it, and Beam VMs keep a 50 GiB root disk while stopped.
- Open source and your own cloud. Its Beta9 runtime is AGPL-3.0 and free to self-host, and Beam can also run in your own cloud for a fee.
Use Deno Sandbox when
you run short pieces of untrusted code that must start in milliseconds and reach only the hosts you allow, 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.
- Locked-down outbound traffic and secrets. Each sandbox can be limited to a list of hosts, and real secrets are swapped in only on requests to those hosts.
- Two regions and a path to Deno Deploy. Sandboxes run in Amsterdam or Chicago, and one can be promoted to a Deno Deploy app when the code should go live.
Where bochka fits
Beam and Deno Sandbox both suit short or GPU-heavy jobs, but neither gives an agent a full Linux server with a desktop, coding agents and a disk that keeps itself. If your agents install, build and test for hours, run Docker or emulators, or need a browser they can see, look at bochka. It gives every sandbox a full VM with its own kernel, saves the disk every minute and lets you fork a running sandbox.
A full VM with /dev/kvm
A Beam sandbox is a gVisor container without systemd, and Beam VMs document no /dev/kvm. Deno is fixed at 2 vCPU and 4 GB and does not document Docker or nested virtualization, so emulators and nested VMs have nowhere to start.
A machine that stays
A Deno sandbox ends after 30 minutes and wipes its root disk. A Beam sandbox ends with its time to live unless you save an image or attach a volume. bochka has no session cap on paid plans and a stopped sandbox keeps its disk for free.
Agents, desktop and hosting built in
On Beam you install agents yourself, and on Deno you run Claude Code through shell commands and parse the output. Neither has a desktop, and both give public URLs with no built-in auth, while bochka token-protects 50 ports and serves raw TCP.
Use bochka when your agents do real work for hours or days: installs, builds, Docker, emulators and a browser on a full VM whose disk is still there the next time it starts. Compare it one to one: bochka vs Beam and bochka vs Deno Sandbox.
Questions people ask
Is Beam cheaper than Deno Sandbox?
In all five scenarios on this page, yes. For example, one agent that never stops costs $22 a month on Beam against $200 on Deno Builder, and 50 agents in parallel cost $410 against $2,779. Deno Sandbox also does not fit any of the five as written, while Beam fits all of them.
Which is faster, Beam or Deno Sandbox?
Neither has a result on the StarSling CPU benchmark, so there is no fair CPU comparison. Deno says a sandbox starts in under 200 ms, while Beam's guide says its sandboxes cold-boot in 1 to 3 seconds.
Can Beam or Deno Sandbox run Docker?
Beam supports Docker inside a sandbox with docker_enabled. Deno's docs do not say Docker works inside a sandbox. bochka runs Docker and systemd in a full VM and exposes /dev/kvm for emulators and VMs.
How long can a sandbox run on each?
A Deno sandbox lives up to 30 minutes, and you can promote it to a Deno Deploy app for longer work. A Beam sandbox defaults to 10 minutes but can run until you terminate it. A bochka sandbox has no session cap on paid plans.
Do Beam and Deno Sandbox keep files?
A Deno sandbox wipes its root disk when it ends, unless data sits on a volume, which is only in Chicago. A Beam sandbox keeps files only in a saved image, a snapshot or a volume, while a Beam VM keeps its root disk while stopped. bochka saves the whole disk every minute and on stop.
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