Daytona vs Fly.io Machines
Daytona is built for running AI-generated code: you create sandboxes through its SDKs, as containers by default or as Linux VM, Windows or GPU classes. Fly.io Machines are fast microVMs for hosting your own apps near users in 17 regions, so you build the sandbox parts yourself.
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
Fly.io Machines
Fly.io is an app hosting platform, and Machines are the microVMs underneath it that you can also start and stop through a REST API.
A Fly Machine boots your Docker image as a Firecracker microVM on Fly's own servers, in one of 17 regions. You pick a shared or performance CPU preset, attach at most one Volume for data that must last, and Fly Proxy can stop, suspend and wake Machines as traffic comes and goes. It is built for teams that host web apps and services worldwide; it is not a sandbox product, so this page compares the parts that overlap with agent work.
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 | Fly.io Machines: price rank | bochka: price rank |
|---|---|---|---|
| Software factory 100 at once · 4 vCPU / 8 GB · 2,200 sessions of 8 h a month Daytona ranks 15th and fits fully with Docker and its Linux VM class; Fly is a compromise because the root disk resets and shared vCPUs throttle long builds; bochka ranks 3rd. | 15th cheapest of 367 $4,111 a month | 92nd of 367, with limits $836 a month | 3rd cheapest of 367 $634 a month |
| Always-on AI employees 50 machines 24/7 · 2 vCPU / 4 GB Daytona keeps a stopped sandbox's disk, while a Fly Machine keeps only what sits on its one Volume; bochka keeps the whole disk and ranks 5th. | 24th cheapest of 366 $6,104 a month | 125th of 366, with limits $816 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 Daytona fits short bursts fully, creating 400 to 600 sandboxes a minute from Tier 2 up, while Fly's API starts about one Machine per second per app. | 25th cheapest of 345 $271 a month | 75th of 345, with limits $94 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 Fly ranks 69th, ahead of Daytona at 154th, because 300 sandboxes of 2 vCPU need 600 vCPU and Daytona's largest pool is 500; bochka ranks 1st. | 154th of 361, with limits $2,000 a month | 69th of 361, with limits $600 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 | 48th of 360, with limits $2,838 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 | 117th of 364, with limits $457 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 busy CI drains a shared Fly vCPU's burst balance; bochka allows 8 vCPU from the $20 plan. | 308th of 377, with limits $805 a month | 152nd of 377, with limits $288 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 | 118th of 368, with limits $53 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; on Fly you build and stream a desktop yourself; bochka streams a 60fps desktop. | 26th cheapest of 369 $1,198 a month | 95th of 369, with limits $173 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 | 160th of 367, with limits $90 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 | 161st of 346, with limits $67 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 Fly ranks 44th, far ahead of Daytona at 202nd, because it can spread scrapers across 17 regions and bill only the seconds they run. | 202nd of 338, with limits $8,073 a month | 44th of 338, with limits $1,232 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 | 118th of 360, with limits $63 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, Fly discontinued GPU Machines in 2026, and bochka has 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 | Fly.io Machines | bochka |
|---|---|---|---|
| Isolation | Container by default; Linux VM and Windows VM classes have their own kernel | Firecracker microVM with its own kernel, on Fly's own servers | 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 in the same run | 26.69 runs/s |
| CPU class | Reserved vCPU; one sandbox is capped at 4 vCPU / 8 GiB by default | Shared vCPUs guarantee 6.25% of a core plus bursts; performance vCPUs get the full core at a higher rate | One CPU class on every plan, with no baseline quota or burst balance |
| Docker, systemd and nested virtualization | Docker in all classes; /dev/kvm only on Linux VMs, and KVM must be turned on for your organization | Root and Docker you install yourself; Fly's own init, no systemd; /dev/kvm not offered | Docker, root, systemd and /dev/kvm on every machine |
| Files after a stop | The disk is kept and billed while stopped; archived containers are free | Root file system is ephemeral; lasting data goes on one Volume, billed for its full size around the clock | The whole disk is kept, with snapshots every minute and on stop; a stopped sandbox costs nothing |
| Pause and fork | Linux VM and Windows: pause, resume and fork with memory kept; containers: no pause or fork | Suspend keeps memory for Machines up to 2GB; a clone copies the config and its Volume starts empty | Fork a running sandbox, disk included; resume reboots from disk (no memory snapshots) |
| Wake on request | Idle sandboxes auto-stop or auto-pause; you start them again through the API | Fly Proxy stops or suspends idle Machines and wakes them when a request arrives | You start and stop machines through the API |
| Desktop and computer use | VNC desktop (xfce4) and a computer-use API on Linux and Windows | None built in; you add a desktop and browser to your own image | 60fps desktop and Chromium, computer use and browser control, embeddable stream |
| Coding agents | Guides install agents and run them through process exec | None built in; you install and run agents yourself | 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 | Secrets arrive as environment variables; Fly's open-source tokenizer proxy can be deployed yourself | AI credentials proxy for model providers and any HTTPS API; switch a credential to another account when credits run out |
| Reaching the sandbox | HTTPS preview URLs on any port, token-protected or public; SSH; no raw TCP or public IP | Public HTTPS and TCP services through Fly Proxy, Anycast IPs, custom domains, private network between Machines | HTTPS URLs for up to 50 ports, token-protected; raw TCP; dedicated IPv6 or IPv4 |
| Outbound internet | Tier 1 and 2 reach only package registries, git hosts and AI APIs; Tier 3 and up get open internet plus per-sandbox domain or CIDR allowlists | Open internet; network policies allow chosen ports and protocols and deny the rest | Open internet on every plan; no provider-side allowlist |
| GPUs and Windows | Nvidia and AMD GPUs, on-demand or preemptible; Windows VM sandboxes | GPU Machines discontinued from 2026-08-01; no Windows | No GPUs; no Windows guests, Wine for Windows apps |
| Regions | US and EU, plus dedicated regions or your own machines (BYOC) | 17 regions on six continents | EU only: Germany, Finland, France |
Every feature Battleships tracks (43)
| Feature | Daytona | Fly.io Machines | 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 | No | Yes |
| Desktop GUI | Yes | No | Yes |
| Browser | Yes | No | Yes |
| Computer-use API | Yes | No | Yes |
| SSH | Yes | Yes | 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 | No | 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 | Yes | Yes |
| Public IPv4 | No | Yes | No |
| Egress allowlist | Yes | Yes | No |
| Secret proxy | Yes | No | Yes |
| Secret proxy for any API | Yes | No | Yes |
| Preinstalled agents | Yes | No | Yes |
| Agent harness API | No | No | Yes |
| MCP server | Yes | Yes | 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 | Yes | No |
| Scoped API keys | Yes | Not published | Yes |
| Spend limits | Not published | No | Yes |
| Usage per sandbox (API) | Yes | No | Yes |
| Audit logs | Yes | Not published | No |
| SSO | Yes | No | 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, so each build takes about a quarter longer on Daytona. Daytona's default container class reported no result, and Fly.io Machines were not in that run, so there is no comparable number for Fly.
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). Fly.io 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 | Fly.io 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) | $15 · Pay As You Go · with limits | $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) | $36 · 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) | $487 · Pay As You Go · with limits | $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 | $110 · Pay As You Go · with limits | $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 | $232 · Pay As You Go · with limits | $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).
Fly.io Machines: Fly bills each Machine per second while it runs, by CPU preset and memory, with no plan fee; stopped Machines pay for their root file system and Volumes are billed for their full size. The figures here use Fly's lowest rate: shared vCPUs bought in 1-year reservation blocks for 40% off.
Fly.io Machines: You pick a monthly plan from $20, and all of it becomes usage credit spent per second on running sandboxes. A stopped sandbox costs nothing and keeps its disk.
Limits in those scenarios
Daytona limits the total vCPU running at once, from 10 to 500 vCPU by tier, so 300 user sandboxes (600 vCPU) and 1,000 short jobs at once (2,000 vCPU) do not fit even Tier 4 without a custom limit. Fly is a compromise in all five scenarios: its lowest figures need a 1-year reservation, its shared vCPUs guarantee only 6.25% of each core, and its API starts about one Machine per second per app. On bochka the 1,000-job burst is limited by starts per minute and per day, so it gets queued even on the $2,000 plan.
| Scenario | Daytona | Fly.io Machines | bochka |
|---|---|---|---|
| One coding agent, workdays |
|
| None that bite |
| One agent that never stops |
|
| None that bite |
| 50 agents in parallel |
|
| None that bite |
| Sandboxes for your users |
|
| None that bite |
| 1,000 short jobs at once |
|
|
|
Which one should you use?
Use Daytona when
your agents need GPUs, Windows or memory pause and fork, or you create many short sandboxes from code in the US or EU.
- GPUs and Windows. Useful if agents test models or need Windows: Daytona rents Nvidia and AMD GPUs by the hour and runs Windows VM sandboxes.
- Made as a sandbox API. Useful if you create many short sandboxes from code: Daytona has SDKs in five languages and creates up to 600 sandboxes a minute.
- Pause and fork with memory. Useful if a sandbox must come back exactly where it was: Daytona's VM classes pause and fork with memory kept.
Use Fly.io Machines when
you host web apps or light services that must run near users worldwide, sleep between requests and wake on traffic.
- 17 regions worldwide. Useful if your users are spread out: Fly runs Machines in 17 regions, from the US to Sydney and Johannesburg.
- Wake on request. Useful for services that sleep between requests: Fly Proxy wakes a Machine when traffic arrives, and small Machines resume with memory kept.
- A full app platform. Useful if you host whole apps: Fly adds public IPs, raw TCP, Anycast, custom domains and a private network around each Machine.
Where bochka fits
If your agents do real work for hours, like installs, builds, tests, Docker and emulators, look at bochka. Daytona gives you that only on its VM class and Fly asks you to build it yourself, while bochka ships a full, faster VM with a lasting disk, a desktop and coding agents in every sandbox.
A full VM with /dev/kvm ready
Daytona's default sandbox is a container sharing the host kernel; its VM class has its own kernel, but /dev/kvm needs KVM turned on for your organization. Fly gives a microVM but no systemd and no /dev/kvm, so emulators and nested VMs cannot run.
A disk that survives every stop
An agent leaves tools, repos and caches all over its disk. Daytona keeps that disk but bills it while stopped, and Fly wipes the root file system, so you pay for a full-size Volume around the clock.
Agents and a desktop built in
On Daytona you install the agent and run it as a process; on Fly you also build the desktop and browser into your image. bochka has Claude Code, Codex and a 60fps desktop ready, driven from outside by API.
Use bochka when your agents do real work for hours: installs, builds, tests, Docker and emulators on a full, faster VM whose disk survives every stop, with a desktop, coding agents and a keys proxy built in. Compare it one to one: bochka vs Daytona and bochka vs Fly.io Machines.
Questions people ask
Is Daytona cheaper than Fly.io Machines?
No, Fly comes out lower in every scenario we priced, using its cheapest rate: one agent running all month is $36 on Fly against $245 on Daytona, and 50 agents in parallel are $487 against $2,682. Fly's figures need a 1-year reservation and shared vCPUs that guarantee 6.25% of a core. On bochka those two come to $26 and $317 a month.
Which is faster, Daytona or Fly.io Machines?
Only Daytona has a measured number: its Linux VM class did 21.52 runs per second in StarSling's 4 vCPU / 8 GB test, where bochka did 26.69. Fly.io Machines were not in that run, and their speed depends on whether you pick shared or performance vCPUs.
Can Daytona and Fly Machines run Docker?
Yes. Daytona has Docker in every sandbox class, and /dev/kvm on its Linux VM class once KVM is turned on for your organization. On Fly you install Docker yourself, and /dev/kvm is not offered, so nested VMs and Android emulators do not run. bochka has Docker, systemd and /dev/kvm on every machine.
Do they keep my files when a sandbox stops?
Daytona keeps the disk of a stopped sandbox and bills it while stopped; archived containers are free. A Fly Machine's root file system is ephemeral, so lasting files must go on its one Volume, billed for its full size. bochka keeps the whole disk, with snapshots every minute, and a stopped sandbox costs nothing.
Do Daytona or Fly.io have GPUs?
Daytona rents Nvidia and AMD GPUs, from RTX 4090 to B300, on demand or preemptible. Fly discontinued its GPU Machines, which are unavailable from 2026-08-01. bochka has no GPUs.
Where do they run?
Daytona runs in the US and EU, plus dedicated regions and your own machines. Fly runs Machines in 17 regions on six continents. bochka runs only in the EU (Germany, Finland and France), with EU data residency.
Try bochka
Install the CLI, then run bochka new.
Product preview