Deno Sandbox vs smol machines

Both run code in a Linux microVM with its own kernel. Deno Sandbox is built for short, locked-down runs of up to 30 minutes on a fixed 2 vCPU machine, while smol machines gives you bigger VMs with no lifetime cap that you can branch live and even run on your own servers.

The companies and products

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
Machine size: 2 vCPU, 768 MB to 4 GB memory, 10 GB ephemeral disk
Lifetime: Bound to a session, up to 30 minutes
Regions: Amsterdam and Chicago; volumes only in Chicago
Plans: Sandboxes on Pro and Builder; 3 or 20 at once per region
Compliance: Deno Deploy states SOC2 and ISO27001; HIPAA BAA for enterprise contracts

smol machines

smol machines makes fast, isolated Linux microVMs that run the same way on your laptop, in their hosted cloud, or on your own servers.

The core is smolvm, an open-source microVM engine built on libkrun, where each machine has its own guest kernel. smol cloud is the paid hosted service that runs fleets of those machines behind a REST API and Node, Python and Rust SDKs. It is built for developers who want one VM model from local development to production, with live branching of running machines.

Isolation: Hardware-isolated microVM with its own guest kernel (libkrun)
Company: Founded 2026, Y Combinator Spring 2026, San Francisco, team of one listed
Open source: smolvm engine and smol SDK are open source and run on macOS, Linux and Windows hosts
Guests: Linux only; no Windows or macOS guests
Regions: No region field in the cloud create API
Uptime SLA: 99.95% on Pro, Startup and Enterprise

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. “290th cheapest of 367” means 289 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	Deno Sandbox: price rank	smol machines: 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 builds and Docker for hours, which outlasts Deno's 30-minute lifetime; smol machines has no lifetime cap, and bochka adds /dev/kvm, SSH and coding agents you drive from outside.	290th of 367, with limits $5,665 a month	73rd of 367, with limits $604 a month	3rd cheapest of 367 $634 a month
Always-on AI employees 50 machines 24/7 · 2 vCPU / 4 GB	287th of 366, with limits $5,803 a month	148th of 366, with limits $1,038 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 Both suit short code runs, but smol machines ranks 12th of 345 with a full match, while Deno Sandbox ranks 141st because Builder runs only 20 sandboxes at once per region.	141st of 345, with limits $329 a month	12th cheapest of 345 $140 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 smol machines ranks 7th and fits, while Deno caps Builder at 20 sandboxes at once per region; bochka ranks 1st with a desktop, token-protected hosting and a credentials proxy for each user.	148th of 361, with limits $1,863 a month	7th cheapest of 361 $531 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 smol machines can branch a running machine with its memory and processes, so many rollouts start from one prepared state; a Deno sandbox cannot be forked.	122nd of 360, with limits $7,963 a month	111th of 360, with limits $6,978 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 smol machines ranks 36th with a full match and can branch a warm machine for each eval, while Deno ranks 296th because of its 30-minute cap and 20 at once.	296th of 364, with limits $1,563 a month	36th cheapest of 364 $670 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 smol machines fits CI with Docker inside the VM, Deno does not document Docker, and only bochka exposes /dev/kvm for jobs that boot Android emulators or VMs.	304th of 377, with limits $731 a month	66th cheapest of 377 $514 a month	4th cheapest of 377 $86 a month
24/7 dev boxes 1 machine 24/7 · 4 vCPU / 8 GB A dev box that stays on all month rules out Deno's 30-minute sandboxes; smol machines keeps its files across a stop but bills the disk while stopped, while a stopped bochka sandbox costs nothing.	179th of 368, with limits $200 a month	216th of 368, with limits $29 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 Deno Sandbox nor smol machines has a hosted desktop; bochka streams a Linux desktop at 60fps with Chromium and computer use built in.	280th of 369, with limits $1,583 a month	90th of 369, with limits $156 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	284th of 367, with limits $783 a month	176th of 367, with limits $136 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	286th of 346, with limits $573 a month	241st of 346, with limits $242 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	247th of 338, with limits $11,923 a month	148th of 338, with limits $4,344 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	251st of 360, with limits $367 a month	252nd of 360, with limits $377 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	Deno Sandbox	smol machines	bochka
Isolation	Firecracker microVM with its own kernel	libkrun microVM with its own guest kernel	Full VM with its own kernel on dedicated AMD Ryzen 9 9950X hosts
Machine size	2 vCPU fixed, 768 MB to 4 GB memory, 10 GB disk	Up to 8 vCPU / 16 GB on Standard, 16 vCPU / 24 GB on Pro, 32 vCPU / 32 GB on Startup	4 vCPU / 8 GB by default, up to 16 vCPU / 32 GB on the $100 plan and above
Session length	Up to 30 minutes; longer work can be promoted to a Deno Deploy app	No provider cap; an optional lifetime you set yourself	No cap on paid plans; you set the time to live
Disk that persists	Root disk wiped when the sandbox ends; opt-in volumes of 300 MB to 20 GB, Chicago only	Filesystem survives a stop, /tmp and other memory paths are emptied; disk keeps billing while stopped	The whole disk is kept, saved every minute and on stop; a stopped sandbox costs nothing
Snapshots and fork	Read-only snapshots of a volume that new sandboxes can boot from; no fork of a running sandbox	Branch a running machine with its memory and processes; checkpoints capture RAM to a file	Automatic disk snapshots; fork a running sandbox with its disk
Start and wake	Starts in under 200 ms; no wake on request	A command or terminal starts a stopped machine; idle apps wake on the next request	Boots a full VM; a stopped sandbox is started by API
Docker and nested virtualization	Root access; Docker and nested virtualization not documented	Docker inside the VM; nested virtualization not exposed in the cloud API	Docker, systemd and /dev/kvm for Android emulators and VMs
Inbound access and SSH	HTTPS URL per exposed port, public without authentication; SSH	Up to 16 published ports through a URL or an authenticated connect route; no SSH, terminal capped at one hour per connection	HTTPS URLs for up to 50 ports, token-protected by default; raw TCP; dedicated IPv4 or IPv6; SSH
Outbound rules	Host allowlist per sandbox, enforced by a proxy outside the VM	Blocked, open, or an allowlist of hosts and CIDR ranges	Open internet, no provider-side allowlist
Keeping API keys out of the sandbox	Secrets swapped in on outbound requests to approved hosts; the sandbox only sees a placeholder	Cloud secrets are environment variables the guest can read; swapping exists only in self-hosted smolvm	Credentials proxy for model providers and any HTTPS API; switch a credential to another account when credits run out
Desktop and browser	No desktop; a VS Code editor in the browser	No hosted desktop; a guide shows running your own Chromium inside a machine	Linux desktop streamed at 60fps, Chromium and computer use built in
Coding agents	A root image with Claude Code, run through the shell command API	Registry images with the Codex CLI and the Harbor eval harness, run through the command API	Seven agents preinstalled, with a prompt, steer and events API
Regions	Amsterdam and Chicago	No region choice in the cloud API	EU only (Germany, Finland, France), with EU data residency
Self-hosting	No	Open-source smolvm runs on your laptop or your own servers	No

