Fly.io vs Vercel Sandbox: Persistence, Sessions, and Credentials Compared

Vercel Sandbox and Fly.io Sprites both run untrusted, agent-generated code inside a Firecracker microVM with a dedicated kernel,^[1] both give you root, both persist state by default, and both keep credentials out of the environment through a proxy. On the surface they look like the same product. The divergence is what “resume” means. A Vercel sandbox resumes by booting a new session from a filesystem snapshot, so your files come back and your processes do not.^[2] A Fly.io Sprite resumes by waking the same machine, with RAM restored and supervised services already running. One is a very good sandbox. The other is a computer.

Fly.io Sprites vs Vercel Sandbox at a glance

Vercel column from Vercel’s own documentation: ^{[1] [2] [3] [4] [5]}. Checked 2026-09-11.

What is Vercel Sandbox?

Vercel Sandbox is Vercel’s compute primitive for running untrusted or agent-generated code. Each sandbox is a Firecracker microVM with its own kernel, booted from a managed image (the default carries Node LTS, Python, and coding agents) or a custom OCI image from Vercel Container Registry.^[1] You get root, so container runtimes, VPN clients, and FUSE drivers all work. Sandboxes are persistent by default since v2 of the SDK: stopping one snapshots its filesystem, and the next SDK call boots a new session from that snapshot. Vercel is direct about the intended shape, stating in its own documentation that sandboxes “are not designed to run continuously” and are not suitable for permanent hosting.^[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. 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 checkpoints for rolling back to a known state do not expire. Fly.io has compared Sprites with Daytona and Cloudflare’s Sandbox SDK as well.

Do running processes survive?

Vercel’s persistence model works like this: when a session stops, “Vercel captures its filesystem and creates a snapshot automatically before the sandbox shuts down,” and the next session starts from that snapshot.^[2] The word doing the work there is filesystem. A snapshot is your disk. It is not your memory, and it is not your process table. So when a Vercel sandbox resumes, node server.js is not running. Your dev server is a file again. Vercel’s answer to this is the onResume lifecycle hook, which “runs every time a session is resumed” so you can restart background services and rehydrate caches by hand.^[2] That hook exists precisely because the platform hands you back a cold machine.

A Fly.io Sprite handles this two ways at once. When it goes idle it suspends, and suspending snapshots RAM, so the Sprite picks up mid-thought when something touches it. And underneath that, in place of systemd, a 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. Your dev server is supervised. Your queue worker is supervised. If the Sprite reboots outright, they come back on their own, because they are registered services and not something a hook has to remember to start.

The practical difference is who writes the recovery logic. On Vercel, you do, in onResume, for every process you care about, and you keep that hook correct as the environment grows. On Fly.io, you register a service once.

What are the session caps, and do they matter?

Vercel’s numbers: the default sandbox timeout is 5 minutes, extendable with extendTimeout(), and the maximum session duration is 24 hours on Pro and Enterprise and 45 minutes on Hobby.^[3] Crucially, that maximum applies to a session, not to the sandbox. Because the cap resets every time a sandbox stops and resumes, the total lifetime of a persistent sandbox is, as Vercel puts it, effectively unbounded.

So Vercel never permanently kills your sandbox at the cap, but it does decides when your current session ends, and every session boundary is a cold boot of everything that was running. Unbounded lifetime for the sandbox, hard ceiling for the processes.

Fly.io Sprites have no duration cap of any kind. There is no session boundary to design around, because there are no sessions. A Sprite that has been running for a month is the same Sprite, with the same processes, at the same address.

How does each one wake up?

A stopped Vercel sandbox resumes when you call an SDK method on it. Calling runCommand, writeFiles, or most other methods on a stopped persistent sandbox starts a new session and retries the operation automatically, and Sandbox.get({ name }) returns a handle that resumes on the next call needing a running VM. Two methods deliberately do not auto-resume: stop() and update().^[2] What Vercel’s documentation does not describe is an inbound HTTP request to an exposed port bringing a stopped sandbox back. The wake trigger it documents is your code calling the SDK.

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. That is the dividing line between a computer and a job. It means OAuth callbacks land, webhooks land, and pointing Stripe or GitHub or Slack at the URL just works, with no tunnel, no relay process babysitting a connection, and no orchestrator whose job is to notice traffic and call an SDK to wake something up. Your agent can build a thing, start it, and hand you a link that will still be alive on Thursday.

Vercel does give you real addresses. A sandbox can expose up to 15 ports on every plan, each reachable at a public URL, and for a named sandbox that URL keeps pointing at the current session across resumes.^[3] The gap is not the URL. It is who does the waking.

How much state management do you have to do?

On Vercel, persistence is real but it comes with a retention system you own:

• Each sandbox gets 64 GB of ephemeral NVMe on every plan. Durable state lives in snapshots, or in Drives, which are in beta.^[3]
• Snapshots expire 30 days after their last use by default. The timer resets each time a snapshot is used, and you can set the expiration to none to keep them indefinitely.^[4]
• keepLastSnapshots bounds how many a sandbox retains, between 1 and 10, because a persistent sandbox writes a snapshot every time a session stops. Vercel recommends count: 1, which “keeps snapshot storage flat”.^[2]
• Snapshot storage is billed separately from compute, at $0.08 per GB-month.^[3]
• Snapshots are stored in the region of the sandbox that created them and “can’t be moved between regions”, so creating from one elsewhere fails with a snapshot_region_mismatch error.^[4]
• Vercel removes sandboxes that cannot resume from a snapshot after 14 days of inactivity.^[2]

None of those are bad decisions. Together they are a policy surface: expirations, counts, eviction, storage cost, and a portability constraint, all of which have to stay correct for your environment to still exist next month.

A Sprite gets 100 GB of ext4, and it does not expire. 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 there is no metadata database to keep consistent. Checkpoints sit on top as deliberate save points, taken by hand or automatically after an hour of continuous activity, on idle, and at graceful shutdown, with tiered retention handled for you. They do not rot. There is no snapshot lifecycle to get right, because there is no snapshot standing between your files and their continued existence.

Where do 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. Vercel does not.

Vercel’s sandbox firewall runs outside the sandbox boundary. The default policy is allow-all, and you can switch to deny-all or a user-defined policy that denies by default and allows named domains. On an allowed domain you can attach a transform rule, which terminates TLS and injects credentials into the request in transit, so in Vercel’s words “the secrets never enter the sandbox”. Denied CIDR ranges take precedence over allowed domains and address ranges. There is also forwardURL for routing traffic through a proxy you control, with a Vercel-issued OIDC token carrying the team, project, and sandbox identifiers.^[5] It is a well-built system and the precedence choices are correct.

It also has edges that Vercel documents plainly. Domain matching reads the hostname from the TLS SNI, so code inside the sandbox can present an allowlisted SNI while sending a different Host header, a technique Vercel names as domain fronting, and “the firewall does not prevent the mismatch by default”. Traffic allowed by subnets.allow “bypasses SNI filtering, credentials brokering, and requests proxying”. A policy with allowed address ranges and no allowed domains “can resolve any hostname”, which is a data path.^[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. The credential lives in the Fly.io control plane and the Sprite never holds it. The gateway attaches it on the way out, and every request to a customer-chosen host passes an SSRF guard checking self-targeting along with private and link-local addresses. Connectors are default-deny: you grant access to specific Sprites by label or name prefix and scope the allowed request paths, 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 injecting a key 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. Injecting a header 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, which is the more common failure.

Where Vercel Sandbox is the better tool

If your application already lives on Vercel, the integration is an advantage. Authentication happens through Vercel OIDC tokens with no key management in production, sandboxes fit naturally alongside Vercel Functions and AI Gateway, and the whole thing is one billing relationship and one dashboard.

Vercel is also the stronger fit for high-burst, one-shot execution. Pro and Enterprise allow 10,000 concurrent sandboxes with vCPU allocation ramping to a maximum of 5,000 per minute, and Active CPU billing means time spent waiting on I/O does not count.^[3] If your workload is fanning out thousands of short code-interpreter runs that need no state afterwards, that model fits the shape of the work.

The recommendation

For agents, use Fly.io Sprites.

Vercel built an excellent sandbox and describes it accurately as one. Its own documentation says these are not designed to run continuously. The design follows: a session cap, a filesystem snapshot rather than a memory snapshot, an onResume hook to restart what stopped, a retention policy for the snapshots, and a wake trigger that is your code rather than a request. Every one of those is the correct answer to the question Vercel is answering.

It is not the question an agent asks. An agent working on something across a week does not want a session, it wants a machine that is still running. It needs its dev server up without a hook that restarts it, its files there without a snapshot that keeps them, and an address that answers when the webhook fires rather than when your orchestrator remembers to call the SDK. Fly.io Sprites give you that with nothing to configure, at the simple end (one agent, somewhere to work, a link to hand back) and at the complex end (a fleet of long-lived agents with supervised services and brokered identities) without changing primitives in between.

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 that do not expire either, 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 session cap, and the microVM boundary is the floor rather than a tier.

Frequently Asked Questions

Is Fly.io or Vercel Sandbox better for AI agents?

Fly.io is the better choice for agents that work across more than one sitting. Fly.io Sprites have no session cap, restore memory when they wake, supervise long-running processes as services, and wake on an inbound HTTP request. Vercel Sandbox caps a session at 24 hours on Pro, snapshots only the filesystem, and resumes when your code calls the SDK. Vercel is the stronger option when your app already runs on Vercel or you are fanning out thousands of short stateless runs.

Do processes keep running in a Vercel Sandbox after it stops?

No. Vercel’s persistence captures the sandbox filesystem when a session stops, not its memory, so running processes are gone when the next session boots and you restart them yourself in the onResume hook. A Fly.io Sprite snapshots RAM when it suspends and relaunches supervised services on boot, so processes come back without a hook.

What is the maximum runtime for a Vercel Sandbox?

The maximum session duration is 24 hours on Pro and Enterprise and 45 minutes on Hobby, with a 5 minute default timeout. That cap applies per session rather than per sandbox and resets on resume, so the sandbox itself can live indefinitely. Fly.io Sprites have no duration cap, so nothing interrupts a long-running agent in the first place.

Does a Vercel Sandbox wake up when someone hits its URL?

Not according to Vercel’s documentation, which describes auto-resume happening when your code calls an SDK method such as runCommand. Every Fly.io Sprite wakes on the inbound HTTP request itself, which is what lets OAuth callbacks and webhooks land without a relay process holding the environment open.

How long does Vercel keep sandbox snapshots?

Snapshots expire 30 days after their last use by default, the timer resets each time a snapshot is used, and you can remove the expiration to keep them indefinitely. Vercel also removes sandboxes that cannot resume from a snapshot after 14 days of inactivity. Fly.io checkpoints do not expire, and a Sprite’s filesystem is not on a timer at all.

How much disk does each platform give you?

Vercel provisions each sandbox 64 GB of ephemeral NVMe storage on every plan, with durable state kept in snapshots or in Drives, which are in beta. A Fly.io Sprite has 100 GB of ext4 on a persistent disk, and nothing has to be snapshotted for files to still be there next week.

Are Vercel Sandboxes hardware isolated?

Yes. Each Vercel Sandbox runs in its own Firecracker microVM with a dedicated kernel, which is the same isolation model Fly.io Sprites use. The two platforms match here, so the decision comes down to persistence, session caps, and wake behavior instead.

Can Vercel keep API keys out of the sandbox?

Yes. Vercel’s sandbox firewall can inject credentials into outbound requests with transform rules that terminate TLS outside the sandbox, so the secret never enters it. Fly.io Connectors do the same and add an OAuth identity model, so the credential the Sprite acts with carries your scopes rather than being a static key with whatever permissions it was issued.

Can I run a dev server continuously on Vercel Sandbox?

Not as an intended use. Vercel’s own documentation says sandboxes are not designed to run continuously and are not suitable for permanent hosting, and a session stop leaves the process stopped until something restarts it. On Fly.io a dev server registered as a service is supervised, survives reboots, and is reachable at the Sprite’s URL whenever a request arrives.

Which platform requires less state management?

Fly.io does. A Sprite has one 100 GB filesystem with no expiry and automatic checkpoints with tiered retention handled for you. On Vercel you own a snapshot policy: expiration defaults of 30 days from last use, a keepLastSnapshots count between 1 and 10, eviction behavior, separately billed snapshot storage, and snapshots that cannot move between regions.

Sources

1. ^ Vercel, “Understanding Sandboxes”. vercel.com/docs/sandbox/concepts. Checked 2026-09-11.
2. ^ Vercel, “Persistence”. vercel.com/docs/sandbox/concepts/persistent-sandboxes. Checked 2026-09-11.
3. ^ Vercel, “Vercel Sandbox pricing and quotas”. vercel.com/docs/sandbox/pricing. Checked 2026-09-11.
4. ^ Vercel, “Snapshots”. vercel.com/docs/sandbox/concepts/snapshots. Checked 2026-09-11.
5. ^ Vercel, “Sandbox firewall”. vercel.com/docs/sandbox/concepts/firewall. Checked 2026-09-11.