Daytona vs smol machines
Daytona starts each sandbox as a container and sells Linux VM, Windows and GPU classes on top. smol machines gives every machine its own microVM kernel from an open-source engine you can also run on your laptop or your own servers.
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
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. “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 | smol machines: price rank | bochka: price rank |
|---|---|---|---|
| Software factory 100 at once · 4 vCPU / 8 GB · 2,200 sessions of 8 h a month Both run Docker; Daytona's Linux VM class adds /dev/kvm once KVM is turned on for your organization, smol cloud exposes no nested virtualization, and bochka has /dev/kvm, Docker and coding agents on every machine. | 15th cheapest of 367 $4,111 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 | 24th cheapest of 366 $6,104 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: smol machines bills a one-minute minimum and wakes stopped machines on the next command, while Daytona creates hundreds of sandboxes a minute with no plan fee. | 25th cheapest of 345 $271 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 300 sandboxes of 2 vCPU need 600 vCPU, more than Daytona's Tier 4 pool of 500, while smol machines fits on Startup and bochka fits with a desktop and hosting per user. | 154th of 361, with limits $2,000 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 branches a running machine with its memory and processes, and Daytona's VM class forks with memory too, so both can fan rollouts out from one prepared state. | 130th of 360, with limits $8,261 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 | 189th of 364, with limits $2,000 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 Daytona caps a sandbox at 4 vCPU by default and smol cloud has no nested virtualization, while bochka gives 8 vCPU and /dev/kvm from the $20 plan. | 308th of 377, with limits $805 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 | 183rd of 368, with limits $245 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 Daytona has a VNC desktop and a computer-use API on Linux and Windows, smol cloud has no hosted desktop, and bochka streams a 60fps desktop you can embed. | 26th cheapest of 369 $1,198 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 smol machines documents running your own Chromium inside a machine, Daytona has a desktop with a browser, and bochka ships Chromium ready for agents. | 93rd of 367, with limits $598 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 | 38th cheapest of 346 $404 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 | 202nd of 338, with limits $8,073 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 | 12th cheapest of 360 $2,000 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 Only Daytona fits: it rents Nvidia and AMD GPUs by the hour, while smol cloud and bochka have no 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 | smol machines | bochka |
|---|---|---|---|
| Isolation | Container by default; Linux VM and Windows VM classes have their own kernel | libkrun microVM with its own guest kernel for every machine | Full VM with its own kernel for every sandbox, 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 |
| Biggest machine | 4 vCPU / 8 GiB per sandbox by default, raisable per region | Up to 32 vCPU / 32 GB on Startup, 16 vCPU / 24 GB on Pro | Up to 16 vCPU / 32 GB on the $100 plan and above |
| Docker and nested virtualization | Docker in all classes; /dev/kvm only on Linux VMs, once KVM is turned on for your organization | Docker inside the VM; no nested virtualization on hosted machines | Docker, root, systemd and /dev/kvm on every machine |
| Fork and pause | Linux VM and Windows classes pause and fork with memory kept; containers do not | Branch a running machine with its memory and processes; checkpoints capture RAM to a file | Fork a running sandbox with its disk; resume reboots from disk |
| Files after a stop | Disk is kept and billed while stopped; archived containers are free | Filesystem survives a stop; stopped disk keeps billing | Disk saved every minute and on stop; a stopped sandbox costs nothing |
| Wake on request | No; a stopped sandbox is started by API | A command or terminal starts a stopped machine; idle apps wake on the next request | No; a stopped sandbox is started by API |
| Shell access | SSH and process exec | Command API and a WebSocket terminal capped at one hour per connection; no SSH | SSH, plus a command API and terminal |
| Inbound access | HTTPS preview URLs on any port, token-protected or public; no raw TCP or public IP | Up to 16 published ports through a returned URL or an authenticated connect route; no dedicated 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 allowlists | Blocked, open, or an allowlist of hosts and CIDR ranges on every plan | Open internet on every plan; no provider-side allowlist |
| Desktop and computer use | VNC desktop and a computer-use API on Linux and Windows | No hosted desktop; a guide shows running your own Chromium inside a machine | 60fps Linux desktop with Chromium, computer use and browser control, embeddable stream |
| Keeping keys out of the sandbox | Secrets proxy swaps placeholders in HTTPS request headers for allowed hosts | Cloud secrets are environment variables the guest can read | Credentials proxy for model providers and any HTTPS API; switch a credential to another account when credits run out |
| Coding agents | Guides install agents and run them through process exec | Registry images with the Codex CLI and the Harbor eval harness, run through the command API | Claude Code, Codex, OpenCode and more preinstalled, with a prompt, steer and events API |
| GPUs, Windows and where it runs | Nvidia and AMD GPUs, Windows VMs; US and EU regions, plus your own machines | Linux only, no GPUs in the cloud; no region choice; open-source engine runs on your own servers | Linux only, no GPUs; EU only (Germany, Finland, France) with EU data residency |
Every feature Battleships tracks (43)
| Feature | Daytona | smol machines | bochka |
|---|---|---|---|
| Full VM (own kernel) | No | Yes | Yes |
| Docker inside | Yes | Yes | Yes |
| Nested virtualization | Yes | No | Yes |
| Root | Yes | Not published | Yes |
| Systemd | Not published | Not published | 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 | No | 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 | 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 | Yes | Yes | No |
| GPU | Yes | No | No |
| Windows | Yes | No | No |
| Arm64 | No | Yes | No |
| Self-hosting | No | Yes | No |
| BYOC | Yes | Yes | No |
| Open source | No | Yes | No |
| Scoped API keys | Yes | Not published | Yes |
| Spend limits | Not published | Yes | Yes |
| Usage per sandbox (API) | Yes | Yes | Yes |
| Audit logs | Yes | Not published | No |
| SSO | Yes | 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
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. smol cloud has not been run on that test, so there is no comparable CPU number 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). smol machines 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 | 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 | $56 · Tier 3 ($500 top-up) | $25 · Standard | $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) | $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,682 · Tier 3 ($500 top-up) | $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 | $2,000 · Tier 4 ($2,000 top-up every 30 days) · 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 | $2,000 · Tier 4 ($2,000 top-up every 30 days) · with limits | $1,389 · Startup | $2,000 · $2000/mo · with limits |
Daytona: Daytona bills per second for the vCPU, memory and disk you reserve, and keeps billing the disk while a sandbox is stopped. You pay from a prepaid wallet: open internet needs a $500 top-up (Tier 3), and the biggest pool needs $2,000 every 30 days (Tier 4).
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 while stopped. Pro ($20 a month) and Startup ($150 a month) are fees on top of usage, not credit.
smol machines: Plans start at $20 a month, and the whole fee is usage credit spent per second while a sandbox runs. A stopped sandbox costs nothing and keeps its disk.
Limits in those scenarios
Daytona limits the total vCPU running at once, 10 to 500 vCPU from Tier 1 to Tier 4, so 300 sandboxes for your users and 1,000 short jobs at once do not fit even Tier 4. smol machines limits machines held, counting stopped ones: 20 on Standard, 100 on Pro and 1,000 on Startup, so the 1,000-job burst fits on Startup. bochka fits every scenario but the burst, where its plans queue starts above 90 a minute.
| Scenario | Daytona | smol machines | bochka |
|---|---|---|---|
| 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 Daytona when
your agents need GPUs or Windows, or must run in the US or on your own machines.
- GPUs and Windows. Useful if your agents test models or need a Windows desktop: Daytona rents Nvidia and AMD GPUs and runs Windows VMs.
- US region and your own machines. Teams that must run in the US, or on machines they bring, can do both with Daytona.
- SSH and a computer-use API. Tools that expect SSH work as they are, and a VNC desktop with a computer-use API is ready on Linux and Windows.
Use smol machines when
you want one open-source VM engine from your laptop to your own servers, or you fan out many live branches of a running machine.
- Open source, laptop to servers. Teams that want the same VM on a laptop, in a hosted cloud and on their own servers get it from one open-source engine.
- Live branches that wake on demand. Useful for RL and test fan-out: branch a running machine with its memory, and stopped machines start on the next command.
- A VM kernel and allowlists on every plan. Every machine is a microVM with its own kernel, and outbound traffic can be blocked or limited to chosen hosts from the free plan.
Where bochka fits
If your agents do long, real work, like installs, builds, tests, Docker and emulators, bochka gives each one a full, measured-faster VM with a desktop and coding agents built in. Daytona makes you pick its VM class to leave the shared kernel, and smol cloud leaves out nested virtualization, SSH and a desktop. Choose Daytona or smol machines instead for GPUs, Windows, the US, or self-hosting.
A whole machine by default
Daytona's default container shares the host kernel, and its VM class needs KVM turned on for your organization before /dev/kvm works. smol cloud has its own kernel but no nested virtualization or SSH. bochka has /dev/kvm, Docker, systemd and SSH everywhere.
A faster CPU, measured
In the same 4 vCPU / 8 GB benchmark, bochka did 26.69 runs per second and Daytona's VM class did 21.52, so each build takes about a quarter longer there. smol cloud has no measured number at all.
Agents, desktop and keys built in
On both, you install and drive coding agents through exec calls yourself. smol cloud has no hosted desktop and puts secrets in readable environment variables. bochka ships agents with a steer API, a 60fps desktop and a credentials proxy for any HTTPS API.
Use bochka when your agents need a whole, faster machine for hours of real work: Docker, emulators, SSH, a desktop and a browser, with coding agents you drive from outside and keys that never enter the sandbox. Compare it one to one: bochka vs Daytona and bochka vs smol machines.
Questions people ask
Is Daytona cheaper than smol machines?
Not in the scenarios we priced. One coding agent on workdays comes to $56 a month on Daytona and $25 on smol machines, and 50 agents in parallel come to $2,682 against $1,139. On bochka those are $20 and $317.
Which is faster, Daytona or smol machines?
Only Daytona has a public CPU number: its Linux VM class did 21.52 runs per second in StarSling's 4 vCPU / 8 GB test. smol cloud has not been measured on that test. bochka did 26.69 in the same run.
Are Daytona and smol machines sandboxes VMs or containers?
Every smol machine is a libkrun microVM with its own guest kernel. Daytona's default sandbox is a container, and its Linux VM and Windows VM classes have their own kernel. On bochka every sandbox is a full VM.
Can I run Docker and Android emulators in each?
Both run Docker. For emulators you need /dev/kvm: Daytona offers it only on its Linux VM class with KVM turned on for your organization, and smol cloud does not expose nested virtualization. bochka has /dev/kvm on every machine.
Can I self-host Daytona or smol machines?
smol machines' engine, smolvm, is open source and runs on your laptop or your own servers. Daytona can manage sandboxes on machines you bring through custom regions, but its public repository stopped receiving updates in June 2026. bochka is a hosted service only.
Do they keep API keys out of the sandbox?
Daytona's secrets proxy swaps placeholders in HTTPS headers for allowed hosts. On smol cloud, secrets are environment variables the guest can read. bochka's credentials proxy keeps real keys outside the sandbox for model providers and any HTTPS API.
Try bochka
Install the CLI, then run bochka new.
Product preview