Where to Run Agent Code: AI Agent Sandbox Providers Compared

Where to Run Agent Code: AI Agent Sandbox Providers Compared

Author
Daniel Botha
Daniel Botha
Writer at Fly.io
Published

An AI agent sandbox provider is a hosted service that runs code an agent wrote in an isolated environment, and the real choice is between three different products: a stateless code runner, a persistent computer, and a control plane that manages fleets of either.

Your agent has just produced its first shell command, and you are about to run it. Not on your laptop, where a mistyped path deletes the wrong directory, and not on the production box, where a curl to the wrong host leaks a key. Somewhere else.

E2B, Modal, Daytona, Vercel Sandbox, Cloudflare Sandbox and Fly.io Sprites all say “sandbox” and mean different things by it: a different isolation boundary, a different answer to what happens when the agent goes quiet, a different cap on a session. Pick by feature list and you find out in week three that your coding agent’s working tree evaporated at the ten-minute mark.

What Are You Actually Choosing Between?

Three product shapes share the word “sandbox”, and most bad picks come from buying one shape when the agent needed another.

Isolated code runners execute a snippet or a command and return the result, then discard everything unless you snapshot it. A Modal Sandbox has a default maximum lifetime of five minutes,[1] and a Cloudflare sandbox deletes all files and terminates all processes when its container stops.[2]

Persistent computers are full Linux machines with a disk that stays put: the agent installs dependencies on Monday, comes back on Thursday, and the repository is where it left it. A stopped Daytona sandbox keeps its identity, filesystem and configuration,[3] an E2B pause saves filesystem and memory together,[4] and Vercel snapshots automatically on stop.[5]

Control planes are the orchestration layer on top, a different purchase from the sandbox itself. E2B’s BYOC tier is the case in point: an Enterprise deployment running sandboxes inside your own AWS or Google Cloud VPC, managed rather than self-hosted.[6] The agent sandbox explainer covers what a sandbox has to isolate.

How to Evaluate an AI Agent Sandbox

Four things separate these products, and all four sit in the reference docs rather than the marketing page: isolation, what survives idle time, egress control, and the timers.

The Isolation Primitive

Every provider draws its boundary with one of three tools. E2B makes each sandbox a Firecracker microVM rather than a container, booting its own kernel,[7] and Vercel Sandbox does the same, with its own filesystem and network.[8] Modal containerizes and virtualizes with gVisor, a userspace kernel that answers the tenant’s syscalls itself.[9] Daytona documents two classes: an isolated container with dedicated namespaces, and a full VM whose kernel makes pause, fork and hot snapshots possible.[10] Cloudflare builds on Containers, giving each sandbox its own container with a full Linux environment,[11] each instance inside its own VM.[12] The trade-off between a hardware boundary and a userspace kernel is its own page, Firecracker vs gVisor.

State Between Turns

An agent that writes files and comes back later needs a disk that outlives the session. A Cloudflare sandbox deletes every file and terminates every process when the container stops.[2] Modal expects a filesystem snapshot before the 24-hour maximum lifetime runs out,[1] and its memory snapshots carry known limitations and expire after seven days.[13] Vercel snapshots the filesystem on stop and boots a new session from it, so background services restart from an onResume hook,[5] and Daytona keeps the filesystem across stop and start, archiving a stopped container after seven days.[3] An E2B pause preserves filesystem and memory together, including running processes, and is kept indefinitely.[4] A Sprite keeps its disk with no expiry.

The Network Boundary

Filesystem isolation is not enough if the agent still has open egress. Every provider documents a per-sandbox network control, differing in the default and in what a policy can say. E2B is open by default, takes allow and deny lists of IPs, CIDR blocks and domains, and adds per-host rules whose egress proxy swaps a placeholder for a fresh token, so the credential never enters the sandbox.[14] Modal takes block_network, an outbound CIDR allowlist and a domain allowlist.[15] Daytona puts every sandbox behind a firewall, restricted by default on tiers 1 and 2 and open on 3 and 4, where a per-sandbox allow list replaces the default.[16] Vercel takes a network policy up to deny-all.[5] Cloudflare blocks, allows and intercepts outbound HTTP, injecting authorization headers in the Worker.[11] Sprites make the policy read-only from inside, so the agent cannot rewrite its own rules.

Timers and the Cost Shape

Every hosted sandbox has a timer, and the timer sets the bill. Modal and Vercel both default to five minutes.[17][18] Vercel caps a session at 45 minutes on Hobby and 24 hours on Pro, resetting on each stop and resume,[18] and E2B caps continuous runtime at one hour on Hobby and 24 hours on Pro, which pausing resets.[19] Daytona stops a sandbox after 15 idle minutes,[3] Cloudflare sleeps one after ten,[2] and a Sprite pauses after roughly 30 seconds. What matters more is what happens at zero: E2B terminates a sandbox at timeout unless you set the action to pause,[4] and a kill loses state unless you paid for a snapshot. Rates and snapshot fees are in AI sandbox pricing; a per-session product punishes an agent that waits on a model for hours.

Which Sandbox Should I Use for AI Agents?

