Agentic development on Fly.io
Run AI coding agents from prototype to production
Build with Claude Code, Cursor, Codex, and Gemini in isolated Sprites, keep the agent separate from the code it runs, and ship to production on Fly Machines with no rewrite.
Start building on Fly.io
An agent is two things: a brain and the code it runs
The brain holds your context, your keys, and your tools. The code it runs was often written seconds ago by a model, or pulled from a dependency nobody has read. Run both in the same place and one bad command can reach everything the agent can. The safer shape is to separate them, and Fly.io gives you a compute primitive for each.
- The agent wants a stable home. It should stay up, hold its context, and keep your credentials. In production that wants always-on compute: a Fly Machine.
- Its code wants an isolated sandbox. Whatever the agent runs should be sealed off from the agent and from you, easy to contain and to throw away: a Sprite.
Sprites: isolated execution, and a place to build
A Sprite is a hardware-isolated, persistent Linux computer on Fly.io. It is where code runs safely, separate from whatever launched it, and it is where an agent can build. Claude Code, Gemini, and Codex come preinstalled, and any agent can drive Sprites through the Sprites MCP server.
Hardware isolation
Each Sprite is a Firecracker microVM with its own kernel. Code an agent runs here cannot reach the agent's host, your secrets, or your network.
Persistence
A stable filesystem that survives across sessions. Sprites sleep when idle and wake in under a second on the next request.
Checkpoint and restore
Snapshot the whole environment before a risky change, then roll back in seconds if it goes wrong. Not just the code, the running services too.
Agents preinstalled
Claude Code, Gemini, and Codex ship inside every Sprite, ready to build and to run code on your behalf.
Machines: the stable home for your agent
In production, run the agent itself on a Fly Machine. Machines are always-on Firecracker VMs built for long-running services, so the agent stays up, holds its state, and keeps responding while it spins up Sprites to execute code.
Sprites and Machines are the same Firecracker substrate. Moving the agent from a Sprite you built in to a Machine you run in production is a deploy, not a rewrite. The apps your agent builds run on Machines too.
- Agent. On a Fly Machine in production, in a Sprite while you build.
- Execution. Always in a separate Sprite, isolated from the agent.
- Build. The agent works and checkpoints inside Sprites.
- Ship. Apps graduate to Fly Machines. Same substrate, no rewrite.
A complete, secure, persistent foundation for agentic development
While you build, run everything in Sprites: the agent and its code execution, cheap and reversible. Keep the agent isolated from the code it runs at every stage, so generated code never touches the agent's host. For production, move the agent onto a Fly Machine for a stable, always-on home while it keeps executing code in Sprites, and run the apps it built on Machines too. One foundation for agentic development on Fly.io, from the first prompt to production.
Start building on Fly.ioSeparate the agent from the code it runs
The agent process is the trusted part of the system. It holds your model keys, your repository, and the tools you have given it. The code it executes is the least trustworthy part: freshly generated, or pulled from a package nobody audited. Running them in the same process is how a single prompt injection or a bad dependency turns into leaked keys and a compromised host.
On Fly.io you keep them apart. Run the agent on a Fly Machine, or on its own Sprite, and have it execute code in a separate Sprite through the Sprites MCP server. The two are different Firecracker microVMs with different kernels, so code that misbehaves, or even escapes the process it ran in, is still inside a disposable sandbox, not inside your agent. When the task is done, the execution Sprite is checkpointed or thrown away, and the agent is untouched.
Driving Sprites from your agent with the MCP server
The Sprites MCP server is a hosted Model Context Protocol endpoint, so an MCP-aware agent can operate Sprites without living inside the one it is driving. An agent on a Fly Machine can create a Sprite, run a command in it, read the result, set a network policy, checkpoint it, and tear it down, all over the MCP server, and never run that code in its own process. It authenticates with either an OAuth flow or a Fly.io API token.
Inside a Sprite, the preinstalled agents go further. Claude Code, Gemini, and Codex ship with machine-readable docs and prebuilt skills that teach them how the environment works, so the agent already knows how to checkpoint, register a service, open a port, or read service logs without you wiring any of it up.
From prototype to production without a rewrite
Most agent sandboxes stall at the prototype stage because the sandbox is not production. The code runs in one place while it is built and has to be packaged for somewhere else to ship. On Fly.io that gap does not exist. While you build, run the agent and its code execution in Sprites, checkpointing as the work comes together. For production, move the agent itself onto a Fly Machine for an always-on, stable host, and keep using Sprites for execution.
Because Sprites and Machines are the same Firecracker substrate, that move is a deploy, not a migration. The apps the agent built ship to Machines the same way, so the runtime never changes underneath you and behavior you verified during development is the behavior you get in production.
Best practices for autonomous agents
Never run generated code in the agent's own process: delegate it to a Sprite, so the agent host stays clean no matter what the code does. Checkpoint before anything risky, since a checkpoint captures the whole environment and restores in seconds, giving an agent a safe point to return to before a destructive migration or a large refactor. Lock down egress with a network policy that allows only the domains the task needs, so generated code cannot reach anything you did not intend. And use the per-Sprite HTTPS URL to preview what the agent built, including webhooks and OAuth callbacks, without exposing your own machine.
When the work is solid, ship it to Fly Machines and keep the Sprites around as the place the agent continues to build and run code. The development environment and the production environment stay in sync because they were the same kind of environment all along.
Frequently asked questions
Can I run Claude Code on Fly.io? +
Yes. Fly.io Sprites are hardware-isolated, persistent Linux environments with Claude Code preinstalled and ready to use. A Sprite ships with machine-readable docs and prebuilt skills, so Claude Code can manage its own environment, including checkpoints, services, and network policy, with no setup.
Which AI coding agents work with Fly.io Sprites? +
Claude Code, Gemini, and Codex come preinstalled on every Fly.io Sprite, each taught how to checkpoint, register services, and read logs. Cursor and other MCP-aware agents are supported through the Sprites MCP server and the sprite-api-gateway skill that ships in every Sprite.
Where should the AI agent itself run on Fly.io? +
Run the agent on a Fly Machine in production: Machines are always-on Firecracker VMs suited to a long-running agent process that holds context and keys. While you are building, the agent can live in a Sprite instead. In both cases it executes code in separate Sprites, so the agent's host stays isolated from the code it runs.
How do I keep my agent isolated from the code it runs on Fly.io? +
Run the agent in one place (a Fly Machine, or its own Sprite) and execute its code in a separate Sprite through the Sprites MCP server. Because each Sprite is a Firecracker microVM with its own kernel, code the agent runs cannot reach the agent's process, your credentials, or your network. The agent never runs untrusted code in its own environment.
What is the Sprites MCP server? +
The Sprites MCP server is a hosted Model Context Protocol endpoint that lets an AI coding agent create and control Fly.io Sprites directly. Through it an agent can create sprites, run commands, checkpoint and restore, manage long-running services, and set network policy, authenticating with either OAuth or a Fly.io API token.
Is it safe to let an AI agent run code autonomously on Fly.io? +
Yes. Each Fly.io Sprite is a Firecracker microVM with its own kernel, so an agent can run with full permissions and still not affect anything outside its environment. Outbound network access is controlled by an allowlist policy the agent cannot widen from inside, and checkpoints let you roll back any change in seconds.
How do I take what an agent built from prototype to production on Fly.io? +
Sprites and Fly Machines run on the same Firecracker substrate, so the environment an agent builds in is the same kind of environment that runs in production. When the prototype is ready, you run it as a long-lived service on Fly Machines without porting it to a different runtime.
How is a Fly.io Sprite different from an ephemeral sandbox? +
Most agent sandboxes are ephemeral and are destroyed when a task ends. A Fly.io Sprite is persistent: its filesystem lives on a stable disk, it sleeps when idle and wakes in under a second, and checkpoints capture the whole environment so an agent can pick up exactly where it left off.
Can my agent manage its own infrastructure on Fly.io? +
Yes. Through the Sprites MCP server a coding agent can create and destroy sprites, execute commands, checkpoint and restore state, run services, and adjust network policy on Fly.io, so the agent operates its own infrastructure rather than waiting on you.
Do I need to configure anything to use an agent inside a Sprite? +
No. A Fly.io Sprite spins up with the agents preinstalled and a set of machine-readable docs at a known path that teach the agent how the environment works. You can point the agent at those docs and it will manage checkpoints, services, and ports on its own.