Daytona vs Azure Container Apps Sandboxes
Daytona is a standalone sandbox cloud with containers by default, plus Linux VM, Windows and GPU classes, SSH and a desktop. Azure Container Apps Sandboxes gives every sandbox its own microVM inside your Azure account, headless, that suspends with its memory and wakes on traffic.
The companies and products
Daytona
Daytona is a cloud for running AI-generated code: you create sandboxes from code through its API and SDKs.
By default a Daytona sandbox is a Linux container with its own namespaces and reserved vCPU, memory and disk. You can also pick a Linux VM class (pause, fork, memory snapshots, /dev/kvm), a Windows VM class, or a GPU class with Nvidia and AMD cards. It is built for teams that run agent code, code interpreters and evals through Python, TypeScript, Ruby, Go or Java SDKs.
- Founded
- 2023
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. “15th cheapest of 367” means 14 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 | Daytona: 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 Daytona fits a software factory in full with SSH, Docker and a VM class with /dev/kvm, while Azure is a compromise: no SSH, no desktop and no documented nested virtualization; bochka has all of these on every machine. | 15th cheapest of 367 $4,111 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 | 24th cheapest of 366 $6,104 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 fit short code runs: Daytona creates hundreds of sandboxes a minute, and Azure suspends with memory and resumes in under a second. | 25th cheapest of 345 $271 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 Azure fits 300 user sandboxes at once, while 600 vCPU is more than Daytona's Tier 4 pool of 500 vCPU, so Daytona needs a custom limit. | 154th of 361, with limits $2,000 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 | 130th of 360, with limits $8,261 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 Azure fits eval runs in full, while Daytona's vCPU pool makes it a compromise; bochka fits too and also has a desktop for agents that need a screen. | 189th of 364, with limits $2,000 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 Azure fits CI runners, while Daytona caps a sandbox at 4 vCPU by default; builds that need Android emulators or VM images need /dev/kvm, which bochka has and Azure does not document. | 308th of 377, with limits $805 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 | 183rd of 368, with limits $245 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 Daytona has a VNC desktop and a computer-use API on Linux and Windows, Azure's sandboxes are headless, and bochka streams a Linux desktop at 60fps. | 26th cheapest of 369 $1,198 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 | 93rd of 367, with limits $598 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 | 38th cheapest of 346 $404 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 | 202nd of 338, with limits $8,073 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 Daytona fits parallel red teaming in full, while Azure is a compromise; bochka fits too, with a full VM per attacker. | 12th cheapest of 360 $2,000 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 Only Daytona fits GPU jobs: it rents Nvidia and AMD GPUs by the hour, and neither Azure's sandboxes nor bochka have GPUs. | 20th cheapest of 98 $1,190 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 | Daytona | Azure Container Apps Sandboxes | bochka |
|---|---|---|---|
| Isolation | Container by default; Linux VM and Windows VM classes with their own kernel | MicroVM per sandbox with its own kernel | Every sandbox is a full VM with its own kernel, on dedicated AMD Ryzen 9 9950X hosts |
| CPU speed (Node.js build-and-test, 4 vCPU / 8 GB) | 21.52 runs/s on the Linux VM class; the default container class reported no result | Not measured | 26.69 runs/s |
| Nested virtualization | /dev/kvm on the Linux VM class, once KVM is turned on for your organization | Not documented | /dev/kvm on every machine, for Android emulators and VMs |
| Docker and systemd | Docker in all classes | Depends on the image: azure-dev ships Docker on systemd; the default ubuntu image has only Buildah | Docker, systemd and root on every sandbox |
| Getting a shell | SSH, plus SDK process exec | Interactive shell through the aca CLI, SDK or portal; no SSH | SSH, plus CLI and API exec |
| Desktop and computer use | VNC desktop (xfce4) and a computer-use API on Linux and Windows | Headless; no desktop or managed browser | Linux desktop streamed at 60fps, Chromium and computer-use tools preinstalled |
| Suspend and resume | Linux VM and Windows classes pause and resume with memory; containers stop and keep their disk | Suspend with memory and disk; resume in under a second with processes running; wakes on network traffic | Disk saved every minute and on stop; resume boots the machine again; a stopped sandbox costs nothing |
| Fork | Fork with memory on the VM classes; no fork for containers | Snapshot a running sandbox with its memory and start new sandboxes from it | Fork a running sandbox with its disk |
| Inbound access | HTTPS preview URLs on any port, token-protected or public; no raw TCP or public IP | Public HTTPS routes per published port; private endpoint from your VNet; no public IP | HTTPS URLs for up to 50 ports, token-protected; raw TCP; dedicated IPv4 or IPv6 |
| Outbound internet | Tier 1 and 2 reach only package registries, git hosts and AI APIs; Tier 3 and up get open internet plus domain or CIDR allowlists | Open internet, with egress rules that allow, deny or rewrite requests by host, path and method; VNet integration | Open internet on every plan; no provider-side allowlist |
| Coding agents | Guides install agents and run them through process exec | Copilot CLI and Claude Code images, run through the exec API | Claude Code, Codex, OpenCode and more preinstalled, with a prompt, steer and events API |
| Keeping keys out of the sandbox | Secrets proxy swaps placeholders in HTTPS request headers for allowed hosts | Group secrets usable in egress header rules; Copilot and Anthropic tokens are injected into the sandbox at startup | AI credentials proxy for model providers and any HTTPS API; switch a credential to another account when credits run out |
| GPUs and Windows | Nvidia and AMD GPUs by the hour; Windows VM sandboxes | No GPUs, no Windows | No GPUs; no Windows guests, Wine for Windows apps |
| Regions | US and EU, plus dedicated regions or your own machines | 40 Azure regions, 9 of them in the EU | EU only: Germany, Finland, France |
Every feature Battleships tracks (43)
| Feature | Daytona | Azure Container Apps Sandboxes | bochka |
|---|---|---|---|
| Full VM (own kernel) | No | Yes | Yes |
| Docker inside | Yes | Yes | Yes |
| Nested virtualization | Yes | No | Yes |
| Root | Yes | Yes | Yes |
| Systemd | Not published | Yes | Yes |
| Desktop GUI | Yes | No | Yes |
| Browser | Yes | No | Yes |
| Computer-use API | Yes | No | Yes |
| SSH | Yes | No | Yes |
| Persistent disk | Yes | Yes | Yes |
| Pause/resume | Yes | Yes | Yes |
| Automatic snapshots | Yes | Yes | Yes |
| Fork/clone | Yes | Yes | Yes |
| Live fork (no pause) | No | Yes | Yes |
| Memory fork | Yes | Yes | No |
| Custom image (Docker or snapshot) | Yes | Yes | Yes |
| ≥24 h sessions | Yes | Yes | Yes |
| Idle auto-stop | Yes | 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 | Yes | No | No |
| GPU | Yes | No | No |
| Windows | Yes | No | No |
| Arm64 | No | 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) | Yes | Yes | Yes |
| Audit logs | Yes | Yes | No |
| SSO | Yes | 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
In StarSling's public run of 2026-09-29 at 4 vCPU / 8 GB, bochka did 26.69 Node.js build-and-test runs per second and Daytona's Linux VM class did 21.52. Daytona's default container class reported no result in that run. Azure Container Apps Sandboxes has no comparable measurement, so this page makes no speed claim for it.
Node.js build-and-test loop at 4 vCPU / 8 GB, higher is better. Measured with the open hpc-sandbox-benchmarks suite. Daytona measured on: Linux VM sandbox (same rates; KVM / nested virt per-org feature). Azure Container Apps Sandboxes 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 | Daytona, 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 | $56 · Tier 3 ($500 top-up) | $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 | $245 · Tier 3 ($500 top-up) | $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,682 · Tier 3 ($500 top-up) | $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 | $2,000 · Tier 4 ($2,000 top-up every 30 days) · 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 | $2,000 · Tier 4 ($2,000 top-up every 30 days) · with limits | $2,148 · Pay-as-you-go | $2,000 · $2000/mo · with limits |
Daytona: Daytona bills per second for reserved vCPU, memory and disk from a prepaid wallet, and keeps billing the disk while a sandbox is stopped. Open internet needs a $500 top-up (Tier 3), and the biggest pool needs $2,000 every 30 days (Tier 4).
Azure Container Apps Sandboxes: Azure bills per second on the Container Apps Consumption meters for the vCPU and memory of the sandbox's size while it runs, idle time before auto-suspend included (5 minutes by default). There is no plan fee, and some regions such as West Europe charge more.
Azure Container Apps Sandboxes: bochka plans start at $20 a month, and the whole fee is usage credit spent per second on running sandboxes. A stopped sandbox costs nothing and keeps its disk.
Limits in those scenarios
Daytona limits the vCPU running at once per organization, 500 vCPU at Tier 4, so 300 user sandboxes (600 vCPU) and 1,000 short jobs at once do not fit without a custom limit, and it caps one sandbox at 4 vCPU / 8 GB by default. Azure starts with 500 concurrent active cores and raises that by support request, and it fits the 1,000-job burst. Azure bills an always-on sandbox for every second, so that scenario only fits with a 3-year commitment. bochka's start limits queue the 1,000-job burst on the $2,000 plan.
| Scenario | Daytona | 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 Daytona when
your agents need GPUs, Windows, SSH or a desktop, or when you want a sandbox cloud outside Azure that can also run on your own machines.
- GPUs and Windows. Useful if your agents test models or need Windows: Daytona rents Nvidia and AMD GPUs by the hour and runs Windows VM sandboxes.
- SSH and a desktop. Useful if people or tools need to get into the sandbox: Daytona has SSH and a VNC desktop with a computer-use API.
- No cloud account to set up. Useful if you are not on Azure: Daytona is its own service with a prepaid wallet, and can also run on your own machines.
Use Azure Container Apps Sandboxes when
your team already runs on Azure and wants headless sandboxes that suspend with their memory, wake on traffic and sit behind strict egress rules.
- Memory suspend and wake on traffic. Good for stateful jobs that sleep between requests: a sandbox suspends with its memory and resumes in under a second.
- Fine-grained outbound rules from day one. Every sandbox can get egress rules by host, path and method, with no top-up needed to reach the open internet.
- Inside Azure, in 40 regions. Teams already on Azure get Entra ID, Azure billing and their own VNets, in 40 regions.
Where bochka fits
If your agents do long, real work like installs, builds, Docker, emulators and browsers, look at bochka as well. Every bochka sandbox is a full VM with a desktop, SSH and coding agents built in, with no class to choose and no image to pick for Docker.
A full VM with /dev/kvm on every sandbox
Daytona's default is a container sharing the host kernel, and /dev/kvm needs its VM class plus KVM turned on for your organization. Azure does not document nested virtualization, so an agent there cannot start an Android emulator or a VM.
A screen, SSH and raw TCP for every agent
Azure's sandboxes are headless with no SSH, so a computer-use agent needs your own browser, display and streaming stack. Daytona has a VNC desktop but no raw TCP or public IP; bochka streams 60fps and takes raw TCP on its own IP.
Agents driven from outside, keys kept outside
On both, you run agents through process exec and write the code that prompts and watches them. Azure injects agent tokens into the sandbox at start; bochka keeps real keys in a proxy and can switch a credential when credits run out.
Use bochka when your agents need a whole, faster computer for hours: Docker, /dev/kvm, SSH, a 60fps desktop and coding agents built in, with keys kept outside the sandbox. Compare it one to one: bochka vs Daytona and bochka vs Azure Container Apps Sandboxes.
Questions people ask
Is Daytona cheaper than Azure Container Apps Sandboxes?
In most of our scenarios, yes: one coding agent on workdays comes to $56 on Daytona against $68 on Azure, and 50 agents in parallel come to $2,682 against $3,421. Azure fits 300 user sandboxes for $989 a month and 1,000 short jobs at once, which Daytona does not without a custom limit. bochka comes to $20, $317 and $200 a month in the first three.
Which is faster, Daytona or Azure Container Apps Sandboxes?
Only Daytona has a measured score: its Linux VM class did 21.52 runs per second in StarSling's Node.js test at 4 vCPU / 8 GB, against 26.69 for bochka. Azure has no comparable measurement yet.
Can Daytona and Azure sandboxes run Docker?
Daytona runs Docker in all its classes. On Azure it depends on the image: azure-dev ships Docker on systemd, while the default ubuntu image has only Buildah. bochka runs Docker, systemd and /dev/kvm on every sandbox.
Are they containers or VMs?
Daytona's default is a Linux container, with Linux VM and Windows VM classes that have their own kernel. Every Azure sandbox is a microVM with its own kernel. Every bochka sandbox is a full VM.
Can I SSH into them?
Daytona has SSH. Azure gives an interactive shell through the aca CLI, SDK or portal, but no SSH. Every bochka sandbox has an SSH endpoint.
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