Pick the persistent computer for a coding agent that works across turns, the code runner for a tool that finishes in seconds, and check the GPU column if the agent trains or serves a model.

Provider Isolation What survives idle Idle default Session cap Egress control GPU
E2B Firecracker microVM Killed by default; pause keeps filesystem and memory indefinitely 5 min timeout 1 h Hobby, 24 h Pro, resets on pause Allow and deny lists, per-host token injection No
Modal Sandboxes gVisor Nothing unless snapshotted; memory snapshots expire in 7 days 5 min lifetime 24 h maximum block_network, CIDR and domain allowlists Yes
Daytona Container by default, VM class with own kernel Filesystem; archived after 7 days stopped Stops after 15 min None Per-sandbox firewall, tier-dependent Yes
Vercel Sandbox Firecracker microVM Filesystem via automatic snapshot, expiring 30 days after last use 5 min timeout 45 min Hobby, 24 h Pro, per session Network policy, up to deny-all Not in the plan limits
Cloudflare Sandbox Container, each instance in its own VM Nothing on the container; mounted object storage persists Sleeps after 10 min Not in the limits page Block, allow and intercept outbound HTTP Not in the limits page
Fly.io Sprites Firecracker microVM 100 GB disk; processes resume from a warm sleep, services relaunch from cold Pauses after about 30 s None Domain allow and deny rules, read-only from inside No

Sources for this table: [1][2][3][4][5][7][8][9][10][11][12][13][14][15][16][17][18][19][20][21][22]. Checked 2026-09-10.

A coding agent that keeps a project. Sprites and Daytona treat the disk as the product. A Daytona sandbox is 1 vCPU, 1 GB of RAM and 3 GiB of disk by default,[20] which Fly.io vs Daytona puts side by side with a Sprite. E2B gets there with pause, at about four seconds per gigabyte of RAM,[4] and also ships a Desktop sandbox, an Ubuntu environment with XFCE and VNC for agents that work a screen;[23] what pause costs over hours is the subject of Fly.io vs E2B.

A code-interpreter tool. Modal fits when the agent is one tool call in a Python pipeline already on Modal; Fly.io vs Modal covers what a userspace kernel means for untrusted code. Cloudflare Sandbox suits a Worker that runs a command and forgets it, and Fly.io vs Cloudflare covers where the state has to live instead. Inside a Vercel app, Vercel Sandbox keeps its filesystem across stops but not its processes, which Fly.io vs Vercel Sandbox walks through.

A model to train or serve. Modal takes a GPU reservation as a Sandbox parameter,[17] and Daytona sells GPU sandboxes with NVIDIA and AMD acceleration, up to eight each.[20] E2B says its sandboxes are CPU-only, with no GPU option in the SDKs, CLI or API.[21]

Open Source and Self-Hosted Agent Sandboxes

Not every agent runs on a hosted provider, and the local options fall into the same shapes.

A wrapper around bubblewrap is the lightest. Bubblewrap is the unprivileged user-namespace tool that Flatpak and rpm-ostree build on, and its README is blunt about the limits: it “is not a complete, ready-made sandbox with a specific security policy”, and “everything mounted into the sandbox can potentially be used to escalate privileges”.[24] It shares the host kernel, so it is containment rather than a boundary.

A local microVM is the heavier option. Docker Sandboxes run AI coding agents in isolated microVM sandboxes, each with its own Docker daemon, filesystem and network, driven by an sbx CLI you install and sign in to.[25]

Self-hosting a provider is possible with E2B, whose infrastructure repository is Apache-2.0 and deploys with Terraform on Google Cloud, with AWS in beta.[26] That is the route when the compliance boundary has to contain the sandbox host, at the cost of running a Firecracker fleet.

Agent Sandboxes on Fly.io

Fly.io offers both shapes on one substrate. A Sprite is the persistent computer: a Firecracker microVM with a 100 GB ext4 disk that keeps files and repositories indefinitely, pauses after about 30 seconds of inactivity and wakes on the next request. A warm wake resumes running processes in place; from a cold wake, supervised services relaunch onto the same disk, per the lifecycle docs.

Fly Machines are the stateless runner: the same microVMs on a REST API, starting in well under a second and stopping when the program exits. The architecture reference describes the boundary both share, and code an agent builds in a Sprite runs on Machines without a rewrite.

Egress on a Sprite is unrestricted by default and governed by domain allow and deny rules set through the API, never from inside, per the networking docs. Connectors route outside API calls through a gateway that holds the token, so no credential lands on the agent’s disk. The hand-built tour is at fly.io/run-agent-code.

Frequently Asked Questions

Which sandbox providers run a GPU inside the sandbox?

Modal and Daytona document GPU-backed sandboxes: a Modal Sandbox takes a GPU reservation as a creation parameter, and Daytona sells GPU sandboxes on NVIDIA and AMD hardware. E2B says its sandboxes are CPU-only. Fly.io Sprites do not attach a GPU either; GPU work runs on Fly GPU Machines that an agent in a Sprite calls over the network.

Can an AI agent run a browser or a desktop inside a sandbox?

