Deno Sandbox vs Azure Container Apps Sandboxes
Both run code in a microVM with its own kernel. Deno Sandbox is built for short runs that start in under 200 ms and end within 30 minutes, while Azure keeps a sandbox for as long as you want, suspends it with its memory when idle and lives inside your Azure account.
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
Azure Container Apps Sandboxes
Azure Container Apps Sandboxes is a service inside Microsoft Azure that gives each agent or user an isolated microVM you create, suspend and resume through an SDK.
It is part of Azure Container Apps, the hyperscaler's serverless container platform, and lives in your Azure subscription as a sandbox group resource. Each sandbox boots from an OCI image or a snapshot, has its own kernel, and can be suspended with its memory and resumed in under a second. It is built for teams already on Azure that want stateful code execution with Azure networking, identity and billing.
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 | Azure Container Apps Sandboxes: 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, Docker builds and browsers for hours, which outlasts Deno's lifetime and needs SSH, /dev/kvm and a desktop that neither Deno nor Azure offers. | 290th of 367, with limits $5,665 a month | 288th of 367, with limits $5,276 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 | 302nd of 366, with limits $6,544 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: Deno starts in under 200 ms and bills CPU only while code runs, and Azure suspends with memory and resumes in under a second, so it fits fully where Deno is a compromise. | 141st of 345, with limits $329 a month | 34th cheapest of 345 $354 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 allows 20 sandboxes at once per region, while Azure starts at 500 active cores, so Azure fits a few hundred users at once and Deno does not; bochka fits too, with hosting on up to 50 ports. | 148th of 361, with limits $1,863 a month | 22nd cheapest of 361 $2,260 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 | 122nd of 360, with limits $7,963 a month | 153rd of 360, with limits $10,740 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 Eval runs often outlast 30 minutes or need more than 2 vCPU, which rules Deno out as written, while Azure's larger tiers and lack of a session cap fit. | 296th of 364, with limits $1,563 a month | 75th cheapest of 364 $1,728 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 CI jobs that build Docker images fit Azure with the azure-dev image, but not Deno, which does not document Docker; neither documents the /dev/kvm that bochka exposes for Android emulators. | 304th of 377, with limits $731 a month | 103rd cheapest of 377 $1,046 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 cannot run on Deno's 30-minute lifetime, and on Azure it bills every running second with no SSH; bochka keeps its disk and has SSH. | 179th of 368, with limits $200 a month | 322nd of 368, with limits $262 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 Computer-use agents need a screen, and both Deno and Azure are headless; bochka streams a Linux desktop at 60fps with Chromium. | 280th of 369, with limits $1,583 a month | 279th of 369, with limits $1,573 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 On Deno and Azure you install and run a headless browser yourself, while bochka ships Chromium on a desktop in every sandbox. | 284th of 367, with limits $783 a month | 288th of 367, with limits $795 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 | 284th of 346, with limits $561 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 | 239th of 338, with limits $10,956 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 | 278th of 360, with limits $517 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 | Azure Container Apps Sandboxes | bochka |
|---|---|---|---|
| Isolation | Firecracker microVM with its own kernel | MicroVM per sandbox with its own 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 | Tiers from 0.25 cores / 0.5 GB to 4 cores / 8 GB; up to 16 vCPU / 32 GB by API | 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 cap; auto-suspends after an idle timeout, 5 minutes by default | No cap on paid plans; you set the time to live |
| Keeping state | Root disk wiped when the sandbox ends; opt-in volumes of 300 MB to 20 GB, Chicago only | Suspend with memory and disk; resume in under a second with processes running | Whole disk saved every minute and on stop; a stopped sandbox costs nothing, and resume boots the machine again |
| Snapshots and fork | Read-only volume snapshots that new sandboxes can boot from; no fork of a running sandbox | Snapshot a running sandbox with its memory and create new sandboxes from it | Automatic disk snapshots; fork a running sandbox with its disk |
| Docker and nested virtualization | Root access; Docker and nested virtualization not documented | Docker in the azure-dev image; the default ubuntu image has only Buildah; nested virtualization not documented | Docker, systemd and /dev/kvm on every sandbox for Android emulators and VMs |
| Getting a shell | SSH, plus a VS Code editor in the browser | Interactive shell through the aca CLI, SDK or portal; no SSH | SSH, plus CLI and API exec |
| Desktop and browser | No desktop or managed browser | Headless; no desktop or managed browser | Linux desktop streamed at 60fps, Chromium and computer use built in |
| Inbound access | HTTPS URL per exposed port, public without authentication | Public HTTPS routes per published port; private endpoint from your VNet at extra cost | HTTPS URLs for up to 50 ports, token-protected by default; raw TCP; dedicated IPv4 or IPv6 |
| Outbound rules | Host allowlist per sandbox, enforced by a proxy outside the VM | Egress policy with allow, deny, rewrite and header rules by host, path and method; VNet integration | 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 | Group secrets usable in egress header rules; Copilot and Anthropic tokens are injected into the sandbox at startup | Credentials proxy for model providers and any HTTPS API; switch a credential to another account when credits run out |
| Coding agents | A root image with Claude Code, run through the shell command API | Copilot CLI and Claude Code images, run through the exec API | Seven agents preinstalled, with a prompt, steer and events API |
| Sandboxes at once | 3 per region on Pro, 20 per region on Builder | 500 concurrent active cores by default; more by Azure support request | Concurrency set by plan, up to 2,000 sandboxes, self-serve |
| Start time | Under 200 ms | Resume from suspend in under a second | Boots a full VM |
| Regions | Amsterdam and Chicago | 40 Azure regions, 9 of them in the EU | EU only (Germany, Finland, France) |
Every feature Battleships tracks (43)
| Feature | Deno Sandbox | Azure Container Apps Sandboxes | bochka |
|---|---|---|---|
| Full VM (own kernel) | Yes | Yes | Yes |
| Docker inside | Not published | Yes | Yes |
| Nested virtualization | No | No | Yes |
| Root | Yes | Yes | Yes |
| Systemd | Not published | Yes | 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 | Yes | 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 | 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 | No | No | Yes |
| MCP server | No | No | No |
| GPU | No | No | No |
| Windows | No | No | No |
| Arm64 | No | No | No |
| Self-hosting | No | No | No |
| BYOC | No | No | No |
| Open source | No | No | 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 | Yes | No |
| SSO | No | Yes | No |
| SOC 2 | Yes | Yes | No |
| HIPAA | Yes | Yes | No |
| EU data residency | Yes | Yes | Yes |
| Zero data retention | Not published | Not published | Yes |
Performance
There is no comparable measurement for Deno Sandbox or Azure Container Apps Sandboxes, so this page makes no speed claim between them. bochka did 26.69 runs per second on the StarSling hpc-sandbox-benchmarks Node.js build-and-test loop at 4 vCPU / 8 GB. Deno's fixed 2 vCPU shape could not run that 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 and Azure Container Apps Sandboxes 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 | Azure Container Apps Sandboxes, 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 | $68 · Pay-as-you-go | $20 · $20/mo |
| One agent that never stops 4 vCPU / 8 GB, 50 GB disk, running 24/7 all month | $200 · Builder · with limits | $262 · Pay-as-you-go · 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 | $2,779 · Builder · with limits | $3,421 · Pay-as-you-go | $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 | $989 · Pay-as-you-go | $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 | $2,148 · Pay-as-you-go | $2,000 · $2000/mo · with limits |
Deno Sandbox: Sandboxes need the Pro plan at $20 a month or Builder at $200 a month, which include 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 whole life of the sandbox.
Azure Container Apps Sandboxes: There is no plan fee: Azure bills per second on the Container Apps Consumption meters for the vCPU and memory of the sandbox's tier while it runs, idle time before auto-suspend included. Some regions such as West Europe and UK South charge more per second.
Azure Container Apps Sandboxes: 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. Azure fits four of the five; the always-on agent bills every second all month and only gets close with a 3-year commitment, and a fleet past 500 active cores needs a support request. bochka fits four of the five; at 1,000 short jobs at once its top plan queues starts above 90 a minute, while Azure fits that burst.
| Scenario | Deno Sandbox | Azure Container Apps Sandboxes | bochka |
|---|---|---|---|
| One coding agent, workdays |
| None that bite | None that bite |
| One agent that never stops |
|
| 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 finish within 30 minutes, especially if you already deploy on Deno Deploy.
- Fast starts, CPU billed while code runs. Good for short bursts of code: a sandbox starts in under 200 ms and CPU bills only while code is running.
- SSH and a browser editor. Fits people who want to step into a sandbox: it takes SSH and opens a VS Code editor in the browser.
- A path to Deno Deploy. Fits teams on Deno Deploy: a sandbox can be promoted to a Deploy app and bills on the same meters.
Use Azure Container Apps Sandboxes when
your team already runs on Azure and wants stateful sandboxes with no session cap that suspend with their memory, wake on traffic and sit behind strict egress rules.
- No session cap, memory suspend. Good for stateful jobs that sleep between requests: a sandbox suspends with its memory and resumes in under a second.
- Bigger machines and fleets. Fits heavier work: tiers go to 4 cores / 8 GB, 16 vCPU by API, with 500 active cores by default.
- Inside Azure, in 40 regions. Teams already on Azure get Entra ID, Azure billing, VNets and fine egress rules, in 40 regions.
Where bochka fits
Deno Sandbox and Azure Container Apps Sandboxes both run code in a headless microVM that you drive through an SDK. If your agents do real work for hours, with Docker, emulators, a browser and a desktop, bochka gives each one a whole computer with its own kernel, SSH and coding agents built in.
A whole computer with /dev/kvm
Neither Deno nor Azure documents nested virtualization, so an Android emulator or a VM cannot start. Deno also does not document Docker, and on Azure you must pick the azure-dev image to get it. bochka has Docker, systemd and /dev/kvm everywhere.
A screen and a browser
Both Deno and Azure are headless, so a computer-use or browser agent needs you to build a browser, a virtual display and a streaming stack into your own image. bochka streams a Linux desktop at 60fps with Chromium.
Agents and keys run from outside
On Deno you run Claude Code through shell commands, and on Azure through raw exec with tokens injected into the sandbox. bochka's agents take a prompt, steer and events API, and real keys stay in a credentials proxy outside.
Use bochka when your agents need a whole computer for hours: SSH, Docker, emulators, a desktop and a browser, with coding agents and a credentials proxy built in and a disk that is still there tomorrow. Compare it one to one: bochka vs Deno Sandbox and bochka vs Azure Container Apps Sandboxes.
Questions people ask
Is Deno Sandbox cheaper than Azure Container Apps Sandboxes?
On paper Deno comes out lower in every scenario on this page, for example $53 against $68 a month for one coding agent on workdays. But Deno fits none of them as written, because of its 30-minute lifetime, 2 vCPU shape and 20-at-once limit, while Azure fits four of the five.
Which is faster, Deno Sandbox or Azure Container Apps Sandboxes?
Neither has a comparable CPU measurement, so there is no fair speed answer. Deno says a sandbox starts in under 200 ms, and Azure resumes a suspended sandbox in under a second with its processes running.
Can Deno Sandbox or Azure run Docker?
Deno's docs do not say Docker works inside a sandbox. On Azure, the azure-dev image ships Docker on systemd, and the default ubuntu image has only Buildah. bochka runs Docker on every sandbox and also exposes /dev/kvm, which neither documents.
How long can a sandbox run on each?
A Deno sandbox lives up to 30 minutes, and longer work has to be split or promoted to a Deno Deploy app. Azure has no session cap; a sandbox runs until you stop it or it auto-suspends after an idle timeout, 5 minutes by default.
Can I SSH into Deno Sandbox or Azure Container Apps Sandboxes?
Deno Sandbox supports SSH. Azure does not; it gives you a shell through the aca CLI, the SDK or the portal. Every bochka sandbox has an SSH endpoint.
Do I need an Azure account to use Azure Container Apps Sandboxes?
Yes. It needs an Azure subscription, a Microsoft Entra ID account and the Container Apps SandboxGroup Data Owner role. Deno Sandbox needs a Deno Deploy organization on the Pro or Builder plan.
Try bochka
Install the CLI, then run bochka new.
Product preview
More comparisons
- bochka vs Deno Sandbox
- bochka vs Azure Container Apps Sandboxes
- E2B vs Deno Sandbox
- Daytona vs Deno Sandbox
- Modal vs Deno Sandbox
- Vercel Sandbox vs Deno Sandbox
- Cloudflare Sandbox vs Deno Sandbox
- Blaxel vs Deno Sandbox
- Runloop vs Deno Sandbox
- Tensorlake vs Deno Sandbox
- Morph Cloud vs Deno Sandbox
- CodeSandbox SDK vs Deno Sandbox