Skip to content

CONCEPT Cited by 1 source

Warm Sprite pool

Definition

A pool of pre-created, pre-paid-cost VMs maintained on every physical worker in the platform fleet, holding VMs in a ready-to-assign state such that a user's create request is satisfied by dequeuing from the pool, not by any per-request image pull / boot / filesystem-build work. Enabled by the no-user-container- image decision — because every Sprite starts from the same standard container, warm pools can be pre-paid without per-user customisation.

Canonical wiki statement

Fly.io Sprites, 2026-01-14:

"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 this works for Sprites specifically

Three conditions make the warm-pool pattern cheap enough to run at create-first-touch scale:

  1. Uniform image — concepts/no-container-image-sprite. Every pooled Sprite looks identical. Without this, per-user images would demand a per-user pool (prohibitive).
  2. Cheap idle VMs — Sprites auto-sleep and stop metering when unused (concepts/scale-to-zero). An idle warm Sprite is nearly free.
  3. start is already fast — once a Sprite is created, Fly Machines' *"starts instantly, fast enough that they can wake in time to handle an incoming HTTP request"* property carries over.create=dequeue + start;start` was already ms-scale.

Relationship to Fly Machines' start-vs-create split

The 2024 start-vs- create design gave Fly Machines customers an interface with two verbs and asked them to manage the pool themselves:

"What you're supposed to do is to create a whole bunch of them and stop them so they're ready when you need them. But for Sprites, we need create to be so fast it feels like they're already there waiting for you."

Sprites move pool management into the platform. The user sees one verb (sprite create); the platform presents a warm VM from its own pool. Shifts the start-vs-create responsibility from tenant to platform.

What "warm" means here

Named components of the warm-pool state:

  • VM booted — KVM micro-VM up on the host.
  • Standard container image in place — no registry pull outstanding.
  • NVMe cache volume attached — the sparse 100 GB read- through cache described in concepts/read-through-nvme-cache.
  • Storage stack daemon in root namespace — ready to receive an object-store-URL assignment (user-data binding happens at dequeue time).
  • Inner container ready to launch — the user-facing namespace (concepts/inner-container-vm) materialises on dequeue.

Not all of this is named in the post; the post says the warm-pool dequeue "is basically just doing the stuff we do when we start a Fly Machine."

Operational parameters not disclosed

  • Pool depth per worker. Not stated. Ptacek's "I use dozens" and "casually create hundreds of them" user-side numbers bound demand, not supply.
  • Pool-refill cadence / policy. Whether refill is rate-limited, pre-emptive, or reactive is not disclosed.
  • Pool exhaustion fallback. What happens when a worker's pool is empty and demand spikes — hot-boot a new Sprite? Fall back to Fly-Machine-create? Not stated.
  • Per-region / per-worker warming policy. No disclosure.

Contrast with other warm-pool instances on the wiki

  • Pre-warmed instances under slow-boot VMMs (concepts/fast-vm-boot-dx): when boot is seconds, warm pools exist to hide the boot cost. Sprites' warm pool is different — boot is already fast; the pool hides the create-path cost (container, storage, network setup).
  • AWS Lambda execution environments: Lambda keeps warm micro-VMs per-tenant to avoid per-invocation Firecracker boot. Similar shape, different invariant — Lambda warms per-tenant (because code varies), Sprites warm globally (because image is uniform).

Seen in

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