My argument won’t make sense without showing you something new we’ve built. We’re all adults here, this is a company, we talk about what we do. Here goes. So, I want to run some code. So what I do is, I run sprite create. While it operates, I’ll exp
Overview
Fly.io introduces 'Sprites' — durable, persistent cloud computers designed as an alternative to ephemeral sandboxes for AI coding agents. The article argues that the industry's reliance on read-only, stateless containers forces agents like Claude to wastefully rebuild environments for every task, and that giving agents actual persistent computers with durable storage, checkpoints, and instant restore fundamentally changes what's possible in agent-assisted software development.
What You'll Learn
1
Why ephemeral sandboxes are a poor abstraction for AI coding agents
2
How persistent, durable cloud computers with checkpoint/restore improve agent workflows
3
Why stateless containers designed for professional developers don't match how AI agents work
4
How Fly.io Sprites combine instant creation, auto-idle, durability, and checkpointing into a single abstraction
5
Why the future of personal software may not require professional developer gatekeeping
Prerequisites & Requirements
- Understanding of cloud computing concepts (VMs, containers, sandboxes)
- Familiarity with AI coding agents (e.g., Claude, Cursor) and their sandbox-based execution model
- Experience with ephemeral development environments or CI/CD pipelines(optional)
Key Questions Answered
What are Fly.io Sprites and how are they different from ephemeral sandboxes?
Sprites are durable, persistent cloud computers that can be created in 1-2 seconds, automatically go idle and stop metering when inactive, have 100GB of durable storage, support instant checkpoint and restore, and connect to Fly.io's Anycast network for HTTPS URLs. Unlike ephemeral sandboxes, they persist across sessions and don't destroy state after each use.
Why do AI coding agents need persistent computers instead of stateless containers?
AI agents like Claude aren't professional developers trained to use stateless deployments. They work best with persistent state — they shouldn't have to rebuild node_modules, reinstall packages, or reconstruct development environments for every task. Persistent computers let agents exploit the full application lifecycle, including monitoring logs and iterating across multiple PRs without rebooting.
How fast can you create and restore a Fly.io Sprite?
Creating a new Sprite takes approximately 1 second, comparable to SSH-ing into an existing host. Checkpoint creation is described as completing instantly (too fast to bother measuring). Restoring from a checkpoint takes about one second, making it fast enough for casual, interactive use rather than being an emergency escape hatch.
How do Sprite checkpoints work compared to git?
Sprite checkpoints function like git but for the entire system state, not just source code. You create a checkpoint with 'sprite-env checkpoints create' which captures the full machine state instantly. If something goes wrong — a bad pip install, accidental rm -rf, or disk corruption — you restore with 'sprite checkpoint restore v1' in about one second, rolling back the entire system.
What problems do ephemeral sandboxes cause for AI agent development?
Ephemeral sandboxes force agents to rebuild entire development environments for every task, impose time limits that restrict compute-heavy workflows, require external infrastructure (S3, Redis, RDS) for persistent data, and prevent agents from monitoring running applications. Developers work around these limitations with plan files that are essentially encoded key-value stores, wasting effort on problems that persistence would eliminate.
How does Phoenix.new demonstrate the value of persistent agent environments?
Chris McCord built Phoenix.new where the agent runs on a Fly Machine alongside the Phoenix app it generated. The agent can see app logs and automatically notice and fix exceptions that users trigger. This required significant custom work because current sandbox models kill the environment after code generation, but with a persistent computer it would just require not destroying the sandbox when the agent finishes.
Can Fly.io Sprites replace production servers for personal applications?
For personal and small-audience applications, yes. The author runs a vibe-coded MDM (mobile device management) application on a Sprite in production for over a month. The Sprite's Anycast URL serves as the MDM registration endpoint. While Sprites aren't designed for millions of users, most important day-to-day applications don't need that scale, making dev-is-prod viable for personal software.
What is the difference between Fly.io Sprites and EC2 instances?
Sprites offer EC2-like full Linux computers but with key differences: you can casually create hundreds in 1-2 seconds without Docker, they auto-idle and stop billing when inactive, they connect to Fly.io's Anycast network for HTTPS URLs, and they have first-class checkpoint/restore. They combine the power of full instances with the convenience of disposable environments.
Key Statistics & Figures
Sprite creation time
~1 second
Time to create a new Sprite with a root Linux shell
Checkpoint restore time
~1 second
Time to restore a Sprite to a previous checkpoint
Default storage capacity
100GB
Starting durable storage capacity per Sprite
99th percentile agent sandbox runtime
< 15 minutes
Estimated maximum time most sandboxed agent runs need today
Technologies & Tools
Some links below are affiliate links. We may earn a commission if you make a purchase.
Cloud Infrastructure
Fly.io Sprites
Durable, persistent cloud computers with instant creation and checkpoint/restore
Cloud Infrastructure
Fly Machines
Fly.io's existing micro-VM platform for horizontal-scaling stateless applications
Media Processing
Ffmpeg
Demonstrated package installation on a Sprite via apt-get
AI
Claude
AI coding agent used to build applications on Sprites, referenced as the target user for persistent environments
Database
Sqlite
Backend database for the vibe-coded MDM application built on a Sprite
Programming Language
Go
Language used to build the MDM application on a Sprite
Web Framework
Phoenix
Phoenix.new cited as an example of an agent observing a running application's lifecycle
Containerization
Docker
Referenced as unnecessary — Sprites don't use Dockerfiles
Orchestration
Kubernetes
Referenced as the typical host for read-only sandbox clusters
Cloud Infrastructure
EC2
Used as comparison point — Sprites aim to feel like EC2 instances you can summon instantly
AI Integration
Mcp
Mentioned as current workaround for hauling logs to agents in sandbox environments
Key Actionable Insights
1Stop destroying your agent's execution environment after every task. Instead of ephemeral sandboxes, give AI coding agents persistent, durable computers where state carries over between sessions. This eliminates the need to rebuild node_modules, reinstall dependencies, and reconstruct development contexts every time an agent starts work.The industry is spending tens of millions of dollars on snapshot/restore for ephemeral sandboxes — problems that simply don't exist when you use persistent environments.
2Use checkpoint/restore as a first-class development tool, not just a disaster recovery mechanism. Create checkpoints after installing packages or reaching stable states, then restore instantly when experiments go wrong. Think of it as git for your entire system state.Checkpoint creation is instant and restore takes about one second, making it practical for interactive, casual use during iterative agent-driven development.
3Let your AI agent observe the full application lifecycle by running the agent and the application on the same persistent machine. This allows agents to see production logs, notice runtime exceptions, and fix issues autonomously without complex MCP server setups or external log-hauling infrastructure.Phoenix.new demonstrated this pattern where the agent monitors the app it built and auto-fixes exceptions, but it required significant custom engineering that persistence would make trivial.
4For personal and small-audience applications, consider running the agent's output directly as production software without a separate deployment pipeline. When dev and prod are the same environment on a persistent cloud computer, you eliminate deployment complexity entirely.The author has run a vibe-coded MDM on a Sprite for over a month in production. This pattern works for apps that serve individuals or small groups rather than millions of users.
5Stop building external infrastructure (S3 buckets, Redis servers, RDS instances) just to give your agent access to persistent data. If the agent's environment has durable storage, data can simply be written to files and trusted to stay put across sessions.People currently build this external infrastructure because they know they're dealing with a clean slate every time they prompt their agent, which is an unnecessary workaround for a self-imposed limitation.
Common Pitfalls
1
Treating ephemeral sandboxes as the default execution model for AI coding agents. The industry reflexively uses read-only sandboxes because they were the only isolation tool available when agents emerged, but this forces agents to wastefully rebuild environments and prevents them from maintaining state across tasks.
The author describes this as Stockholm Syndrome — developers rationalize starting from a clean environment every time, but wouldn't do this for their own feature branches.
2
Building external infrastructure (S3 buckets, Redis, RDS) to work around the lack of persistent storage in agent sandboxes. This adds complexity and cost to solve a problem that wouldn't exist if the agent had durable local storage.
People arrange external data stores because they know they're dealing with a clean slate every prompt, which is an unnecessary workaround for an artificial limitation of ephemeral environments.
3
Using 'plan files' as a workaround for lack of persistent state between agent sessions. These are ostensibly prose documents but often function as poorly-encoded key-value stores, representing the limits of trying to maintain context without actual durable storage.
This pattern emerges because agents have no way to persist structured state across sessions, leading to fragile and error-prone state management through text files.
4
Assuming agents need the same stateless container abstractions that professional developers use. Stateless deployments with persistent data confined to database servers make sense for horizontal scaling, but AI agents aren't professional developers — they work best when given full computers with durable state they can freely modify.
The mismatch between container-oriented infrastructure and agent needs leads to square-peg-round-hole situations where agents fight their environment instead of being productive.
Related Concepts
Ephemeral Sandboxes
AI Agent Infrastructure
Checkpoint/Restore
Micro-vms
Stateless Vs Stateful Architecture
Vibe Coding
Cloud Development Environments
Container Isolation
Anycast Networking
Disposable Cloud Computers
Agent-assisted Development
Personal Software Ownership