Skip to content

CONCEPT Cited by 1 source

No container image (Sprite design)

Definition

A VM-platform design decision: do not let users supply a container image. Every instance boots from a single platform- standard image; user workloads bring their state through a different mechanism (durable filesystem, apt install, VCS clone) after boot. The container image — with all of its Dockerfile semantics, registry pulls, layer unpacking, and per-image cache misses — is removed from the create path.

Canonical wiki statement

Fly.io Sprites, 2026-01-14:

"Sprites get rid of the user-facing container. Literally: problem solved. Sprites get to do this on easy mode. Now, today, under the hood, Sprites are still Fly Machines. But they all run from a standard container. Every physical worker knows exactly what container the next Sprite is going to start with, so it's easy for us to keep pools of 'empty' Sprites standing by. The result: a Sprite create doesn't have any heavy lifting to do; it's basically just doing the stuff we do when we start a Fly Machine."

(Source: [[sources/2026-01-14-flyio-the-design- implementation-of-sprites]])

Why the container-image path is slow

Ptacek enumerates four costs that deleting the user-container eliminates:

  1. "Huge and fussy, they take forever to pull and unpack."
  2. Registry throughput — "A truly heartbreaking amount of engineering work has gone into just allowing our OCI registry to keep up with this system."
  3. Regional locality — "create a Fly Machine in São Paulo on gru-3838, and a create on gru-d795 is no faster" — the image isn't present regionally, so every fresh region hits the global registry.
  4. Per-image variance — since every user's image is different, no amount of per-host caching eliminates the pull on first create.

What replaces the container image

Contrast with Fly Machines

Fly Machines are "approximately OCI containers repackaged as KVM micro-VMs" — the Dockerfile is load-bearing. The 2024 Making Machines Move retrospective carries the cost explicitly: "It took 3 years to get workload migration right with attached storage, and it's still not 'easy'." Most of that 3-year cost is the image + attached-storage-anchoring combination.

Ptacek's summary:

"We only murdered user containers because we wanted them dead. […] We love [Fly Machines] very much and they're clearly the wrong basis for a ball-point disposable cloud computer."

Trade-offs

  • Image composition is no longer in user's contract. Users who need a specific base image or a pre-baked toolchain install it at first boot — slower first use, but only the first.
  • Cold tooling on first boot. A blank Sprite with apt install has to pay the package-install latency the first time. Ameliorated by pre-installed defaults (Claude, Gemini, Codex in the 2026-01-09 post) and by checkpointing the post-install state ([[concepts/fast-checkpoint-via- metadata-shuffle]]).
  • Fit with CI/CD conventions. "For that matter, professional production apps ship out of CI/CD systems as OCI containers; that's a big part of what makes orchestrating Fly Machines so hard." — Sprites opt out of the CI/CD ecosystem that container images fit into, by design, at the cost of not being the right product for production-scale app shipping.

Not a universal prescription

The no-container-image decision is scoped to the Sprites product shape: durable per-user interactive VMs. It is not a claim about production-app orchestration. Ptacek:

"Sprites live alongside Fly Machines in our architecture. […] An automated workflow [prototype on Sprites, ship as Fly Machine] will happen."

Seen in

  • [[sources/2026-01-14-flyio-the-design-implementation-of- sprites]] — canonical wiki statement.
Last updated · 319 distilled / 1,201 read