Every feature Battleships tracks (43)

Feature	Deno Sandbox	smol machines	bochka
Full VM (own kernel)	Yes	Yes	Yes
Docker inside	Not published	Yes	Yes
Nested virtualization	No	No	Yes
Root	Yes	Not published	Yes
Systemd	Not published	Not published	Yes
Desktop GUI	No	No	Yes
Browser	No	No	Yes
Computer-use API	No	No	Yes
SSH	Yes	No	Yes
Persistent disk	Yes	Yes	Yes
Pause/resume	No	Yes	Yes
Automatic snapshots	No	No	Yes
Fork/clone	No	Yes	Yes
Live fork (no pause)	No	Yes	Yes
Memory fork	No	Yes	No
Custom image (Docker or snapshot)	Yes	Yes	Yes
≥24 h sessions	No	Yes	Yes
Idle auto-stop	No	Yes	No
Wake on request	No	Yes	No
HTTPS preview URLs	Yes	Yes	Yes
Raw TCP inbound	No	Not published	Yes
Public IPv4	No	No	No
Egress allowlist	Yes	Yes	No
Secret proxy	Yes	No	Yes
Secret proxy for any API	Yes	No	Yes
Preinstalled agents	Yes	Yes	Yes
Agent harness API	No	No	Yes
MCP server	No	Yes	No
GPU	No	No	No
Windows	No	No	No
Arm64	No	Yes	No
Self-hosting	No	Yes	No
BYOC	No	Yes	No
Open source	No	Yes	No
Scoped API keys	Not published	Not published	Yes
Spend limits	Yes	Yes	Yes
Usage per sandbox (API)	No	Yes	Yes
Audit logs	Not published	Not published	No
SSO	No	Yes	No
SOC 2	Yes	No	No
HIPAA	Yes	No	No
EU data residency	Yes	No	Yes
Zero data retention	Not published	Not published	Yes

