Sprites Meet MCP: How Fly.io Built Agent-Safe Sandboxed Deployment Environments

Simon Willison opened 2026 with a prediction: we were due a "Challenger disaster" for coding-agent security, because the only way to get real work out of Claude Code or Codex CLI was YOLO mode — --dangerously-skip-permissions — running on your laptop with your credentials, your SSH keys, and your production access one prompt injection away from ruin.

Nine months later, Fly.io's answer has fully matured: Sprites, persistent Firecracker microVMs you spin up in a second or two, now speak MCP natively at sprites.dev/mcp, so an agent can type "on a new Sprite, do…" and get a real computer instead of a sandbox ticket.

This post pulls apart what Fly.io actually built and turns it into something you can reuse: a six-primitive checklist for what "agent-safe" concretely requires, mapped to how Sprites implements each item, then compared against E2B, Daytona, Modal, Vercel Sandbox, and Blaxel — and against what you'd need to build the same thing on hardware you own.

Keep this table. It is the whole post in miniature, and section 6 reuses it as a build spec for a self-hosted sandbox fleet.

What Sprites Actually Is​

Sprites (sprites.dev) launched in January 2026 as Fly.io's second orchestration stack — a deliberate undoing of several Fly Machines decisions, in Thomas Ptacek's telling. The shape is unusual enough to be worth stating precisely, because every property on the list exists to serve agents:

• Persistent Linux microVMs, not containers. You get root on a real VM with hardware virtualization underneath. Create takes one to two seconds — fast enough that shelling into a fresh Sprite feels like SSH into a machine that already exists. They are responsive enough to host web apps for a team, which is what promotes them from sandboxes to deployment environments.
• A 100GB durable root filesystem per Sprite. Storage is NVMe attached to the host, but — and this is the key design inversion — the NVMe is only a read-through cache. The true state lives as a blob on S3-compatible object storage, so a dead host never takes your data with it. You pay for blocks you write, and deletes lower the bill.
• Auto-sleep with scale-to-zero billing. Idle Sprites hibernate; compute cost drops to ~zero while cold storage keeps state durable. Fly.io staff famously accumulate 20–30 Sprites just hanging around because keeping one costs practically nothing.
• Checkpoints as a routine primitive, not an escape hatch. A checkpoint captures the writable overlay in ~300ms by shuffling metadata, not copying disk. Preinstalled agents checkpoint aggressively without asking, and restore is async with an environment restart. Ptacek frames it as "a git restore, not a system restore."
• Agents preinstalled and pre-taught. Claude Code, Codex, and Gemini CLIs ship on the image alongside Python 3.13 and Node.js, plus skills and machine-readable docs in /.sprite/ that teach an agent inside the machine how the place operates — how to checkpoint, register services, and read logs.

Kurt Mackey's launch thesis was blunt: "ephemeral sandboxes are obsolete." Agents don't want containers or read-only sandboxes; they want computers, with real filesystems, connected to real networks. The design above is what it costs to give them that without giving them your laptop.

The MCP Layer: sprites.dev/mcp​

The September 2026 post "Your Agent Speaks MCP. Give It a Computer." plugged that computer into the agent-tooling standard. Point any MCP-compatible client at sprites.dev/mcp, authenticate to one Fly.io organization, and prompts like these start working:

On a new Sprite, take this repository and reproduce this bug from issues/913, capturing logs.
On 3 new Sprites, change this service to use each of these 3 query libraries, and use HTTP to test latency.
On a new Sprite, run this code with bpfwatch and show me what files it touches.

Three design choices in the MCP layer are worth stealing:

1. Progressive disclosure instead of tool-dumping. The live debate in agent tooling is whether MCP's "dump thirty tool descriptions into context" is worse than a discoverable CLI. Fly.io's answer is that it's a false dichotomy: disclosure is what you say to the model, MCP is how the bytes get there. Their Claude Code plugin ships the hosted MCP server underneath and skills on top, so what lands in context is roughly one sentence about when you'd want a fresh computer — the rest arrives when needed. Codex, Cursor, Gemini, Grok, and opencode follow the same pattern, and anything else can point at the bare endpoint.

2. Safety annotations on every tool. File reads come back as MCP resources instead of pasted walls of text. Read-only operations are marked read-only, destructive ones destructive — and exec and service_start are explicitly flagged as the two tools that reach past the Sprite's boundary. A client that honors annotations can treat "list my checkpoints" very differently from "run this thing."

3. Guardrails that assume the robots will misbehave. Auth hands the agent a single specific org, scoped down from there. Sessions default to five Sprites max with an mcp- name prefix, so agent-created machines are easy to spot and easy to disassemble. The shell and REST API never went away either — same API underneath, so an agent that prefers scripts over tool calls gets identical power.

The Agent-Safe Primitives Checklist, Concretely​

Each row of the opening table exists because a specific failure mode is otherwise a matter of time. Here is the checklist with the failure each primitive prevents:

