Fly.io vs Daytona: Lifecycle Timers, Disk Limits, and Isolation Compared

Daytona and Fly.io Sprites both give an agent an isolated Linux environment with a filesystem, snapshots, and a preview URL. They differ on what happens when you stop paying attention. A Daytona sandbox auto-stops after 15 minutes of inactivity by default, then auto-archives into object storage after 7 days stopped,^[1] and its default disk is 3 GiB.^[2] A Fly.io Sprite suspends when idle, keeps a 100 GB filesystem that does not expire, supervises long-running programs so they come back on their own, and has no lifecycle timers at all.

Fly.io Sprites vs Daytona at a glance

Daytona column from Daytona’s own documentation and site: ^{[1] [2] [3] [4] [5] [6] [7] [8]}. Checked 2026-09-11.

What is Daytona?

Daytona is an infrastructure platform for running AI-generated code, built around fast sandbox creation. It keeps warm pools so sandboxes start in milliseconds, advertising sub-90ms creation,^[7] and supports declarative images. Snapshots are “persistent, point-in-time captures of sandbox state, including the filesystem, installed packages, dependencies, and settings”, so you can configure an environment once and spawn any number of sandboxes from it, though capturing one from a running sandbox is still an _experimental_ SDK call.^[9] Inbound traffic reaches a sandbox through preview URLs or SSH, and those are authenticated by default, requiring a preview token or a signed URL unless the sandbox is explicitly made public.^[8]

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 and no archival timer. Fly.io has compared Sprites with Modal Sandboxes and Cloudflare’s Sandbox SDK as well.

The three timers

Daytona’s lifecycle is governed by three intervals:^[1]

• Auto-stop, default 15 minutes of inactivity, configurable per sandbox.
• Auto-archive, default 7 days after the sandbox stops, with 30 days the maximum interval. Archiving moves the filesystem to object storage to free disk quota on the runner, and the sandbox can be started again with its filesystem restored.
• Auto-delete, disabled by default.

These are set through the SDKs and the CLI, and none of them are unreasonable defaults for the workload Daytona was designed around. What they add up to is a posture: the environment is winding down unless you tell it not to. Fifteen minutes of an agent thinking rather than executing is enough to trip the first one, and a week of a project sitting idle between sprints is enough to trip the second.

A Fly.io Sprite has none of these. It suspends when it goes idle, which is a cost optimization rather than a lifecycle stage, and the next request or command brings it back in about a second with its memory intact. There is nothing to archive out of, nothing that gets slower the longer you leave it, and no interval to reset.

How much disk do you actually get?

Daytona sandboxes have 1 vCPU, 1 GB RAM, and 3 GiB of disk by default.^[2] Above that sits an organization-wide pool shared by every running sandbox, 10 vCPUs, 20 GiB of RAM and 30 GiB of storage on the first tier, rising with account verification and spend.^[3] For running a generated script, that is correctly sized and there is no reason to provision more.

For an agent that owns a repository, it is tight. A node_modules tree, a Python virtualenv with a couple of ML libraries, a Docker layer cache, and a build output directory will make 3 GiB feel small quickly. Raising it is a per-sandbox setting, but it draws on the same pool every other running sandbox draws on, so disk per agent and number of concurrent agents trade against each other.

A Fly.io Sprite gets 100 GB of ext4. 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, so it is a real disk rather than a volume you attach or a cache you hope survives, and checkpoints on it are block-level snapshots with copy-on-write clones. It is the difference between an environment sized for a task and an environment sized for a project.

What provides the isolation?

Daytona’s documentation describes sandboxes as isolated by default, with each one getting its own processes, network, filesystem mounts, and inter-process communication, and resource limits enforced as hard limits through cgroups.^[4] It distinguishes container sandboxes, which use dedicated namespaces, from VM sandboxes, which it describes as a full virtual machine with its own kernel behind a hardware virtualization boundary. Code in one sandbox cannot read another’s filesystem or memory, and sandboxes do not share a network.

There is no hypervisor named in the docs, no microVM framework named, and no statement about which mode you get by default. That matters when the question you are actually asking is “what am I comfortable running in here,” because the answer depends on whether the boundary is a kernel you share or one you do not, and on which of the two you get without asking.