Performance

Deno SandboxNot measured

smol machinesNot measured

bochka26.69 runs/s

There is no comparable CPU measurement for Deno Sandbox or smol machines: neither has been run on the StarSling hpc-sandbox-benchmarks test. bochka did 26.69 runs per second on that Node.js build-and-test loop at 4 vCPU / 8 GB. Both Deno and smol publish start times under 200 ms, which measure how fast a machine starts, not how fast it computes.

Node.js build-and-test loop at 4 vCPU / 8 GB, higher is better. Measured with the open hpc-sandbox-benchmarks suite. Deno Sandbox and smol machines 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	Deno Sandbox, a month	smol machines, 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	$53 · Pro · with limits	$25 · Standard	$20 · $20/mo
One agent that never stops 4 vCPU / 8 GB, 50 GB disk, running 24/7 all month	$200 · Builder · with limits	$93 · Standard	$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	$2,779 · Builder · with limits	$1,139 · Pro	$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	$783 · Builder · with limits	$465 · Startup	$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	$1,563 · Builder · with limits	$1,389 · Startup	$2,000 · $2000/mo · with limits

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.

smol machines: smol cloud charges a base fee for every hour a machine runs, plus the CPU and memory the guest actually uses, with a one-minute minimum and disk billed even while stopped. Pro ($20 a month) and Startup ($150 a month) are fees added on top of usage, not credit.

smol machines: 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. smol machines fits all five, but it caps machines by plan, 20 on Standard, 100 on Pro and 1,000 on Startup, with stopped machines still holding a slot, so 50 agents needs Pro and 1,000 short jobs at once needs Startup. bochka fits four of the five; at 1,000 short jobs at once its top plan queues starts above 90 a minute.

Scenario	Deno Sandbox	smol machines	bochka
One coding agent, workdays	Pro: sessions capped at 0.5 h capped at 2 vCPU / 4 GiB largest size is 2 vCPU / 4 GiB disk beyond 10 GiB: price unknown	None that bite	None that bite
One agent that never stops	Builder: sessions capped at 0.5 h capped at 2 vCPU / 4 GiB largest size is 2 vCPU / 4 GiB disk beyond 10 GiB: price unknown	None that bite	None that bite
50 agents in parallel	Builder: max 20 concurrent Builder: sessions capped at 0.5 h capped at 2 vCPU / 4 GiB largest size is 2 vCPU / 4 GiB	None that bite	None that bite
Sandboxes for your users	Builder: max 20 concurrent	None that bite	None that bite
1,000 short jobs at once	Builder: max 20 concurrent	None that bite	max 2,400 starts/day (needs ~6,667) max 600 starts/hour (needs ~1,000) bursts above 90 starts/min are queued (a burst of 333 takes ~4 min to start)

Which one should you use?

Use Deno Sandbox when

