Daytona vs Islo
Daytona starts every sandbox as a container and sells Linux VM, Windows and GPU classes on top, in the US and the EU. Islo gives every agent its own microVM in US West or your own cloud, with a gateway that decides what each agent can reach.
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
Islo
Islo is an agent sandbox from Incredibuild: each coding agent gets its own microVM, with network rules and credentials handled at a gateway.
An Islo sandbox is a Linux microVM with its own kernel, built from a container image, with Claude Code, Cursor CLI and Codex preinstalled. Outbound traffic can pass through a gateway that allows or blocks hosts, injects credentials and logs every request. It is built for teams that run coding agents, evals and RL rollouts in the background, on Islo's cloud or in their own cloud account.
- Launched
- May 4, 2026
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 | Islo: price rank | bochka: price rank |
|---|---|---|---|
| Software factory 100 at once · 4 vCPU / 8 GB · 2,200 sessions of 8 h a month Daytona fits fully and Islo is a compromise: Islo runs Docker but documents no /dev/kvm or desktop, Daytona needs its Linux VM class for /dev/kvm, and bochka has both on every machine. | 15th cheapest of 367 $4,111 a month | 326th of 367, with limits $7,402 a month | 3rd cheapest of 367 $634 a month |
| Always-on AI employees 50 machines 24/7 · 2 vCPU / 4 GB All three fit with no session cap; Islo can pause an idle assistant with its memory and wake it on the next request, and Daytona's VM class auto-pauses after an hour idle. | 24th cheapest of 366 $6,104 a month | 30th cheapest of 366 $9,928 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 one-minute runs best: it creates 300 to 600 sandboxes a minute with no plan fee, while Islo needs a raised concurrency limit and bochka's start limits queue big bursts. | 25th cheapest of 345 $271 a month | 153rd of 345, with limits $503 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 at once is more than Daytona's Tier 4 pool of 500 vCPU and more than the 50 running sandboxes reported for Islo's Team plan, so both need custom limits; bochka fits. | 154th of 361, with limits $2,000 a month | 171st of 361, with limits $3,160 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 | 167th of 360, with limits $15,265 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 Islo has a built-in Harbor integration and gateway rules that stop trials from looking up answers, Daytona offers memory forks on its VM class, and bochka runs more sandboxes at once. | 189th of 364, with limits $2,000 a month | 198th of 364, with limits $2,456 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 Islo fits fully while Daytona caps one sandbox at 4 vCPU by default, so an 8 vCPU CI job needs a raised limit there; bochka allows 8 vCPU from the $20 plan. | 308th of 377, with limits $805 a month | 119th cheapest of 377 $1,507 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 | 112th cheapest of 368 $402 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, Islo sandboxes are headless, and bochka streams a 60fps desktop you can embed in your app. | 26th cheapest of 369 $1,198 a month | 310th of 369, with limits $2,210 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 | 113th of 367, with limits $1,105 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 | 66th cheapest of 346 $748 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 | 265th of 338, with limits $14,966 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 | 47th of 360, with limits $746 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, and neither Islo nor bochka has 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 | Islo | bochka |
|---|---|---|---|
| Isolation | Container by default; Linux VM and Windows VM classes with their own kernel on request | Every sandbox is a microVM with its own kernel | Every sandbox is a full VM with its own kernel |
| 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 public benchmark | 26.69 runs/s |
| Docker and nested virtualization | Docker in all classes; /dev/kvm only on Linux VMs, with KVM turned on for your organization | Docker inside and sudo; no /dev/kvm or nested virtualization documented | Docker, root, systemd and /dev/kvm on every machine |
| Desktop and computer use | VNC desktop (xfce4) and a computer-use API on Linux and Windows | A browser inside the sandbox for testing; no desktop or computer-use API | 60fps desktop and Chromium, computer use and browser control, embeddable stream |
| Pause and wake | Linux VM and Windows classes pause and resume with memory kept; containers cannot pause | Pause keeps files, processes and memory; can pause after idle time and wake on the next exec, file access or webhook | Stop and resume; resume reboots from disk (no memory snapshots) |
| Fork | Linux VM and Windows classes fork with memory kept; containers cannot fork | Snapshot a running sandbox's files, then start new sandboxes from it | Fork a running sandbox into new ones |
| Files after a stop | The disk is kept and billed while stopped; archived containers are free | Files kept; whether stopped disk is billed is unclear (the FAQ says no charge, but storage has its own meter) | Snapshots every minute and on stop; a stopped sandbox costs nothing |
| Reaching the sandbox | HTTPS preview URLs on any port, token-protected or public; SSH; no raw TCP or public IP | HTTPS share links anyone with the URL can open, expiring after 24 hours by default; SSH and port-forward through the CLI | HTTPS URLs for up to 50 ports, token-protected; raw TCP; its own IP |
| Outbound internet rules | 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 | Gateway profiles allow or deny by host, path and HTTP method, with default deny, rate limits and per-request logs | Open internet on every plan; no provider-side allowlist |
| Keeping keys out of the sandbox | Secrets proxy swaps placeholders in HTTPS request headers for allowed hosts | Gateway injects stored credentials into outbound requests for any host | AI credentials proxy for model providers and any HTTPS API you register; switch a credential to another account when credits run out |
| Coding agents | Guides install agents and run them through process exec | Claude Code, Cursor CLI and Codex preinstalled; factory lines run agent steps with events, steer and follow-ups | Claude Code, Codex, OpenCode and more preinstalled, with a prompt, steer and events API |
| GPUs and Windows | Nvidia and AMD GPUs on-demand or preemptible; Windows VM sandboxes | No GPUs; Linux only | No GPUs; Linux VMs, with Wine for Windows apps |
| Sandboxes at once | An org-wide pool of 10, 100, 250 or 500 vCPU from Tier 1 to Tier 4, not a sandbox count | Free 5 and Team 50 running sandboxes per launch coverage; paused ones do not count | 100 to 2,000 running sandboxes by plan, raised by adding seats |
| Where it runs | US and EU, plus dedicated regions or your own machines | US West, or inside your own cloud account with BYOC | EU only: Germany, Finland, France; EU data residency |
Every feature Battleships tracks (43)
| Feature | Daytona | Islo | 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 | Not published | Yes |
| Desktop GUI | Yes | No | Yes |
| Browser | Yes | Yes | 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 | 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 | Yes | 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 | Yes | No |
| Open source | No | No | No |
| Scoped API keys | Yes | Not published | Yes |
| Spend limits | Not published | Not published | Yes |
| Usage per sandbox (API) | Yes | Yes | Yes |
| Audit logs | Yes | Yes | No |
| SSO | Yes | Yes | No |
| SOC 2 | Yes | Not published | No |
| HIPAA | Yes | Not published | 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 in that run. Islo was not part of it, so there is no comparable number for Islo.
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). Islo 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 | Islo, 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) | $101 · Free | $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) | $420 · Free | $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) | $4,863 · Team | $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 | $1,382 · Team · 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 | $3,053 · Team · with limits | $2,000 · $2000/mo · with limits |
Daytona: Daytona bills per second for the vCPU, memory and disk you reserve, including while a sandbox starts or stops, and keeps billing the disk while it 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).
Islo: Islo bills each CPU core and each GB of memory and disk while a sandbox runs, billed per hour, with no plan fee. An idle sandbox keeps billing until a pause-after-idle timer fires, and that timer can only be set when the sandbox is created.
Islo: 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, memory and disk running at once (500 vCPU at Tier 4), and Islo's Team plan is reported at 50 running sandboxes. So 300 sandboxes for your users and 1,000 short jobs at once fit neither without a custom limit. Daytona also caps one sandbox at 4 vCPU / 8 GB by default and only opens the internet from Tier 3. Neither publishes an egress price, so their totals here leave egress out.
| Scenario | Daytona | Islo | 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 forks that keep memory, or must run in both the US and the EU, and containers by default are fine for you.
- GPUs by the hour. Useful if your agents train or test models: Daytona rents Nvidia and AMD GPUs by the hour, from RTX 4090 to B300.
- Windows and memory forks. Useful if you need Windows desktops or forks that keep memory: Daytona's VM classes do both.
- US, EU and your own machines. Useful if you need both US and EU regions: Daytona runs in each and can also run sandboxes on machines you bring.
Use Islo when
every agent must get its own VM by default, with per-host egress rules, a log of every outbound call, and sandboxes that pause with memory and wake on request.
- A VM for every agent by default. Useful if you want kernel isolation without picking a class: every Islo sandbox is a microVM with its own kernel.
- Egress rules and request logs. Useful if you must control what agents reach: Islo allows or blocks each host, path and method, and logs every call.
- Pause with memory, wake on request. Useful for agents that sit idle between tasks: Islo pauses them with memory kept and resumes on the next request.
Where bochka fits
If your agents do long, real work like installs, builds, tests, Docker and emulators, and you can run in the EU, bochka is worth a look before either. Every bochka sandbox is a full VM with /dev/kvm, a desktop and ports you can host on, and it ran faster than Daytona in the one public test that measured both.
A full VM with /dev/kvm on every machine
Daytona's default sandbox is a container that shares the host kernel, and /dev/kvm needs its VM class plus KVM turned on for your organization. Islo has VMs but documents no /dev/kvm, so Android emulators stop at the first boot.
Ports you can host on
Daytona has no raw TCP or public IP, and Islo share links are open to anyone with the URL and expire after 24 hours by default. bochka serves up to 50 token-protected HTTPS ports and raw TCP for as long as the sandbox lives.
Room for a fleet with open internet
Daytona opens the internet only from Tier 3, a $500 top-up, and its biggest pool is 500 vCPU. Islo's Team plan is reported at 50 running sandboxes. bochka has open internet on every plan and 100 to 2,000 sandboxes by plan.
Use bochka when your agents do real work for hours: installs, builds, tests, Docker and emulators on a full, faster VM with a desktop, ports you can host on and coding agents built in. Compare it one to one: bochka vs Daytona and bochka vs Islo.
Questions people ask
Is Daytona cheaper than Islo?
In the scenarios we priced, yes: one coding agent on workdays comes to $56 a month on Daytona and $101 on Islo, and one agent running all month comes to $245 versus $420. 50 agents in parallel come to $2,682 versus $4,863. On bochka the same three come to $20, $26 and $317 a month.
Which is faster, Daytona or Islo?
There is no head-to-head number. In StarSling's public run, Daytona's Linux VM class did 21.52 runs per second and bochka did 26.69; Islo was not tested, and Daytona's default containers reported no result.
Are Daytona and Islo sandboxes containers or VMs?
Daytona's default sandbox is a Linux container, with Linux VM and Windows VM classes you can choose. Every Islo sandbox is a microVM with its own kernel, built from a container image. bochka gives every sandbox a full VM.
Can Daytona and Islo run Docker?
Yes, both run Docker inside a sandbox. Daytona gives /dev/kvm only on its Linux VM class with KVM turned on for your organization, and Islo documents no /dev/kvm. bochka has Docker, systemd and /dev/kvm on every machine.
Can I limit what an agent reaches on the internet?
On both. Daytona from Tier 3 lets you limit each sandbox to chosen domains or IP ranges, and Islo's gateway allows or denies by host, path and HTTP method and logs each request. bochka has open internet with no provider-side allowlist, and its credentials proxy keeps real API keys out of the sandbox.
Where do Daytona and Islo run?
Daytona runs in the US and the EU, plus dedicated regions and your own machines. Islo runs in US West, or inside your own cloud account with BYOC. 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