Skip to content

SYSTEM Cited by 1 source

pilot (Fly Machines next-generation init)

pilot is Fly.io's next-generation init binary for Fly Machines — the successor to the original Rust Fly init described in the 2024-06-19 AWS without Access Keys post. Unlike that init, which was "whatever we wanted it to be" and slowly accreted features, pilot is itself a complete OCI-compliant runtime with a defined API for flyd to drive. Written in Rust (one of Fly.io's three Rust services, alongside fly-proxy and corrosion2).

Stub page — expand on future pilot-focused sources.

Why pilot exists

From JP Phillips's 2025-02-12 Fly.io exit interview:

pilot is our new init. When we launch a Fly Machine, init is our foothold in the machine; this is unlike a normal OCI runtime, where "pid 1" is often the user's entrypoint program. Our original init was so simple people dunked on it and said it might as well have been a bash script; over time, init has sprouted a bunch of new features. pilot consolidates those features, and, more importantly, is itself a complete OCI runtime; pilot can natively run containers inside of Fly Machines.

Before pilot, there really wasn't any contract between flyd and init. And init was just "whatever we wanted init to be". That limited its ability to serve us.

Having pilot be an OCI-compliant runtime with an API for flyd to drive is a big win for the future of the Fly Machines API. (Source: sources/2025-02-12-flyio-the-exit-interview-jp-phillips)

Delta vs. the pre-pilot init

Dimension init (pre-pilot) pilot
Role in Machine PID 1, feature-bag PID 1, OCI runtime
Contract with flyd Ad-hoc / absent Formal API
Runs containers No — launches customer entrypoint Yes — natively
Feature placement Accreted into init binary Consolidated into runtime

The structural move is analogous to runc / containerd for Fly Machines: before, flyd and init handled whatever they handled; after, flyd calls a defined OCI-runtime API on pilot inside the Machine. This restores a contract at the init/orchestrator boundary that Fly had let drift for years.

Features disclosed this source

  • Complete OCI runtime — pilot can natively run containers inside a Fly Machine, not merely bootstrap one entrypoint.
  • API for flyd to drive — disclosed as existing, not specified. Endpoints / RPCs / semantics are not in this source.
  • Consolidates pre-pilot init features — the AWS OIDC-credential-broker behaviour disclosed in the 2024-06-19 post, the /.fly/api Unix-socket API proxy, the Macaroon- attach-on-outbound model, and whatever other features had accreted. JP does not enumerate which specific features migrate; wiki assumption: all of them.

Not yet disclosed

  • Pilot's exact API surface to flyd.
  • Whether pilot uses an off-the-shelf OCI runtime under the covers (containerd? crun? youki? its own?) or implements the OCI runtime spec directly.
  • Fleet-wide rollout status (full? staged? beta?).
  • Whether pilot is open-sourced.
  • Latency / memory / throughput deltas vs. the pre-pilot init.
  • Whether the Rust init binary from 2024-06-19 is still in use on any production fleet or has been fully replaced.

Seen in

  • systems/fly-init — the pre-pilot Rust init; historical record of the Unix-socket API proxy + OIDC credential-broker features that pilot consolidates.
  • systems/fly-machines — the compute primitive pilot lives inside.
  • systems/flyd — the orchestrator that drives pilot via its (disclosed-but-unspecified) API.
  • systems/firecracker — the hypervisor substrate pilot runs under.
  • systems/runc, systems/containerd — the standard OCI runtime stack pilot's role is analogous to (for Fly Machines).
Last updated · 200 distilled / 1,178 read