you run short pieces of untrusted code that must start in milliseconds, reach only the hosts you allow and never see real keys, or run in the US, especially if you already deploy on Deno Deploy.

Keys the code never sees. For running untrusted code: real secrets are swapped in only on requests to approved hosts, so the sandbox sees a placeholder.
A US region and a path to Deno Deploy. Fits teams on Deno Deploy: sandboxes run in Chicago or Amsterdam and can be promoted to Deploy apps.
Starts in under 200 ms. Good for one sandbox per request: Deno says a sandbox starts in under 200 ms, and CPU bills only while code runs.

Use smol machines when

you need bigger VMs that run as long as you like, want to branch a running machine with its memory, or want one open-source VM engine from your laptop to your own servers.

Bigger machines with no lifetime cap. For work that runs for hours: machines go up to 32 vCPU / 32 GB, with no provider cap on how long they run.
Live branches with memory. Useful for RL and test fan-out: branch a running machine with its memory and processes, and wake stopped machines on the next command.
Open source, from laptop to your own servers. Teams that want the same VM locally, in a hosted cloud and on their own servers can use one open-source engine.

Where bochka fits

If your agents do real work for hours, with builds, Docker, emulators and a browser, look at bochka as well. It gives each agent a full VM whose disk is still there tomorrow, with a desktop, coding agents and a credentials proxy built in, which neither Deno Sandbox nor smol cloud offers together.

A machine that stays, with every file

A Deno sandbox ends after 30 minutes and wipes its root disk, so long tasks must be split and the setup rebuilt. smol machines keeps files across a stop but bills the disk while stopped and empties /tmp.

Docker, /dev/kvm and SSH

Deno does not document Docker or nested virtualization, and smol cloud runs Docker but exposes no /dev/kvm and no SSH. An agent that needs an Android emulator or a VM inside its sandbox cannot start one on either.

Agents, desktop and keys built in

Neither has a hosted desktop, so a computer-use agent needs a desktop stack you build yourself. You run agents through shell or exec calls on both, and on smol cloud the guest can read your secrets.

Use bochka when your agents do real work for hours: Docker, emulators, SSH, a desktop and a browser, with coding agents you drive from outside, keys that never enter the sandbox, and a disk that is still there tomorrow. Compare it one to one: bochka vs Deno Sandbox and bochka vs smol machines.

Questions people ask

Is Deno Sandbox cheaper than smol machines?

Not in the scenarios on this page: smol machines comes out lower in all five and fits all of them, while Deno Sandbox fits none as written. For one agent that never stops, smol machines comes to $93 a month against $200 on Deno Builder, which still cannot keep one sandbox up that long.

Which is faster, Deno Sandbox or smol machines?

Neither has a comparable CPU measurement, so there is no fair speed ratio. Both publish start times under 200 ms. smol machines offers bigger machines, up to 32 vCPU on Startup, while Deno is fixed at 2 vCPU.

Can Deno Sandbox run Docker?

Deno's docs do not say Docker works inside a sandbox, and they do not mention nested virtualization. smol machines runs Docker inside the VM, with Docker data on the machine's ext4 disk. bochka runs Docker and systemd and also exposes /dev/kvm for Android emulators and VMs.

How long can each one run?

A Deno sandbox's lifetime is bound to a session of up to 30 minutes, and longer work can be promoted to a Deno Deploy app. smol machines has no provider cap; you can set an optional lifetime yourself. A bochka sandbox has no cap on paid plans.

Do they keep API keys out of the sandbox?

Deno does: it swaps placeholder secrets for real ones on requests to approved hosts. smol cloud does not today, since its secrets are environment variables the guest can read; swapping exists only in self-hosted smolvm. bochka's credentials proxy keeps real keys outside the sandbox for model providers and any HTTPS API.

Is smol machines open source?

The engine, smolvm, and the smol SDK are open source and run on your own computer or servers. smol cloud, the hosted service, is paid. Deno Sandbox and bochka are hosted services only.

Try bochka

Install the CLI, then run bochka new.

Product preview