The Ultimate AI Agent Sandboxes Comparison 2026
April Wong
Comparing Nirvana, E2B, Daytona, Modal, Vercel, Blaxel, Cloudflare, Northflank, Fly.io, Beam, Railway, AWS, and Google on persistence, pause/resume speed, isolation, and what actually survives. Every claim sourced from vendor docs, July 2026.
If you're deploying AI agents, you've probably noticed that every sandbox provider now says the similar words: fast, instant, isolated, secure.
We wanted to know what those words actually mean on each platform, so we read every sandbox provider's docs so you don't have to. 13 of them: E2B, Daytona, Modal, Vercel, Blaxel, Cloudflare, Northflank, Fly.io, Beam, Railway, AWS, Google, and our own.
A few things first before we dive in:
- There's ephemeral vs persistent. Ephemeral sandboxes are wiped when they stop: one clean environment per job, nothing left behind. Persistent ones keep their state, so an agent can pick up exactly where it left off.
- Speed is in a few numbers. Boot (creating a fresh sandbox), resume (waking a persistent one), and pause (putting it to sleep). For persistent sandboxes, pause and resume matter more than boot, because you only boot once.
- Isolation comes in two flavors-ish. By VM: imagine every sandbox getting its own brand-new computer with its own kernel. Most isolated. Or by container: sandboxes share the machine's kernel. Faster, thinner walls. And one more question on top of both: whose cluster are you on?
Ok, now you understand how to read these. Let's dive in.
1. The whole market at a glance
Every provider, every axis, one table. The rest of the article is the zoom-in.
| Provider | Boot | Pause → resume | Persistence | Isolation |
|---|---|---|---|---|
| Nirvana | ~2.5s eph / 6-7s pers | Sub-second → Sub-second | Live block volume, no expiry | Container + VM node + dedicated cluster per customer |
| E2B | ~80ms | 4s/GiB → ~1s | FS + RAM snapshot, kept forever | Firecracker microVM |
| Daytona | ~90ms | — | FS kept on stop; S3 volumes | Container (Kata optional) |
| Modal | ~1s | — → seconds | FS snapshots, 30d TTL + volumes | gVisor; VM beta |
| Vercel | ms-class | — → <1s p75 | Auto-snapshot on stop, default on | Firecracker microVM |
| Blaxel | resume-first | ~15s → 25ms | Standby snapshot incl. processes | MicroVM |
| Cloudflare | ~100ms | none; sleep wipes | R2/S3 mounts only | Container in own VM |
| Northflank | <1s | — → boot + rollout | Attached volumes | MicroVM or gVisor |
| Fly Sprites | persistent-first | auto → 0.1-0.5s | NVMe-to-object FS; checkpoints | Fly Machines VM |
| Beam | 1-3s | — | FS snapshots + volumes | gVisor + runc container |
| Railway | — | none; idle destroys | Named disk checkpoints | Isolated VM |
| AWS Lambda MicroVMs | near-instant | auto → near-instant | RAM + disk snapshot; 8h cap | Firecracker microVM |
| Google GKE Agent Sandbox | ~200ms warm pool | pause/resume primitive | K8s primitive; 14d TTL | gVisor, your GKE cluster |
Now the zoom-ins, starting with the word doing the most work in this market.
2. Persistence, the deep dive: what it means and what survives
The word is the same everywhere. The mechanism is not. And here's the truth: most sandbox persistence isn't backed by storage infrastructure at all. It's snapshots being copied around, and where real storage does appear, it's usually generic S3-compatible object storage.
Four designs in the market:
- A live disk. The sandbox's workspace is a block-storage volume that stays mounted-ready. Nothing is copied out on pause; nothing is restored on resume; nothing expires. This is how Nirvana Agent Sandboxes work: /workspace lives on a dedicated Accelerated Block Storage volume with 20,000 sustained IOPS included.
- A snapshot pipeline. State is copied out when the sandbox stops and copied back when it resumes. E2B (filesystem + memory via Firecracker snapshots), Vercel (automatic filesystem snapshot on stop, on by default), Modal (filesystem snapshots that become images), and Blaxel (full standby snapshots including running processes) all work this way.
The trade: snapshots take time to write, and several expire: Modal's filesystem snapshots default to a 30-day TTL, Vercel's default to 30 days from last use (both configurable), and Modal's memory snapshots hard-expire in 7 days. Railway pushes the snapshot idea furthest: its checkpoints are named disk snapshots you boot fresh sandboxes from, and there is no pause at all; idle sandboxes get destroyed. - An object-storage mount. Durable data lives in S3-style storage mounted into the sandbox. Daytona's volumes are S3-backed FUSE mounts. Their own docs note that volumes "can not be used for applications that require block storage access" and are "generally slower for both read and write operations" than the local filesystem. Cloudflare's persistence path is R2/S3 bucket mounts; their lifecycle docs are admirably blunt about the local disk: "All previous state is lost and the environment resets to its initial state... Design for ephemeral state."
- A tiered filesystem. Fly.io's Sprites keep the whole filesystem on local NVMe that syncs to object storage. Filesystem persists; RAM doesn't; wakes take ~100-500ms warm and 1-2s cold, per their docs.
So which design is better for persistent agents? One distinction explains most of it: snapshot vs live volume. A snapshot is a copy of your disk, taken at pause and restored at resume; a live volume is the disk, still mounted-ready while the compute is gone. The copy approach buys you cloning and (for some vendors) frozen memory. The live disk buys you three things: nothing to write out (pause is instant), nothing to restore (resume is instant, and there's no restore step to go wrong), and nothing to expire (disks don't have TTLs; snapshots often do). It also behaves like a real disk, so databases and write-heavy workloads just work, which object-storage mounts explicitly can't promise.
| Provider | Filesystem | Memory/processes | Expiry / caps |
|---|---|---|---|
| Nirvana | Survives (live volume) | No; processes restart on resume | None |
| E2B | Survives | Yes (optional FS-only mode) | Paused sandboxes kept indefinitely; runtime capped at 24h (Pro) / 1h (Base) |
| Vercel | Survives (snapshot) | No | Snapshots default 30-day expiry from last use, configurable incl. indefinite; 24h session cap |
| Modal | Survives (snapshot) | Alpha only; memory snapshot terminates the sandbox | FS snapshots 30-day default TTL; memory snapshots 7 days, hard |
| Blaxel | Survives | Yes, including processes | Standby TTLs on starter tiers; external network connections don't survive |
| Daytona | Survives on stop | No | Auto-stop/auto-archive TTL knobs |
| Fly Sprites | Survives | No; "RAM doesn't persist" (their docs) | None published |
| Northflank | Survives (attached volume) | No | None published |
| Cloudflare | Does not survive sleep | No | 10-minute default idle; bucket mounts for durability |
| AWS AgentCore | Deliberately none; microVM destroyed after session | No | 8h max session |
| Google GKE Agent Sandbox | Survives pause | No | 14-day TTL on sandbox state |
| Beam | Survives via filesystem snapshots | Not documented for sandboxes | Sessions run indefinitely or auto-shutdown on TTL |
| Railway | Survives only via checkpoint (named disk snapshot) | No: "files are preserved, running processes are not" | Idle timeout destroys sandboxes (5-120 min by plan); checkpoints capped by plan |
Honest note on the memory column: Blaxel and E2B genuinely preserve running processes across pause, and we don't: our agents restart and find their files exactly where they left them. For checkpoint-and-continue agent patterns, files are usually what matters; for frozen-mid-computation patterns, the snapshot vendors have a real capability we don't.
And one more honest note: on cold creation speed we're mid-pack (~2.5s ephemeral, 6-7s persistent first boot). Several providers create sandboxes faster. Our bet is that agents that carry state boot once and live in the pause/resume loop, where both of our directions are instant.
3. The table nobody publishes: pause times
Every provider advertises resume speed. Almost nobody documents what pausing costs, and pause is where checkpoint economics live, because a slow pause means paying for compute while the snapshot writes.
| Provider | Pause (going in) | Resume (coming out) | Source |
|---|---|---|---|
| Nirvana | Instant | Instant | Our docs; no snapshot step exists |
| E2B | ~4s per GiB of RAM | ~1s | Their persistence docs |
| Blaxel | ~15s (full-state snapshot, "within approximately 15 seconds") | <25ms | Their lifecycle docs |
| Fly Sprites | Automatic idle detection (cost not published); explicit checkpoints take 10-30s and stop processes | 100-500ms warm / 1-2s cold | Their docs |
| Vercel | Not published (snapshot-on-stop, size-dependent) | Sub-1s p75, 5s p95 | Their engineering blog |
| Modal | Not published (snapshot API ships a 55s default timeout) | Seconds (new sandbox from snapshot) | Their SDK reference |
| Daytona | Not published | Not published | n/a |
| Northflank | Not published (scale-to-zero) | Boot + deployment rollout | Their SDK guide |
| Cloudflare | No pause: sleep discards state | Fresh container (empty state) | Their lifecycle docs |
| AWS Lambda MicroVMs | Not published (auto-suspend) | Near-instant | Launch announcement |
| Google GKE Agent Sandbox | Not published (pause/resume primitive) | ~200ms from warm pools | Their GKE docs |
| Beam | Not published | Cold boot 1-3s; snapshot restore | Their docs |
| Railway | No pause: idle timeout destroys the sandbox (30 min default); persistence = named checkpoints, capture time size-dependent | Boot fresh from checkpoint (time not published) |
Two patterns worth noticing. First, the fastest resumes in the market pay for it on the way in: E2B's pause scales with RAM (a 16 GiB sandbox takes about a minute), and Blaxel's 25ms resume follows a ~15-second entry into standby. Second, eight of thirteen providers don't publish the pause side at all. And a detail from Railway's docs worth knowing: idle sandboxes keep billing until the idle timeout destroys them.
Our pause is instant in both directions for a boring reason: there is nothing to copy. The workspace is already on the disk.
4. Who's a VM, who's a container (and whose cluster are you on?)
Remember the primer: a VM per sandbox means every sandbox gets its own kernel; a container means sandboxes share the machine's kernel with thinner, faster walls. Here's who's who, from their own docs:
| Provider | Per-sandbox isolation | Tenancy |
|---|---|---|
| Nirvana | Hardened, unprivileged container, inside a VM at every node | Dedicated cluster per customer: you never share a kernel, or anything else, with another company |
| E2B | Firecracker microVM | Multi-tenant |
| Vercel | Firecracker microVM, dedicated kernel | Multi-tenant |
| Blaxel | MicroVM | Multi-tenant |
| Fly Sprites | Hardware-isolated VM (Fly Machines) | Multi-tenant |
| AWS Lambda MicroVMs | Firecracker microVM | Multi-tenant (AWS account boundary) |
| Railway | Isolated virtual machine | Multi-tenant |
| Northflank | MicroVM (Kata/Firecracker) or gVisor | Multi-tenant, or your own VPC (BYOC) |
| Cloudflare | Container, each in its own VM | Multi-tenant |
| Modal | Container (gVisor); VM sandboxes in beta | Multi-tenant |
| Daytona | Container (Kata optional) | Multi-tenant |
| Beam | Container (gVisor + runc) | Multi-tenant, or your own cloud |
| Google GKE Agent Sandbox | gVisor | Your own GKE cluster |
Honest reading: the Firecracker camp has the strongest per-sandbox walls, a kernel per sandbox, and we won't pretend otherwise. Our answer works at a different layer: container walls around each sandbox, VM walls around each node, and then the column nobody else fills - a dedicated cluster per customer. Every managed provider above puts different companies' workloads on shared infrastructure; we don't.
And the checklist questions the comparison posts always ask, answered from the same docs. Where a capability doesn't appear in a provider's sandbox documentation, we say "not in their docs" :
Thought processThought process
Table 5: The checklist questions
| Provider | Compute | BYOC | Part of a bigger platform? |
|---|---|---|---|
| Nirvana | CPU environments today | No, by design: a dedicated cluster on our cloud instead | Yes: same cloud as our instances, block storage, and managed Kubernetes |
| E2B | Not in their sandbox docs | Not in their docs | Sandbox-first |
| Daytona | Yes (GPU pricing published: H100, H200, RTX classes) | Not in their docs | Sandbox-first |
| Modal | Yes, though not with memory snapshots enabled | No, managed only | Yes: functions, inference, batch |
| Vercel | Not in their sandbox docs | No, managed only | Yes: frontend cloud |
| Blaxel | Not in their docs | No, managed only | Sandbox-first, plus agent networking and a model gateway |
| Cloudflare | Not in their sandbox docs | No, managed only | Yes: Workers platform |
| Northflank | Yes, self-serve GPU plans | Yes, self-serve across major clouds and on-prem | Yes: full workload runtime |
| Fly Sprites | Not on Sprites | No, managed only | Yes: Fly.io platform |
| Beam | Yes | Yes: open-source runtime, run it in your own cloud | Yes: serverless platform |
| Railway | Not in their sandbox docs | No, managed only | Yes: full PaaS |
| AWS Lambda MicroVMs | No (Lambda) | It is your AWS account | Yes, obviously |
| Google GKE Agent Sandbox | Via GKE node pools | It runs in your GKE cluster | Yes, obviously |
Two notes on that table. On BYOC: people usually want it for isolation and compliance. We deliberately went the other way - every customer gets a dedicated cluster on our cloud, which is the outcome BYOC buyers are after, without operating the infrastructure yourself. And on the platform column: notice almost everyone answers yes. "Full platform" isn't the differentiator the listicles claim; the real differences live in the three tables above.
5. Compliance, quickly
SOC 2 is table stakes at the top of this market: Nirvana (Type II), E2B (Type II), Vercel (Type II), Modal, Blaxel, Northflank, Fly.io, Cloudflare, and AWS all hold audits.
6. The why not: persistent, even for disposable jobs
If resume is instant, there's a new way of using persistent sandboxes, and we recommend trying it if it fits your use case: run them even for disposable jobs. Boot once, pause, and every job after starts with a resume instead of a boot.
Because the speed is already there, the only real consideration is cost, and it's small: storage pennies while paused, plus a workspace wipe between runs. The one exception is spinning off copies: one sandbox can't resume into fifty, so parallel bursts still want ephemeral creates.
The takeaway
"Persistent" now appears on every spec sheet in this market, so the useful question changed. It's no longer does it persist but what does persistence cost you: a pause toll, an expiry window, an object-storage performance caveat, a filesystem that lives in RAM, or nothing.
We built ours as a disk that's just still there, because that's the version whose costs round to zero. If your agents checkpoint and continue, that difference compounds on every single cycle.
Read the documentation for API examples, or talk to us to get an API key and endpoints for your team.
Everything above reflects vendor documentation as of July 10, 2026. Platforms move fast; if your docs have changed or we've mischaracterized something, email us and we'll correct it with a changelog note.
Powering AI, blockchain, and
databases
