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
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.
- 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 | boat: 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 boat 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; boat 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 boat 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 boat 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; boat 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 | boat |
|---|---|---|---|
| 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 | boat |
|---|---|---|---|
| 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
There is no comparable CPU measurement for Deno Sandbox or smol machines: neither has been run on the StarSling hpc-sandbox-benchmarks test. boat 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 | boat, 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. boat 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 | boat |
|---|---|---|---|
| One coding agent, workdays |
| None that bite | None that bite |
| One agent that never stops |
| None that bite | None that bite |
| 50 agents in parallel |
| None that bite | None that bite |
| Sandboxes for your users |
| None that bite | None that bite |
| 1,000 short jobs at once |
| None that bite |
|
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 boat fits
If your agents do real work for hours, with builds, Docker, emulators and a browser, look at boat 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 boat 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: boat vs Deno Sandbox and boat 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. boat 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 boat 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. boat'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 boat are hosted services only.
Try boat
Install the CLI, then run boat new.
7-day free trial