E2B vs Fly.io Machines
Both run your code in Firecracker microVMs. E2B is built as a sandbox for agent jobs, with SDKs, memory pause and forks, while Fly.io Machines are the building block of an app hosting platform that you turn into a sandbox yourself.
The companies and products
E2B
E2B calls itself the AI agent cloud: an API that gives each agent session its own isolated Linux machine.
Every E2B sandbox is a Firecracker microVM that boots from a snapshot, so it starts fast and can be paused and resumed with its memory. You build custom sandboxes from templates based on a Docker image, and drive them from Python or JavaScript SDKs. It is built for teams that run many short code, data or agent jobs, and its runtime is open source.
- Isolation
- Firecracker microVM per sandbox
- Bring your own cloud
- Enterprise data plane in your AWS, GCP or Azure account
- Compliance
- SOC 2 Type II; HIPAA BAA on request
- Machine size
- 1 to 8 vCPU and 1 to 8 GiB RAM, CPU only
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. “16th cheapest of 367” means 15 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 | E2B: 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 E2B fits fully but stops sessions at 24 hours on Pro; Fly is a compromise because its root disk resets and its cheapest CPUs are shared; bochka fits with no cap and /dev/kvm. | 16th cheapest of 367 $4,143 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 An assistant that runs all month hits E2B's 24-hour cap and must pause and resume, while on Fly it keeps only what sits on its one Volume; bochka keeps the whole disk. | 51st of 366, with limits $5,348 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 E2B is built for this, with fast starts and memory pause; Fly can do it for less on shared CPU, but you package the interpreter yourself. | 37th cheapest of 345 $421 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 E2B wakes a paused sandbox on the next request, while Fly's API creates about one Machine per second per app; bochka gives each user a full VM with hosting built in. | 23rd cheapest of 361 $2,354 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 E2B suits many short rollouts that branch from one state, thanks to memory forks and a high start rate; a Fly clone starts with an empty Volume. | 2nd cheapest of 360 $9,384 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 | 78th cheapest of 364 $1,975 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 CI keeps the CPU busy, which drains a shared Fly vCPU's burst balance, and neither E2B nor Fly offers nested virtualization for Android or VM builds; bochka has /dev/kvm. | 337th of 377, with limits $1,429 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 | 192nd of 368, with limits $358 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 E2B has a Linux desktop for computer use, while on Fly you build and stream a desktop yourself; bochka streams its desktop at 60fps. | 32nd cheapest of 369 $1,342 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 | 100th of 367, with limits $746 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 | 57th cheapest of 346 $554 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 fits mass scraping better than E2B: it can spread scrapers across 17 regions and pay only for the seconds they run. | 227th of 338, with limits $9,223 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 | 11th cheapest of 360 $1,043 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 | 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 | E2B | Fly.io Machines | bochka |
|---|---|---|---|
| Kind of product | Agent sandbox API with Python and JavaScript SDKs | App hosting platform; Machines are its VM building block with a REST API | Agent sandbox: a full VM per agent, ready to use |
| Isolation | Firecracker microVM with its own kernel | Firecracker microVM with its own kernel, on Fly's own servers | Full VM with its own kernel on dedicated AMD Ryzen 9 9950X hosts |
| Docker, systemd and nested virtualization | Docker and systemd inside; nested virtualization not supported | 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 |
| Session length | Up to 1 hour on Hobby, 24 hours on Pro; pausing resets the clock | No documented maximum runtime; a Machine runs until it is stopped | No cap on paid plans; you set the time to live |
| Files after a stop | Pausing keeps disk and memory; paused sandboxes are not billed | 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 with memory | Resumes in about a second with processes still running | Suspend keeps memory for Machines up to 2GB; dropped on deploy or host move | Resume reboots from disk (no memory snapshots) |
| Fork | Fork a running sandbox with its memory, up to 20 copies per call | Clone copies a Machine's config; a cloned Volume starts empty | Fork a running sandbox, disk included |
| Wake on request | A paused sandbox can resume on the next HTTP request or SDK call | 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 | Linux desktop for computer use | 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 | Templates and guides for many agents, run through the command API | 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 injected into outbound HTTPS headers (private beta) | 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 URL per port, public by default unless you turn on a token; no dedicated IP | Public HTTPS and TCP through Fly Proxy, Anycast IPs, custom domains, private network between Machines | HTTPS URLs for up to 50 ports, token-protected by default; raw TCP; dedicated IPv4 or IPv6 |
| Outbound rules | Allow and deny lists by IP, CIDR or domain | Network policies allow chosen ports and protocols and deny the rest | Open internet on every plan; no provider-side allowlist |
| CPU | 12.61 runs/s on the 4 vCPU / 8 GB benchmark | Not measured; shared vCPUs guarantee 6.25% of a core, performance vCPUs get the full core | 26.69 runs/s on the same benchmark, one CPU class with no burst balance |
| Regions | US by default; EU and APAC on Pro and above, enabled by support | 17 regions on six continents | EU only: Germany, Finland, France |
Every feature Battleships tracks (43)
| Feature | E2B | Fly.io Machines | bochka |
|---|---|---|---|
| Full VM (own kernel) | Yes | Yes | Yes |
| Docker inside | Yes | Yes | Yes |
| Nested virtualization | No | No | Yes |
| Root | Yes | Yes | Yes |
| Systemd | Yes | 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) | 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 | 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 | No | No | No |
| Windows | No | No | No |
| Arm64 | No | No | No |
| Self-hosting | Yes | No | No |
| BYOC | Yes | No | No |
| Open source | Yes | Yes | No |
| Scoped API keys | Not published | Not published | Yes |
| Spend limits | Yes | No | Yes |
| Usage per sandbox (API) | No | No | Yes |
| Audit logs | Not published | Not published | No |
| SSO | No | 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
On the StarSling hpc-sandbox-benchmarks Node.js build-and-test loop at 4 vCPU / 8 GB, bochka did 26.69 runs per second and E2B did 12.61, so bochka finished about twice the CPU work in the same time. Fly.io Machines were not part of that run, so there is no comparable score for them. Fly's result would depend on the CPU class: shared vCPUs guarantee only 6.25% of a core, while performance vCPUs get the full core.
Node.js build-and-test loop at 4 vCPU / 8 GB, higher is better. Measured with the open hpc-sandbox-benchmarks suite. 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 | E2B, 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 | $202 · Pro | $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 | $368 · Pro · with limits | $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,773 · Pro | $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 | $1,395 · Pro+ (600 concurrent) | $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,797 · Pro++ (1,100 concurrent) | $232 · Pay As You Go · with limits | $2,000 · $2000/mo · with limits |
E2B: E2B bills per second for the vCPU and RAM you set, idle time included, until you pause or kill the sandbox. Pro costs $150 a month for higher limits with no usage credit, and more concurrency costs $500 a month per 500 slots.
Fly.io Machines: Fly bills each Machine per second while it runs, by CPU preset and memory, with no plan fee, and Volumes are billed for their full size all month. The figures here use Fly's lowest rate: shared vCPUs bought in 1-year reservation blocks for 40% off.
Fly.io Machines: 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
E2B caps a session at 24 hours on Pro, which is why it does not fit the always-on scenario, and its Pro plan includes 20 GiB of disk. Fly is marked a compromise in every scenario because its lowest figures need a 1-year reservation and use shared vCPUs that guarantee only 6.25% of each core, so long builds get throttled. Fly's API also creates about one Machine per second per app, while E2B Pro++ only queues bursts above 300 starts a minute. bochka has no session cap, but at 1,000 short jobs at once its start limits per hour and per day make it a poor fit.
| Scenario | E2B | 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 E2B when
you run many short agent or code jobs that pause, fork or wake on request, and you want a sandbox SDK rather than a bare VM.
- Built as a sandbox. For teams that want agent sandboxes from an SDK, E2B ships templates, a desktop and command API instead of a bare VM.
- Memory pause and forks. For short jobs that branch or sleep, E2B resumes in about a second with processes running and forks a sandbox with its memory.
- Domain-level outbound rules and self-hosting. E2B can limit a sandbox to chosen domains, and its Apache-2.0 runtime can run on your own Linux host with KVM.
Use Fly.io Machines when
you host apps or light services that must run near users worldwide, sleep between requests and wake on traffic.
- 17 regions worldwide. For work that must sit near users outside Europe, Fly runs Machines in 17 regions, from the US to Sydney and Johannesburg.
- No session cap. For services that run for weeks, a Fly Machine has no documented maximum runtime and keeps going until you stop it.
- A full app platform. For teams hosting a product next to their sandboxes, Fly adds Anycast IPs, custom domains, raw TCP and a private network.
Where bochka fits
If your agents do long, heavy work, both options make you give something up: E2B cuts sessions at 24 hours and has no nested virtualization, and Fly gives you an app VM that you turn into a sandbox yourself. bochka gives every agent a full VM with its disk kept, a desktop, coding agents and a keys proxy, on CPUs that ran the benchmark about twice as fast as E2B.
A full VM with /dev/kvm
Neither E2B nor Fly offers nested virtualization, so Android emulators and VMs cannot start. Fly also has no systemd, so services that expect it need rework. bochka has Docker, systemd and /dev/kvm on every machine.
A disk that survives, with no session cap
On E2B an agent stops at 24 hours on Pro and your code must pause and resume it. On Fly the root disk resets, so caches and repos need a Volume billed all month. bochka keeps the whole disk with no cap.
Agents, desktop and keys built in
On Fly you build the image with a desktop, browser and agents, then write the code that drives them. E2B's key injection is in private beta. bochka ships coding agents you drive from outside, a 60fps desktop and a credentials proxy.
Use bochka when your agents do real work for hours: installs, builds, tests, Docker and emulators on a fast full VM whose disk survives every stop, with a desktop, coding agents and a keys proxy built in. Compare it one to one: bochka vs E2B and bochka vs Fly.io Machines.
Questions people ask
Is E2B cheaper than Fly.io Machines?
No, Fly's figures are lower in all five scenarios on this page, for example $36 against $368 for one agent running all month. Those Fly figures assume a 1-year reservation of shared vCPUs that guarantee only 6.25% of each core, so busy agents get throttled.
Which is faster, E2B or Fly.io Machines?
There is no shared measurement. E2B did 12.61 runs per second on the hpc-sandbox-benchmarks CPU test at 4 vCPU / 8 GB, and bochka did 26.69, but Fly.io Machines were not in that run.
Can E2B and Fly.io Machines run Docker?
Yes, both run Docker inside the microVM, though on Fly you install it yourself in your image. Neither offers nested virtualization, so Android emulators and VMs are out. bochka has Docker, systemd and /dev/kvm on every machine.
Can a sandbox run for days on E2B or Fly?
Not in one E2B session: it stops after 24 hours on Pro and 1 hour on Hobby, though pausing resets the clock. A Fly Machine has no documented maximum runtime, but its root disk is ephemeral, so lasting files belong on a Volume.
Can I use Fly.io Machines as an AI agent sandbox?
Yes, but you build the sandbox yourself: you package the tools, browser and agents into an image, add a Volume for files that must last, and write the code that drives the agents. E2B and bochka ship more of that ready to use.
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