1. Hardware boundary. A container escape or a confused agent with host mounts turns "sandbox" into a suggestion. One microVM per tenant with its own kernel makes the blast radius a VM you can delete. This is why Sprites, E2B, Vercel Sandbox, and Blaxel all converged on Firecracker-class isolation rather than Docker defaults.
2. Ephemeral identity. Long-lived credentials and pet-named machines accumulate access. Sprites are cheap enough to be cattle: create in seconds, destroy without ceremony, and the MCP prefix/cap convention makes agent sprawl visible instead of silent.
3. Egress policy. An agent that can reach the open internet can exfiltrate the credentials you gave it. Sprites sit on their own IPv6 prefix apart from Fly's private network — network segmentation as a default, not a checkbox. Note the gap competitors exploit: Vercel Sandbox brokers credentials at the egress proxy so keys never enter the sandbox at all.
4. Lifecycle with TTL. Sandboxes that never sleep become unpatched pets with a cloud bill. Auto-sleep plus scale-to-zero aligns cost with use and bounds how long a compromised box stays warm.
5. Checkpoint and rollback. Agents run destructive commands — that is the job. A ~300ms checkpoint before the risky step turns "the agent deleted the database" into "restore v4 and continue." Anything slower than a second doesn't get used routinely, which is exactly why Fly.io made checkpoint speed a headline metric.
6. Guardrailed agent interface. The tool layer is itself an attack surface: prompt injection arrives through tool results. Auth scoping, creation caps, and machine-readable safety metadata are what keep "give every agent a computer" from meaning "give every attacker a computer."

If you take one thing from this post, take this list. It is also the scorecard for the next section.

How the Alternatives Differ​

The sandbox market has split into two philosophies: persistent computers (Sprites, Blaxel, Daytona) versus ephemeral execution (E2B, Modal, Vercel Sandbox). The table below scores the main contenders against the primitives that actually discriminate between them.

Three rows of that table deserve commentary, because they decide real purchases:

Billing model matters more than sticker price. A community-measured 4-hour Claude Code session on Sprites runs about $0.44 — cheap enough to never think about. But agents spend most of wall-clock time waiting on LLM responses, so E2B's wall-clock billing charges full CPU rate for what is really I/O wait, while Vercel's active-CPU pricing explicitly excludes it. For I/O-heavy agents, the billing model is a bigger number than the per-unit rate. Always recompute with your own wait ratio before comparing price pages.

Isolation strength is not one thing. Firecracker microVMs (Sprites, E2B, Vercel) give each tenant a kernel; gVisor (Modal) interposes on syscalls in userspace; Daytona's Docker default is weakest unless you opt into Kata. All of them beat --dangerously-skip-permissions on a laptop — but if your threat model includes untrusted third-party code rather than just your own agent's mistakes, the microVM row is where you should be.

Self-hosting is E2B's and Daytona's wedge. E2B publishes its infrastructure repo and offers bring-your-own-cloud and self-hosted options; Daytona offers private deployments with your own metal. Sprites has no air-gapped story — Fly.io staff talk about an open-source local version as "coming," which is not a thing you can put in a procurement doc. If the sandbox must live inside your boundary, that row of the table currently eliminates the category leader.

What This Means for a Self-Hosted Fleet​

Re-read the six-primitive checklist as a build spec for owned hardware, and the gap analysis writes itself:

• Isolation: Firecracker and Kata Containers are both open source and both run fine on a Hetzner box. This primitive is solved technology; the work is operational (image builds, kernel versions, cgroup accounting), not research.
• Ephemeral identity and lifecycle: an API that creates a microVM in ~1s, sleeps it on idle, and enforces per-tenant caps is a medium-sized controller project — the same shape as the Cluster API machine lifecycle a self-hosted PaaS already runs, pointed at VMs instead of bare metal.
• Egress policy: CNI network policies plus an egress proxy get you segmentation; credential brokering à la Vercel (keys injected outside the sandbox boundary) is the part nobody has packaged for self-hosters yet.
• Checkpoints: this is the hard one. Sprites' ~300ms checkpoints come from a bespoke storage stack (NVMe read-through cache over object storage, metadata-only checkpoint shuffle). QCOW2 snapshots or ZFS clones get you minutes-scale rollback, not milliseconds-scale routine use. Expect this primitive to lag managed offerings the longest.
• Agent interface: an MCP gateway that fronts your sandbox API with per-tool safety annotations is very buildable — MCP is an open standard, and Fly.io's progressive-disclosure trick is just skills plus a thin server.

The honest summary: a self-hosted fleet can match four of the six primitives with off-the-shelf components today, can approximate egress credential-brokering with real effort, and should not promise Sprites-grade checkpoint speed until the storage layer is purpose-built.

That is a roadmap, not a rejection — and it tells you exactly which managed bill to keep paying while you build (the one for stateful, checkpoint-heavy workloads) versus which to replace first (ephemeral execution, where Firecracker plus an API is a weekend project).

Computers, Not Sandboxes​

Fly.io's provocation — stateless sandboxes are obsolete, agents want computers — reads less like marketing and more like a field report nine months after launch. The MCP integration is what completes the argument: the computer is only as useful as the agent's ability to reach it, and a hosted MCP endpoint with skills, safety annotations, and creation guardrails turns "provision infrastructure" into a sentence inside a prompt.

Whatever you rent or build, score it against the six primitives: hardware boundary, ephemeral identity, egress policy, lifecycle with TTL, checkpoint speed, and a guardrailed agent interface. The vendors in the table above each ace four or five and fumble one — billing model, GPU support, self-hosting, or checkpoint speed. Know which fumble you can live with before your agent's first YOLO run, not after.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. AI agents are first-class operators: every app ships with machine-readable state they can deploy against. Star the repo on GitHub or deploy your first app today.