Fly.io Sprites are Firecracker microVMs. That is not a configuration option, there is no faster mode that quietly shares a kernel, and there is no tier where you get less of it. You can go read what Firecracker is and decide for yourself whether it clears your bar, which is the point of naming it.

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. Daytona ships a per-sandbox firewall too, with three mutually exclusive settings: block all traffic, allow specific CIDR ranges, or allow specific domains.^[4]

Addresses and who does the waking

Daytona gives sandboxes preview URLs, and they are authenticated by default: a preview token or a signed URL is required unless the sandbox has its public property set to true.^[8] That is a better security default than public-by-default, and plenty of this category gets it the other way around.

The question a preview URL does not answer is what happens when the sandbox has auto-stopped. Reaching it means starting it, and starting it is something your code does through the SDK, as it is on E2B and Vercel Sandbox. The URL identifies a sandbox. It is not, by itself, the thing that brings the sandbox back.

Every Fly.io Sprite has a public HTTPS URL with automatic TLS, and a request to that URL wakes the Sprite if it is asleep and gets served. The request is the wake trigger. That is what makes OAuth callbacks land, webhooks land, and pointing Stripe or GitHub or Slack at the URL work with no tunnel and no relay process. Your agent can build a thing, start it, and hand you a link that will still answer next week, whether or not anything else is watching.

What restarts your programs?

Daytona does not document a process supervisor. It runs commands and background sessions and streams their logs, but nothing is watching a process you started to notice when it dies.^[6]

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. A dev server that crashes comes back. A queue worker that gets OOM-killed comes back. After a reboot, everything comes back in dependency order without an orchestrator replaying setup steps.

Where do the credentials live?

Both platforms have done the real work here. Most of this category, E2B and Modal Sandboxes included, still tells you to put the API key in an environment variable inside the sandbox and hope the model does not print it. Daytona does not.

A Daytona secret is stored outside the sandbox, and the environment variable inside holds an opaque placeholder rather than the value. When the sandbox makes an outbound HTTPS request whose header carries the placeholder and whose destination host is on that secret’s allowlist, a proxy substitutes the decrypted value before the request reaches its destination. The plaintext is never present inside the sandbox, and a request to a host that is not allowlisted carries the harmless placeholder.^[5]

Fly.io Connectors are the same shape and go one step further down. 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, so a Connector can permit posting a Slack message and refuse everything else. Expiring OAuth tokens refresh on their own.

The distinction worth the words is between substituting a secret and brokering an identity. The Discourse connector 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. Swapping in a placeholder keeps the secret out of the sandbox, which handles theft. Brokering a scoped identity also bounds the damage when the request is perfectly legitimate and the agent is simply wrong about what it should be doing.

Where Daytona is the better tool

Start latency and fan-out. Daytona keeps warm pools and advertises sub-90ms sandbox creation,^[7] where a Sprite takes about a second to come back from suspend. If your workload wakes an environment constantly and does a small amount of work each time, that difference compounds and Daytona is better at it. The snapshot pattern makes fan-out clean: configure once, snapshot, then spawn a hundred sandboxes from the same known state.

Daytona will also sell you GPUs, which Sprites do not have.^[7] If your agent needs to train or serve a model in the same environment it writes code in, that rules Sprites out and you should take the GPU.

Anyone telling you a second is indistinguishable from milliseconds is selling something. The honest version is that it matters when the tax compounds, and it stops mattering when the agent wakes up and then works for twenty minutes.

The recommendation

For agents that own a project rather than run a task, use Fly.io Sprites.

The difference is what the platform assumes you are doing. Daytona assumes you are running code: start fast, do the work, wind down, archive what is left. Every default follows from that, and for that job the defaults are right. Fly.io assumes the agent has somewhere to be: the disk is project-sized, the processes are supervised, the address answers, and nothing counts down.

That assumption holds at both ends of the range. The simplest case is one agent that needs a machine and a link to hand you when it is done, which is one Sprite with nothing configured, no timers to set to 0 and no snapshot to fork from. The most complex case is a fleet of long-lived agents each holding a repository, each with supervised services and brokered credentials, and it is still one Sprite each. You do not change primitives on the way 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, the microVM boundary is named and non-optional, and nothing is on a timer.

Frequently Asked Questions

Is Fly.io or Daytona better for AI agents?

