The Design & Implementation of Sprites

Thomas Ptacek’s framing for Fly.io’s new Sprites is cheapness of use rather than raw power:

Sprites are ball-point disposable computers.

The point is that you stop rationing them. Creation takes a second or two, so shelling into a fresh one feels the same as SSH’ing into a machine that already exists, and he admits he barely bothers naming them.

Four design choices get them there. There are no user-facing container images, so creating a Sprite is really the fast start of a pre-positioned empty one rather than the slow create. The root filesystem, 100GB and durable, sits on S3-compatible object storage on the JuiceFS model, splitting data chunks from metadata, with local NVMe as a read-through cache and Litestream keeping the SQLite metadata durable. That makes checkpoint and restore a matter of shuffling metadata rather than moving data, closer to git restore than a system restore, and fast enough that Ptacek wants it treated as a normal feature rather than an escape hatch. Finally, orchestration is inside-out: user code runs in an inner container while the storage stack, service manager and logging live in the root namespace, so VMs can be bounced without a full reboot.

This is the engineering companion to agents that don’t break themselves, which covers the same product from the agent’s point of view. Worth reading with the usual caveat: this is a vendor explaining why its own newly launched product is the right shape.