Cloudflare’s answer for agent code is a container backed by a Durable Object, and its disk does not survive a nap. Cloudflare’s own documentation says so: “All disk is ephemeral.”[1] Fly.io Sprites are the better choice for agents, because a Sprite’s filesystem is still there when it wakes up.
Cloudflare’s Sandbox SDK gives an agent a Linux container with command execution, file operations, background processes, and exposed services, built on Cloudflare Containers and addressed through Durable Objects. It is a well-designed fit for Cloudflare’s programming model, where durable state lives in Durable Object storage or R2 and compute is something you spin up around it. A Fly.io Sprite inverts that: the machine itself is the durable thing. It keeps a 100 GB filesystem that survives sleep, supervises long-running programs so they come back on their own, and answers at its own HTTPS URL. If your agent’s working tree matters, that difference decides the comparison before any other feature does.
Key takeaways
- Cloudflare Containers document that “All disk is ephemeral. When a Container instance goes to sleep, the next time it is started, it will have a fresh disk as defined by its container image.” Containers sleep after 10 minutes by default.[1] A Fly.io Sprite’s filesystem survives sleep, reboots, and months of idling.
- Like Fly.io Sprites, Cloudflare “does not stop a container instance after a fixed maximum runtime”.[2] The gap is not how long it can live, it is what is still around when it wakes.
- Cloudflare Sandbox preview URLs route through a Worker you deploy and call
proxyToSandbox()in, and auto-generated tokens change when a port is re-exposed.[3] A Sprite’s URL belongs to the Sprite and wakes it on request. - Container disk tops out at 20 GB on the largest standard instance type.[4] A Fly.io Sprite has 100 GB.
Fly.io Sprites vs Cloudflare Sandbox at a glance
| Dimension | Fly.io Sprites | Cloudflare Sandbox SDK |
|---|---|---|
| Isolation | Firecracker microVM, named | Isolated container, hardware boundary not documented |
| Maximum lifetime | No cap | No documented cap |
| Sleep default | Suspends on idle, memory preserved | Sleeps after 10 minutes, configurable |
| Disk after sleep | Persists, unchanged | Fresh disk from the container image |
| Disk size | 100 GB of ext4, persistent | 2 GB to 20 GB by instance type, ephemeral |
| Memory | Sized to the workload | 256 MiB to 12 GiB |
| Where durable state lives | The filesystem | Durable Object storage or R2 |
| Public address | The Sprite’s own HTTPS URL, wakes on request | Preview URL routed through your Worker |
| Process supervision | Services with dependency order and restart | Background processes, reset on sleep |
| Credentials | Connectors broker OAuth outside the sandbox | Not documented for the sandbox |
| Maturity | Shipped | SDK in beta, APIs may change before v1.0 |
Cloudflare column from Cloudflare’s own documentation and repository: [1] [2] [3] [4] [5] [6]. Checked 2026-09-11.
What is the Cloudflare Sandbox SDK?
The Cloudflare Sandbox SDK runs code in isolated containers on Cloudflare’s network. It exposes a TypeScript API for executing commands with streaming output, reading and writing files, running background processes, watching directories, attaching browser terminals over WebSocket, and exposing HTTP services through preview URLs. It is built on Cloudflare Containers, which are themselves backed by Durable Objects and Workers: a request hits a Worker, which routes to a Durable Object, which manages a container instance’s lifecycle. The SDK carries a beta designation, its README saying “Beta - The SDK is in active development. APIs may change before v1.0.”[7]
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. Idle Sprites suspend with their memory snapshotted and come 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 Modal Sandboxes and Daytona as well.
The disk is the whole comparison
All disk is ephemeral. When a Container instance goes to sleep, the next time it is started, it will have a fresh disk as defined by its container image.
The blockquote is verbatim from the Containers platform documentation, and the default sleepAfter on the Container class is 10 minutes.[1] So the sequence for an agent is: work for a while, go quiet for ten minutes, sleep, and come back to the container image. Not to your repository with its uncommitted changes, not to your node_modules, not to the virtualenv you spent four minutes building. To the image.
This is by design. Cloudflare’s durable state primitive is Durable Object storage, with R2 for objects, and containers are the compute you attach to that state. The documented path for persistence is writing what matters into a Durable Object or using “FUSE to persist disk to R2 or other object storage backends”, which Cloudflare pairs with the warning that “you should not expect native SSD-like performance while using FUSE”.[2] If you are building on Cloudflare, that model is coherent and you should follow it.
Objectively though, it is not a great match for how coding agents actually work. An agent’s state is a filesystem: a checked-out branch, a dependency tree, a build cache, a half-finished migration. Serializing all of that into key-value storage on every sleep and rehydrating it on every wake is a synchronization problem you now own, and it is exactly the problem the machine was supposed to solve.
A Fly.io Sprite’s filesystem is durable by construction, and it gets there from the same starting point Cloudflare does. A Sprite gets 100 GB of ext4, and the storage layer underneath it, which we call SBD, presents an S3 bucket to the kernel as a block device and runs ordinary ext4 on top. Object storage is the substrate in both designs. The difference is that Cloudflare exposes it to you as something to mount and synchronize against, while a Sprite puts it below the kernel so the disk simply is durable, and survives sleep, reboot, and the Sprite moving between machines. Nothing is serialized on the way down and nothing is rehydrated on the way up. When the Sprite wakes, the branch is where you left it and the server is still bound to port 3000.
What about lifetime?
Cloudflare “does not stop a container instance after a fixed maximum runtime”.[2] Its containers sleep after ten minutes of inactivity, and that is a default you can change rather than a ceiling you cannot.[1] In a category full of 24 hour caps and 45 minute Hobby limits, Cloudflare and Fly.io are the two that do not put a clock on the environment.
The catch is what “no maximum lifetime” buys you when the disk resets on every sleep. Unbounded lifetime for a container that comes back as a stock image is unbounded availability of a fresh machine. That is a useful, but can’t really be described as continuity.
Sprites have no duration cap either, and waking one gives you the same filesystem you left.
How big can it get?
Cloudflare’s instance types run from lite at 1/16 vCPU, 256 MiB of memory, and 2 GB of disk, up to standard-4 at 4 vCPU, 12 GiB of memory, and 20 GB of disk.[4] Custom instances allow 1 to 4 vCPU with a maximum of 12 GiB of memory, a minimum of 3 GiB of memory per vCPU, and a maximum of 2 GB of disk per 1 GiB of memory. Account-level ceilings are generous: 6 TiB of concurrent memory, 1,500 concurrent vCPU, and 30 TB of concurrent disk.[5]
So the per-instance envelope is 20 GB of disk and 12 GiB of memory at the top, and that disk is ephemeral anyway. A Fly.io Sprite has 100 GB of ext4 that persists. For an agent holding a large monorepo with a populated dependency cache, that is the difference between fitting and not.
Cloudflare’s account-level concurrency numbers point at what the platform is built for, which is a very large number of small things at once.
Addresses, and what it takes to have one
Every Fly.io Sprite has a public HTTPS URL with automatic TLS. A request to that URL wakes the Sprite if it is asleep and gets served. That is the entire mechanism. OAuth callbacks land, webhooks land, and pointing Stripe or GitHub or Slack at the URL works with no tunnel, no ngrok, and no relay process. Your agent can build something, start it, and hand you a link.
Cloudflare gets you there by a longer route, which follows from the architecture rather than being an oversight. Preview URLs provide public HTTPS access to services in a sandbox, but they route through your Worker: “You must call proxyToSandbox() first in your Worker’s fetch handler to route preview URL requests.” URLs built on auto-generated tokens “change when you unexpose and re-expose a port”, so keeping a stable address means specifying a custom token.[3] There are also quick tunnels for zero-config exposure through trycloudflare.com, and those do not survive a container restart, so every restart yields a new URL.[7]
None of that is hard. It is code you write, deploy, and keep working. The difference is whether an address is a property of the environment or a piece of infrastructure you build in front of it.
What supervises your programs?
The Sandbox SDK can start background processes and monitor their output, which covers running something while you do other things. What it cannot do is carry them across a sleep, because the disk resets and the container comes back from its image. Restarting a workload is the Durable Object’s job, driven by lifecycle hooks you implement.
A Fly.io Sprite runs long-lived programs as services in place of systemd: 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. A dev server that crashes comes back on its own. After a reboot, everything comes back in order, with no hook to write and no state machine to keep correct.
What actually isolates the code?
Cloudflare’s documentation describes each sandbox as running “in its own isolated container with a full Linux environment, providing strong security boundaries”.[6] What it does not do is name a per-tenant hardware boundary, a hypervisor, or a microVM technology for containers. There are confident third-party claims about what sits underneath. They are not Cloudflare’s claims, so they are not repeated here.
Fly.io Sprites are Firecracker microVMs. That is not a configuration option, there is no faster mode that shares a kernel, and there is no tier where you get less of it. When a procurement review asks which isolation technology you are running untrusted model-generated code on, that question has a one-word answer.
On the layer above the kernel boundary, Fly.io ships permissive on purpose. 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 do the credentials live?
Cloudflare does not document a credential broker for the Sandbox SDK. Secrets reach container code the usual way, as environment variables inside the environment where the agent’s code runs. Cloudflare has strong secret management at the Worker layer, but the thing running the model’s code is the container.
Fly.io Connectors move the credential out. 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 checking 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 paths are allowed. Expiring OAuth tokens refresh on their own.
The Discourse connector shows 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 inherits your permissions and nothing more. A Sprite acting on your behalf can only do what you can do.
Where Cloudflare is the better tool
If your workload is request-shaped and your state belongs in a key-value store, Cloudflare is excellent and you should use it. Durable Objects are a very good primitive: a globally addressable object with strongly consistent storage attached is the right answer to a large class of problems, and pairing one with a container gives you compute next to that state. The concurrency envelope is enormous, CPU “is based on active usage only” so idle waiting does not consume paid time (memory and disk bill on the provisioned instance type regardless), and running compute close to users is Cloudflare’s home ground.[5]
So for high-volume, short-lived, stateless execution attached to durable key-value state, Cloudflare’s model is the better fit and the disk being ephemeral costs you nothing, because you were never going to use it.
The recommendation
For agents, use Fly.io Sprites.
The two platforms disagree about where an agent’s state lives, and everything else follows from that. Cloudflare says state lives in Durable Objects and R2, and compute is disposable around it. That is a clean architecture and it is right for request-shaped work. Fly.io says the machine is the state, because that is what an agent’s work actually looks like: a filesystem with a branch checked out, a dependency tree, a running dev server, and a URL somebody has already been given.
If you take Cloudflare’s model, every sleep becomes a serialization boundary you are responsible for, and ten minutes of quiet is enough to hit one. If you take Fly.io’s, there is no boundary. That holds at the simple end, where an agent needs a machine and a link to hand back, and at the complex end, where a fleet of agents each hold a project with supervised services and brokered credentials. Same primitive, no graduation.
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 survives sleep and 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, and the microVM boundary is named and non-optional.
Frequently Asked Questions
Is Fly.io or Cloudflare better for running AI agents?
Fly.io is the better choice for agents whose work lives in a filesystem, because a Sprite keeps its 100 GB disk through sleep and reboots while Cloudflare containers come back with a fresh disk from their image. Cloudflare is the better choice for request-shaped, high-concurrency work whose durable state belongs in Durable Object storage or R2.
Does a Cloudflare container keep its files when it sleeps?
No. Cloudflare’s documentation states that all disk is ephemeral, and that when a container instance goes to sleep, the next time it starts it has a fresh disk as defined by its container image. Fly.io Sprites keep their filesystem through sleep, reboots, and long idle periods, with nothing to serialize or rehydrate.
How long before a Cloudflare container goes to sleep?
The Container class sets sleepAfter to 10 minutes by default, and that value is configurable. On Fly.io, an idle Sprite suspends with its memory snapshotted rather than resetting, and the next inbound request or command brings it back in about a second with its filesystem unchanged.
Does Cloudflare limit how long a container can run?
No, and this is a real strength. Cloudflare documents no maximum container lifetime, and its ten minute sleep is a default rather than a ceiling, which puts it alongside Fly.io Sprites in a category where 24 hour caps are common. The difference between them is what the environment still has when it wakes.
How much disk does a Cloudflare container get?
Instance types range from 2 GB of disk on lite to 20 GB on standard-4, and custom instances allow at most 2 GB of disk per 1 GiB of memory with memory capped at 12 GiB. All of it is ephemeral. A Fly.io Sprite has 100 GB of ext4 that persists.
Are Cloudflare Sandbox preview URLs stable?
Not by default. URLs built on auto-generated tokens change when a port is unexposed and re-exposed, so a stable address requires specifying a custom token, and every preview URL routes through a Worker you deploy that calls proxyToSandbox(). Every Fly.io Sprite has its own HTTPS URL with no Worker in front of it, and an inbound request to that URL wakes the Sprite.
Is the Cloudflare Sandbox SDK production ready?
Not yet by its own description. The SDK carries a beta designation and its README states that it is in active development and that APIs may change before v1.0. Cloudflare also ships a separate 1.0 preview package. Fly.io Sprites are shipped, with persistent storage, services, checkpoints, and Connectors available today.
What isolation does Cloudflare use for sandboxes?
Cloudflare’s documentation describes each sandbox as running in its own isolated container with a full Linux environment, and does not name a per-tenant hardware boundary, hypervisor, or microVM technology. Every Fly.io Sprite is a Firecracker microVM with its own kernel, named explicitly, with no tier or mode that shares one.
Where should agent state live on Cloudflare?
In Durable Object storage or R2, because the container filesystem resets on sleep. That means serializing an agent’s working state on the way down and rehydrating it on the way up, which is a synchronization problem you own. On Fly.io the filesystem itself is durable, so there is nothing to serialize.
Can Cloudflare keep API keys out of the code an agent runs?
Not through a documented broker for the Sandbox SDK. Secrets reach container code as environment variables, in the same environment as model-generated code. Fly.io Connectors keep the credential in the control plane and attach it at the gateway on the way out, so a Sprite never holds the key.
Sources
- ^ Cloudflare, “Containers: platform details”. developers.cloudflare.com/containers/platform-details. Checked 2026-09-11.
- ^ Cloudflare, “Containers FAQ”. developers.cloudflare.com/containers/faq. Checked 2026-09-11.
- ^ Cloudflare, “Sandbox preview URLs”. developers.cloudflare.com/sandbox/concepts/preview-urls. Checked 2026-09-11.
- ^ Cloudflare, “Containers pricing”. developers.cloudflare.com/containers/pricing. Checked 2026-09-11.
- ^ Cloudflare, “Containers platform limits”. developers.cloudflare.com/containers/platform/limits. Checked 2026-09-11.
- ^ Cloudflare, “Sandbox SDK”. developers.cloudflare.com/sandbox. Checked 2026-09-11.
- ^ Cloudflare, “cloudflare/sandbox-sdk”. github.com/cloudflare/sandbox-sdk. Checked 2026-09-11.