Fly.io is the better choice for agents that own a project over time, because Sprites have no lifecycle timers, a 100 GB filesystem, supervised processes, and a URL that wakes them on request. Daytona is the better choice when start latency dominates, because its warm pools start sandboxes in milliseconds, and when the agent needs GPUs.

Does Daytona stop sandboxes automatically?

Yes. Daytona sandboxes auto-stop after 15 minutes of inactivity by default, and the interval is configurable. A Fly.io Sprite suspends on idle instead of stopping, keeps its memory, stays addressable at its URL, and comes back in about a second when a request arrives.

What is Daytona’s auto-archive, and does Fly.io have one?

Daytona auto-archives a stopped sandbox after 7 days by default, up to a maximum interval of 30 days, moving its filesystem to object storage to free disk quota on the runner so it can be started again later with that filesystem restored. Fly.io has no equivalent, because a Sprite’s filesystem does not expire and does not get slower the longer it sits.

How much disk does a Daytona sandbox have?

Daytona sandboxes get 3 GiB of disk by default, with 1 vCPU and 1 GB of RAM, and an organization on the first tier shares 10 vCPUs, 20 GiB of RAM and 30 GiB of storage across every running sandbox. A Fly.io Sprite has 100 GB of ext4, which is the difference between an environment sized for a task and one sized for a repository.

What isolation technology does Daytona use?

Daytona’s documentation describes container sandboxes using dedicated namespaces and VM sandboxes with their own kernel behind a hardware virtualization boundary, but does not name the hypervisor or microVM technology, and does not say which you get by default. Every Fly.io Sprite is a Firecracker microVM, named explicitly, with no mode or tier that shares a kernel.

Are Daytona preview URLs public?

No, not by default. Daytona preview URLs require a preview token or a signed URL unless the sandbox is explicitly made public, which is a stronger default than most of this category. The difference on Fly.io is behavioral rather than about authentication: an inbound request to a Sprite’s URL wakes it, so webhooks and OAuth callbacks reach an agent that has been asleep.

Does Daytona restart a crashed process?

No. Daytona does not document a process supervisor, so a program that dies inside a sandbox stays dead until something notices. A Fly.io Sprite runs long-lived programs as services with dependency ordering and automatic restart backing off from one second to sixty, and relaunches them on boot.

Is Daytona faster to start than Fly.io Sprites?

Yes. Daytona keeps warm pools and starts sandboxes in milliseconds, while a Fly.io Sprite takes about a second to come back from suspend. That gap matters for workloads that wake an environment constantly and do a small amount of work each time, and stops mattering when the agent wakes up and then works for twenty minutes.

How do API keys reach code running in a Daytona sandbox?

Not in plaintext. Daytona sets the environment variable to an opaque placeholder and a proxy substitutes the real secret on outbound requests to allowlisted hosts, so the value never enters the sandbox. Fly.io Connectors keep the credential in the control plane and attach it at the gateway the same way, and add an OAuth identity, so the credential a Sprite acts with carries your scopes rather than being a static key.

Can I get GPUs on Fly.io Sprites?

No. Sprites are not a GPU environment, and Daytona will sell you GPUs, so if an agent has to train or serve a model in the same place it writes code, Daytona handles that and Sprites do not. Fly.io sells GPU Machines as a separate product, which is a different shape of thing from an agent’s persistent computer.

Sources

1. ^ Daytona, “Persistence”. daytona.io/docs/en/persistence. Checked 2026-09-11.
2. ^ Daytona, “Sandboxes”. daytona.io/docs/en/sandboxes. Checked 2026-09-11.
3. ^ Daytona, “Limits”. daytona.io/docs/en/limits. Checked 2026-09-11.
4. ^ Daytona, “Isolation”. daytona.io/docs/en/isolation. Checked 2026-09-11.
5. ^ Daytona, “Secrets”. daytona.io/docs/en/secrets. Checked 2026-09-11.
6. ^ Daytona, “Process and code execution”. daytona.io/docs/en/process-code-execution. Checked 2026-09-11.
7. ^ Daytona, “Daytona: the infrastructure layer for AI agents”. daytona.io. Checked 2026-09-11.
8. ^ Daytona, “Preview and authentication”. daytona.io/docs/en/preview. Checked 2026-09-11.
9. ^ Daytona, “Snapshots”. daytona.io/docs/en/snapshots. Checked 2026-09-11.