smol machines vs Islo
Both give each agent a microVM with its own kernel. smol machines is an open-source engine you can run anywhere, with live branches that keep memory, while Islo wraps its sandboxes in a gateway that controls outbound traffic, keeps credentials out and logs every call.
The companies and products
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
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. “12th cheapest of 345” means 11 of the other 344 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 | smol machines: price rank | Islo: price rank | boat: price rank |
|---|---|---|---|
| Software factory 100 at once · 4 vCPU / 8 GB · 2,200 sessions of 8 h a month Both run Docker inside their microVMs, but neither exposes /dev/kvm on hosted machines, so Android emulators and nested VMs need boat. | 73rd of 367, with limits $604 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 Islo can pause an idle assistant with its memory and wake it on the next request; smol machines keeps the files but empties memory on stop, and boat adds a desktop and a browser. | 148th of 366, with limits $1,038 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 smol machines fits short code runs well, with a one-minute minimum and branches of a warm machine that pay the minimum once; Islo needs more than 50 running sandboxes for large bursts. | 12th cheapest of 345 $140 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 for your users at once fits smol machines on Startup, but is more than the 50 running sandboxes reported for Islo's Team plan. | 7th cheapest of 361 $531 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 smol machines can branch a running machine with its memory and processes, so many rollouts start from one prepared state; Islo starts new sandboxes from a snapshot of files. | 111th of 360, with limits $6,978 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; smol machines ships registry images with the Harbor eval harness. | 36th cheapest of 364 $670 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 All three run Docker for CI jobs; only boat exposes /dev/kvm for jobs that build Android apps or boot VMs. | 66th cheapest of 377 $514 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 | 216th of 368, with limits $29 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 Neither has a desktop or a computer-use API, so you build your own screen stack inside the VM; boat streams a 60fps desktop with Chromium agents can click. | 90th of 369, with limits $156 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 | 176th of 367, with limits $136 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 | 241st of 346, with limits $242 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 | 148th of 338, with limits $4,344 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 | 252nd of 360, with limits $377 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 | 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 | smol machines | Islo | boat |
|---|---|---|---|
| Isolation | libkrun microVM with its own guest kernel | A microVM with its own kernel for each sandbox | Full VM with its own kernel on dedicated AMD Ryzen 9 9950X hosts |
| Docker and nested virtualization | Docker inside the VM; nested virtualization not exposed in the cloud create API | Docker inside and sudo; no /dev/kvm or nested virtualization documented | Docker, root, systemd and /dev/kvm on every machine |
| Desktop and computer use | No hosted desktop; a guide shows running your own Chromium inside a machine | A browser inside the sandbox for testing; no desktop or computer-use API | Linux desktop streamed at 60fps, Chromium, computer use and an embeddable stream |
| Stop and resume | Files survive a stop, memory is emptied; stopped disk keeps billing; the next command starts a stopped machine | Pause keeps files, processes and memory; can pause after idle time and resume on the next exec, file access or webhook | Disk saved every minute and on stop; a stopped sandbox costs nothing; resume reboots from disk |
| Fork | Branch a running machine with its memory and processes; checkpoints capture RAM to a file | Snapshot a running sandbox's files, then start new sandboxes from it | Fork a running sandbox with its disk |
| Shell access | Command API, sessions and a WebSocket terminal capped at one hour per connection; no SSH | SSH and port-forward through the CLI | SSH, plus a command API and terminal |
| Inbound access | Up to 16 published ports through a returned URL or an authenticated connect route; no dedicated IP | HTTPS share links anyone with the URL can open, expiring after a TTL (24 hours by default); no raw TCP over shares | HTTPS URLs for up to 50 ports, token-protected by default; raw TCP; its own IP |
| Outbound rules | Blocked, open, or an allowlist of hosts and CIDR ranges | Gateway profiles allow or deny by host, path and HTTP method, with default deny, rate limits and content filters, and a log of every request | Open internet, no provider-side allowlist |
| Keeping API keys out of the sandbox | Cloud secrets are environment variables the guest can read; placeholder swapping only in self-hosted smolvm | Gateway injects stored credentials into outbound requests for any host; they never reach the sandbox | Credentials proxy for model providers and any HTTPS API; switch a credential to another account when credits run out |
| Coding agents | Registry images with the Codex CLI and the Harbor eval harness, run through the command API | Claude Code, Cursor CLI and Codex preinstalled; factory lines run agent steps with events and steer, on a schedule, webhook or GitHub, Slack and Linear events | Seven agents preinstalled, including Claude Code and Codex, with a prompt, steer and events API |
| Sandboxes at once | 20 on Standard, 100 on Pro, 1,000 on Startup; stopped machines hold a slot | 5 on Free and 50 on Team per launch coverage; paused ones do not count; more by contract | 100 to 2,000 running sandboxes by plan, raised by adding seats |
| Open source and self-hosting | Open-source smolvm runs on your laptop or your own servers with the same .smolmachine artifact | Not open source; BYOC puts the control plane and sandboxes in your own cloud account | Hosted only |
| Where it runs | No region choice in the cloud API | US West, or your own cloud account with BYOC | EU only (Germany, Finland, France), with EU data residency |
| Billing | Base fee per running machine-hour plus the CPU and memory the guest uses, one-minute minimum; plan fees on top of usage | Per CPU core and per GB of memory and disk while running, billed per hour; no plan fee; egress has no published price | Plans from $20 a month, all of it usage credit spent per second; a stopped sandbox costs nothing |
Every feature Battleships tracks (43)
| Feature | smol machines | Islo | boat |
|---|---|---|---|
| Full VM (own kernel) | Yes | Yes | Yes |
| Docker inside | Yes | Yes | Yes |
| Nested virtualization | No | No | Yes |
| Root | Not published | Yes | Yes |
| Systemd | Not published | Not published | Yes |
| Desktop GUI | No | No | Yes |
| Browser | No | Yes | Yes |
| Computer-use API | No | No | Yes |
| SSH | No | Yes | Yes |
| Persistent disk | Yes | Yes | Yes |
| Pause/resume | Yes | Yes | Yes |
| Automatic snapshots | No | Yes | Yes |
| Fork/clone | Yes | Yes | Yes |
| Live fork (no pause) | Yes | 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 | Yes | Yes | No |
| HTTPS preview URLs | Yes | Yes | Yes |
| Raw TCP inbound | Not published | No | Yes |
| Public IPv4 | No | No | No |
| Egress allowlist | Yes | Yes | No |
| Secret proxy | No | Yes | Yes |
| Secret proxy for any API | No | Yes | Yes |
| Preinstalled agents | Yes | Yes | Yes |
| Agent harness API | No | Yes | Yes |
| MCP server | Yes | No | No |
| GPU | No | No | No |
| Windows | No | No | No |
| Arm64 | Yes | No | No |
| Self-hosting | Yes | No | No |
| BYOC | Yes | Yes | No |
| Open source | Yes | No | No |
| Scoped API keys | Not published | Not published | Yes |
| Spend limits | Yes | Not published | Yes |
| Usage per sandbox (API) | Yes | Yes | Yes |
| Audit logs | Not published | Yes | No |
| SSO | Yes | Yes | No |
| SOC 2 | No | Not published | No |
| HIPAA | No | Not published | No |
| EU data residency | No | No | Yes |
| Zero data retention | Not published | Not published | Yes |
Performance
There is no comparable measurement for either: neither smol cloud nor Islo has been run on the StarSling hpc-sandbox-benchmarks CPU test. boat did 26.69 runs per second on that Node.js build-and-test loop at 4 vCPU / 8 GB. smol machines publishes a boot time under 200ms for smolvm, which is a start-time figure, not CPU speed.
Node.js build-and-test loop at 4 vCPU / 8 GB, higher is better. Measured with the open hpc-sandbox-benchmarks suite. smol machines and Islo 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 | smol machines, a month | Islo, a month | boat, 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 | $25 · Standard | $101 · Free | $20 · $20/mo |
| One agent that never stops 4 vCPU / 8 GB, 50 GB disk, running 24/7 all month | $93 · Standard | $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 | $1,139 · Pro | $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 | $465 · Startup | $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 | $1,389 · Startup | $3,053 · Team · with limits | $2,000 · $2000/mo · with limits |
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 even while stopped. Pro ($20 a month) and Startup ($150 a month) are fees on top of usage, not credit.
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 egress has no published price.
Islo: 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
smol machines caps machines by plan: 20 on Standard, 100 on Pro and 1,000 on Startup, with stopped machines still holding a slot, so 50 agents need Pro and 1,000 short jobs at once need Startup. Islo's Team plan is reported at 50 running sandboxes, so 300 sandboxes for your users and 1,000 short jobs at once do not fit without a custom contract. boat's limit that bites is starts: the 1,000-job burst is queued above 90 starts a minute. Islo publishes no egress price, so its totals leave egress out.
| Scenario | smol machines | Islo | boat |
|---|---|---|---|
| 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 smol machines when
you want one open-source VM engine from your laptop to your own servers, branch running machines with their memory, or start very large bursts of short jobs.
- Open source, from laptop to your own servers. Teams that want one VM engine locally, in a hosted cloud and on their own servers can use open-source smolvm.
- Live branches with memory. Useful for RL and test fan-out: branch a running machine with its memory and processes, paying the one-minute minimum once.
- Large bursts on one plan. Teams that start 1,000 short jobs at once can run them all on the Startup plan, where Islo's Team plan stops at 50.
Use Islo when
you need per-host egress rules with a log of every outbound call, credentials injected at a gateway, sandboxes that pause with memory, or a US region or your own cloud account.
- 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.
- Keys that never enter the sandbox. Islo's gateway adds stored credentials to outbound requests, while smol cloud puts secrets in environment variables the guest can read.
- 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 boat fits
smol machines and Islo both give an agent a headless microVM: one with live branching and self-hosting, the other with a gateway around it. If your agents need a screen, emulators, SSH and ports you can host on, boat gives them a whole machine with coding agents you drive from outside and keys kept in a proxy.
A desktop and /dev/kvm
Neither has a desktop or exposes /dev/kvm on hosted machines, so a computer-use agent waits while you build a screen stack in each image, and Android emulators do not boot. boat ships a 60fps desktop, Chromium and /dev/kvm.
Ports and SSH you can rely on
smol cloud has no SSH and caps you at 16 published ports, and Islo share links open to anyone with the URL and expire after 24 hours by default. boat serves 50 token-protected HTTPS ports, raw TCP and SSH.
Stops that keep work, room to grow
smol machines bills stopped disk and counts stopped machines against its cap, and an idle Islo sandbox bills until a pause timer set at creation fires, with 50 running on Team. boat saves disk every minute, stops free, runs up to 2,000.
Use boat when your agents need a whole machine: Docker, /dev/kvm, SSH, a desktop and a browser, ports you can host on, coding agents you drive from outside and keys that never enter the sandbox, in the EU. Compare it one to one: boat vs smol machines and boat vs Islo.
Questions people ask
Is smol machines cheaper than Islo?
In every scenario we priced, yes. One coding agent on workdays comes to $25 a month on smol machines and $101 on Islo, one agent running all month to $93 versus $420, and 50 agents in parallel to $1,139 versus $4,863. boat comes to $20, $26 and $317 for the same three.
Which is faster, smol machines or Islo?
We cannot say: neither has been measured on the StarSling CPU benchmark we use. boat did 26.69 runs per second on it at 4 vCPU / 8 GB. smol machines publishes a boot time under 200ms, which is start time, not CPU speed.
Can smol machines and Islo run Docker?
Yes, both run Docker inside their microVMs. Neither exposes /dev/kvm or nested virtualization on hosted machines, so Android emulators and nested VMs will not start. boat has Docker, systemd and /dev/kvm on every machine.
Do they keep API keys out of the sandbox?
Islo does: its gateway injects stored credentials into outbound requests, so they never reach the sandbox. smol cloud secrets are plaintext environment variables inside the guest; placeholder swapping exists only in self-hosted smolvm. boat's credentials proxy keeps real keys outside for model providers and any HTTPS API.
Can either fork a running sandbox?
smol machines branches a running machine into children that keep its memory and running processes. Islo snapshots a running sandbox's files and starts new sandboxes from that. boat forks a running sandbox with its disk, and the fork boots fresh.
Where do they run?
smol cloud has no region choice in its API, and open-source smolvm runs on your own laptop or servers. Islo runs in US West, or inside your own cloud account with BYOC. boat runs only in the EU, with EU data residency.
Try boat
Install the CLI, then run boat new.
7-day free trial