Yes, on the providers that give the agent a full Linux machine. E2B ships a Desktop sandbox with an Ubuntu desktop and VNC for computer-use agents. A Fly.io Sprite is a full Linux computer with root, so a headless browser installs like any other package and its profile survives sleep.

How long can a sandbox session last?

It depends on the provider and the plan. E2B allows one hour of continuous runtime on its base plan and 24 hours on Pro, and pausing resets the window. Modal Sandboxes cap out at 24 hours. Vercel Sandbox caps a session at 45 minutes on Hobby and 24 hours on Pro, resetting on each resume. Daytona has no cap but stops a sandbox after 15 idle minutes. Fly.io Sprites have no session cap: they run while busy and sleep when not.

Is an allowed-folder flag or a chroot a sandbox?

No. Restricting an agent to a folder only limits the paths it means to touch; a symlink or a writable parent walks it straight back out, and a chroot does nothing about egress or kernel exposure. A sandbox is a separate kernel or machine with its own filesystem and network policy, which is what Fly.io draws around every Sprite.

Why do per-session sandboxes end up costing more than an always-on VM?

Because the billing shape rewards short bursts and punishes long, mostly idle sessions. A provider that meters every second a sandbox is alive, and charges to snapshot it, costs more than a small VM once an agent sits attached for hours waiting on a model. Fly.io Sprites bill compute while the Sprite is active and stop while it sleeps, keeping the filesystem.

Do you run the agent in a sandbox, or give the agent a sandbox?

Both, and the second is not optional. The code an agent writes and runs belongs in an isolated environment, because nobody reviewed it. Whether the agent process lives there too depends on where its credentials are. On Fly.io the usual pattern is the whole agent in a Sprite, with credentials brokered through Connectors so nothing long-lived sits on a disk the agent can read.

Sources

  1. ^ Modal, “Sandboxes”. modal.com/docs/guide/sandbox. Checked 2026-09-10.
  2. ^ Cloudflare, “Sandboxes”. developers.cloudflare.com/sandbox/concepts/sandboxes/. Checked 2026-09-10.
  3. ^ Daytona, “Persistence”. daytona.io/docs/en/persistence. Checked 2026-09-10.
  4. ^ E2B, “Sandbox persistence”. docs.e2b.dev/sandbox/persistence. Checked 2026-09-10.
  5. ^ Vercel, “Persistence”. vercel.com/docs/sandbox/concepts/persistent-sandboxes. Checked 2026-09-10.
  6. ^ E2B, “BYOC (Bring Your Own Cloud)”. docs.e2b.dev/byoc. Checked 2026-09-10.
  7. ^ E2B, “Is E2B SOC 2 compliant?”. docs.e2b.dev/faq/security-and-compliance. Checked 2026-09-10.
  8. ^ Vercel, “Vercel Sandbox”. vercel.com/docs/sandbox. Checked 2026-09-10.
  9. ^ Modal, “Security”. modal.com/docs/guide/security. Checked 2026-09-10.
  10. ^ Daytona, “Isolation”. daytona.io/docs/en/isolation. Checked 2026-09-10.
  11. ^ Cloudflare, “Sandbox SDK”. developers.cloudflare.com/sandbox/. Checked 2026-09-10.
  12. ^ Cloudflare, “Containers architecture”. developers.cloudflare.com/containers/platform-details/architecture/. Checked 2026-09-10.
  13. ^ Modal, “Sandbox snapshots”. modal.com/docs/guide/sandbox-snapshots. Checked 2026-09-10.
  14. ^ E2B, “Internet access”. docs.e2b.dev/sandbox/internet-access. Checked 2026-09-10.
  15. ^ Modal, “Sandbox networking”. modal.com/docs/guide/sandbox-networking. Checked 2026-09-10.
  16. ^ Daytona, “Network Limits”. daytona.io/docs/en/network-limits. Checked 2026-09-10.
  17. ^ Modal, “modal.Sandbox”. modal.com/docs/reference/modal.Sandbox. Checked 2026-09-10.
  18. ^ Vercel, “Vercel Sandbox pricing and quotas”. vercel.com/docs/sandbox/pricing. Checked 2026-09-10.
  19. ^ E2B, “Billing and limits”. docs.e2b.dev/billing. Checked 2026-09-10.
  20. ^ Daytona, “Sandboxes”. daytona.io/docs/en/sandboxes. Checked 2026-09-10.
  21. ^ E2B, “Does E2B support GPUs?”. docs.e2b.dev/faq/gpu-support. Checked 2026-09-10.
  22. ^ Cloudflare, “Sandbox limits”. developers.cloudflare.com/sandbox/platform/limits/. Checked 2026-09-10.
  23. ^ E2B, “Computer use”. docs.e2b.dev/use-cases/computer-use. Checked 2026-09-10.
  24. ^ bubblewrap, “README”. github.com/containers/bubblewrap. Checked 2026-09-10.
  25. ^ Docker, “Docker Sandboxes”. docs.docker.com/ai/sandboxes/. Checked 2026-09-10.
  26. ^ E2B, “E2B Infrastructure”. github.com/e2b-dev/infra. Checked 2026-09-10.