E2B has the best pause in this category: it preserves memory, keeps paused sandboxes indefinitely, and resumes in about a second.[1] Fly.io Sprites are still the better choice for agents, because a paused sandbox is not a running one, and a Sprite never has to stop in the first place.
E2B and Fly.io Sprites both run agent code inside Firecracker microVMs, so the isolation boundary is the same on both.[2] The difference is the lifecycle around it. E2B’s model is a cycle you drive: the sandbox runs, hits a continuous runtime limit, pauses (which costs roughly four seconds per gigabyte of RAM), and resumes when your code calls it.[1] Fly.io’s model has no cycle. A Sprite has no duration cap, suspends on its own when idle, wakes on an inbound HTTP request, and supervises long-running programs so they come back after a crash or a reboot without anything restarting them by hand.
Key takeaways
- E2B caps continuous runtime at 24 hours on Pro and 1 hour on Hobby.[3] The limit resets on each pause and resume, so total lifetime is unbounded, but the platform decides when your processes stop. Fly.io Sprites have no duration cap.
- Pausing an E2B sandbox costs about four seconds per gigabyte of RAM, so a 16 GB environment takes roughly a minute to put down.[1] A Fly.io Sprite suspends on idle with no equivalent tax on your critical path.
- E2B’s default timeout behavior is to kill the sandbox. Preserving it requires opting into the pause lifecycle.[1] On Fly.io, persistence is not a setting.
- E2B does not document a credential broker, so keys reach agent code as environment variables inside the sandbox, and its documentation notes they are not private in the OS.[5] Fly.io Connectors keep the credential in the control plane and the Sprite never holds it.
Fly.io Sprites vs E2B at a glance
| Dimension | Fly.io Sprites | E2B |
|---|---|---|
| Isolation | Firecracker microVM | Firecracker microVM |
| Continuous runtime cap | None | 24 hours Pro, 1 hour Hobby, resets on pause |
| Default on timeout | Suspends and stays | Kills the sandbox unless you opt into pause |
| Cost of stopping | Suspend on idle, off your critical path | About 4 seconds per GiB of RAM |
| Time to come back | About 1 second | About 1 second |
| Memory preserved | Yes, on suspend | Yes, on pause, unless you disable it |
| Retention when stopped | 100 GB of ext4, does not expire | Paused sandboxes retained indefinitely |
| What wakes it | An inbound HTTP request, or any command | An SDK connect call |
| Process supervision | Services with dependency order and restart | Not provided |
| Credentials | Connectors broker OAuth outside the Sprite | Environment variables inside the sandbox |
E2B column from E2B’s own documentation: [1] [2] [3] [4] [5]. Checked 2026-09-11.
What is E2B?
E2B is an open-source infrastructure company whose sandboxes are the most widely adopted primitive for running LLM-generated code. Each sandbox is a Firecracker microVM,[2] and the SDK is built around a code-interpreter workflow: start a sandbox, execute Python or JavaScript, get structured results back including charts and files. E2B’s persistence feature pauses a sandbox and later resumes it from the same state, preserving not just the filesystem but the memory, so running processes and loaded variables come back as they were.[1]
What are Fly.io Sprites?
A Fly.io Sprite is a persistent Linux computer for an agent, running as a Firecracker microVM. It keeps 100 GB of ext4 that does not expire, answers at its own HTTPS URL with automatic TLS, and supervises long-lived programs as services with dependency ordering and automatic restart. When a Sprite goes idle it suspends with RAM snapshotted, and it comes back in about a second. Claude Code, Cursor CLI, Gemini CLI, and Codex CLI ship preinstalled, alongside Node, Python, Go, Ruby, Rust, Java, and Elixir. There is no duration cap. Fly.io has compared Sprites with Daytona and Cloudflare’s Sandbox SDK as well.
What does E2B’s pause actually cost?
Credit where it is due first: E2B’s pause is the best implementation of this approach in the category. It preserves the filesystem and the memory, so all running processes, loaded variables, and in-flight data are restored. Paused sandboxes are retained indefinitely with no automatic time-to-live, so nothing expires out from under you while you are not looking. Resuming takes about a second.[1] If you are going to build a product around suspending environments, this is the version to want.
The cost is on the way down. Pausing takes roughly four seconds per gigabyte of RAM. A 4 GB sandbox is about sixteen seconds. A 16 GB environment is around a minute. That is a real number that sits in your latency budget every time you put an environment away, and it scales with exactly the thing that makes a development environment useful, which is memory.
There is also a default worth checking before you rely on any of this. E2B’s default timeout behavior is to kill the sandbox, not to pause it. Preserving state on timeout means setting the lifecycle parameter to pause.[1] If nobody set it, the sandbox and everything in it goes away when the timer runs out.
A Fly.io Sprite has no equivalent decision to get right. Its 100 GB of ext4 is persistent on its own: the storage layer underneath, which we call SBD, presents an S3 bucket to the kernel as a block device and runs ordinary ext4 on top, so durability is a property of the disk rather than an event you trigger. It suspends when it goes idle and its memory is snapshotted and restored, so it picks up mid-thought. The storage flush happens as a background write-back rather than as a stop-the-world copy of RAM, so putting a Sprite away is not a thing you wait for. Nothing about persistence is a parameter you can forget to pass.
What about the runtime limit?
E2B caps continuous runtime at 24 hours on Pro and 1 hour on Hobby.[3] As with several platforms in this category, Vercel Sandbox among them, that limit resets every time you pause and resume, so the total lifetime of a sandbox is effectively unbounded.
The platform decides when your processes stop, on its schedule rather than yours, and you pay the pause tax at each boundary. For an hour-long Hobby ceiling with a multi-gigabyte environment, that arithmetic gets uncomfortable quickly.
Sprites have no continuous runtime limit of any kind. There is no cycle, no boundary, and no tax, because the environment is not designed around being put down and picked back up.
A paused sandbox is not a running one
This is the part the pause-quality argument tends to skip over. E2B restores your processes beautifully. It restores them when you ask. While the sandbox is paused, nothing in it is running: nothing is serving a request, nothing is polling a queue, nothing is reconnecting a dropped database handle, and nothing is answering the webhook that just fired.
An asleep Sprite behaves differently in one specific way that changes what you can build. The Sprite has a public HTTPS URL with automatic TLS, and a request to that URL wakes it and gets served. The request is the wake trigger. That means OAuth callbacks land, webhooks land, and you can point Stripe or GitHub or Slack at the URL with no tunnel, no ngrok, and no relay process holding a connection open on the sandbox’s behalf. Your agent can build something, start it, and hand you a link that still works next Thursday.
E2B does give a running sandbox a public URL per port, in the form https://<port>-<sandbox-id>.e2b.app, public by default with optional authentication.[4] That covers reaching a sandbox that is currently up. What the documentation does not describe is a request to that URL resuming a paused sandbox, so the documented route back is an SDK connect call from your own code. Something you run has to notice and wake it.
What keeps your processes alive between crashes?
Neither pause quality nor wake latency helps when a process simply dies. E2B restores what was running at the moment you paused. It does not supervise those processes while the sandbox is up, so a dev server that segfaults at 3am is a dev server that is down until something notices.
In place of systemd, a Fly.io Sprite runs services: long-lived processes with dependency ordering, automatic restart on crash backing off from one second to sixty, persisted to disk and relaunched on boot. One service can claim the HTTP port, and that is the one the public proxy routes to. If a program crashes, it comes back. If the Sprite reboots, everything comes back in dependency order. That is a different guarantee from state restoration, and for anything long-lived it is the one that decides whether you get paged.
Where do the credentials live?
E2B does not document a credential broker. Keys reach the code the way they do on most of this category: as environment variables inside the sandbox, in the same process space as code a language model wrote. E2B sets them at creation or per command and notes they are “not private in the OS”.[5] The security boundary for the credential is that the model chooses not to print it.
Fly.io Connectors move the credential out of the environment entirely. You connect GitHub, Slack, OpenRouter, Discourse, or any HTTP API through a real OAuth flow, and the credential lives in the Fly.io control plane. The Sprite never holds it. The gateway attaches it to each outbound request, and every request to a customer-chosen host passes an SSRF guard that checks self-targeting along with private and link-local addresses before anything leaves. Connectors are default-deny: you grant access to specific Sprites by label or name prefix and scope which request paths are allowed, so a Connector can permit posting a Slack message and refuse everything else. Expiring OAuth tokens refresh on their own.
The Discourse connector is the clearest illustration of the difference between injecting a key and brokering an identity. It uses Discourse’s User API Key flow, so you approve the connection on your own forum and the credential that comes back inherits your permissions and nothing more. A Sprite acting on your behalf can only do what you can do, because it was never issued more than that.
Isolation
Both E2B and Fly.io Sprites run Firecracker microVMs.[2] Both give you a per-tenant hardware boundary with a dedicated kernel rather than a shared kernel with syscall filtering; Modal Sandboxes sit on the other side of that line by default. If hardware isolation is your requirement, both platforms meet it and the decision is made on other grounds.
On the policy layer above that boundary, Fly.io ships permissive: network egress from a Sprite is unrestricted until you apply a policy from outside it. Once a policy is in force, only allowlisted domains resolve, and code inside the Sprite can read the policy but has no route to widen it, because the setter is not reachable from inside.
Where E2B is the better tool
Code interpreters. If what you are building is “the model writes Python, we run it, we hand back the output and the charts,” E2B’s SDK is purpose-built for exactly that, it is mature, it is widely adopted, and its structured result handling for plots and files will save you real work. That is the use case E2B was designed around and it does it better than a general-purpose computer would.
The recommendation
For agents that need to persist, use Fly.io Sprites.
E2B built the best version of the pause-and-resume model, and that is the honest framing of the choice. The question is whether pause and resume is what you want at all. It is the right primitive for a sandbox: a bounded piece of work, started by your code, ended by your code, put away between runs. It is the wrong primitive for a computer, because a computer’s defining property is that it keeps existing while you are not thinking about it.
That is what a Sprite gives you at every point on the range. At the simple end, an agent needs somewhere to run and a link to hand back, and that is one Sprite with nothing configured. At the complex end, a fleet of agents each own a long-lived project with supervised services, brokered credentials, and addresses that webhooks can hit, and it is still one Sprite each. There is no pause tax, no runtime ceiling, no lifecycle parameter you have to remember, and no orchestrator whose job is waking things up.
Running agents on Fly.io
A Sprite is a persistent, hardware-isolated Linux computer with a public address. You get 100 GB of storage that does not expire, checkpoints for rolling back to a known state, services that supervise your long-running programs and bring them back after a crash or a reboot, and Connectors that let an agent authenticate to GitHub, Slack, or any HTTP API without the credential ever entering the environment. Coding agents come preinstalled. There is no runtime cap, and the microVM boundary is the floor rather than an upgrade.
Frequently Asked Questions
Is Fly.io or E2B better for AI agents?
Fly.io is the better choice for agents that need to persist between sessions. Fly.io Sprites have no runtime cap, wake on an inbound HTTP request, supervise long-running processes, and keep credentials outside the environment. E2B is the better choice for code-interpreter workloads, where an LLM writes Python, the sandbox runs it, and structured output comes back.
How long does it take to pause an E2B sandbox?
Pausing takes roughly four seconds per gigabyte of RAM, so a 16 GB environment takes around a minute to put down, while resuming takes about a second. A Fly.io Sprite suspends when it goes idle without that cost sitting in your critical path, and comes back in about a second with its memory intact.
Does E2B have a time limit on sandboxes?
Yes. E2B caps continuous runtime at 24 hours on Pro and 1 hour on Hobby, though the limit resets every time you pause and resume, so total lifetime is unbounded. Fly.io Sprites have no duration cap at all, so there is no boundary to design around and no pause to pay for at each one.
Do E2B sandboxes keep running processes when paused?
Yes. E2B’s pause preserves memory as well as the filesystem, so running processes, loaded variables, and in-flight data come back on resume. The distinction on Fly.io is that a suspended Sprite also wakes on an inbound HTTP request and supervises its services, so processes restart on their own after a crash rather than only being restored from a snapshot.
How long does E2B keep a paused sandbox?
Paused E2B sandboxes are retained indefinitely with no automatic time-to-live, and they persist until you explicitly kill them. Fly.io is comparable here: a Sprite’s filesystem does not expire and its checkpoints do not expire either, so neither platform puts a countdown on your stored work.
Does E2B kill sandboxes by default?
Yes. E2B’s default timeout behavior kills the sandbox, and preserving state requires opting into the pause lifecycle explicitly. On Fly.io there is no equivalent setting to miss, because a Sprite persists without being told to and suspends rather than terminating when it goes idle.
Can an E2B sandbox be woken by an HTTP request?
Not according to E2B’s documentation, which describes a public URL per port for a sandbox that is currently running and an SDK connect call as the way to resume a paused one. Every Fly.io Sprite wakes on the inbound request itself, which is what lets webhooks and OAuth callbacks reach an agent that has been asleep.
Is E2B hardware isolated like Fly.io?
Yes. E2B runs Firecracker microVMs, the same isolation model Fly.io Sprites use, so both give each tenant a dedicated kernel rather than a shared one. Isolation is a tie between these two platforms, which means the decision comes down to runtime limits, supervision, wake behavior, and credential handling.
How do API keys reach code running in an E2B sandbox?
They are passed as environment variables inside the sandbox, because E2B does not document a credential broker. On Fly.io, Connectors keep the credential in the control plane and attach it at the gateway on the way out, so the Sprite never holds the key and agent-written code cannot read or leak it.
Does E2B restart a crashed process automatically?
No. E2B restores the processes that were running when you paused, but does not supervise them while the sandbox is up, so a process that dies stays dead until something notices. A Fly.io Sprite runs long-lived programs as services with automatic restart backing off from one second to sixty, and relaunches them on boot.
Sources
- ^ E2B, “Sandbox persistence”. docs.e2b.dev/sandbox/persistence. Checked 2026-09-11.
- ^ E2B, “e2b-dev/infra”. github.com/e2b-dev/infra. Checked 2026-09-11.
- ^ E2B, “Pricing”. e2b.dev/pricing. Checked 2026-09-11.
- ^ E2B, “Sandbox public URL”. docs.e2b.dev/network/public-url. Checked 2026-09-11.
- ^ E2B, “Environment variables”. docs.e2b.dev/sandbox/environment-variables. Checked 2026-09-11.