Skip to content

SYSTEM Cited by 1 source

flaps (Fly Machines API gateway)

flaps is the API server behind Fly.io's Machines API — the front door for POST /apps/{app_name}/machines, GET /apps/{app_name}/machines/{id}, and the rest of the Machines-API surface. flaps translates incoming HTTPS requests into RPCs against per-host flyd processes distributed across Fly.io's global worker fleet.

Stub page — expand on future flaps-focused sources.

Design properties

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

Yes, all of it. The flaps API server, the flyd RPCs it calls, the flyd finite state machine system, the interface to running VMs.

… I like that it for the most part doesn't require any central coordination. And I like that the P90 for Fly Machine create calls is sub-5-seconds for pretty much every region except for Johannesburg and Hong Kong. (Source: sources/2025-02-12-flyio-the-exit-interview-jp-phillips)

Two load-bearing properties disclosed:

  1. Decentralised — "for the most part doesn't require any central coordination." flaps routes to per-host flyd processes; those flyd processes own their Machine placement decisions locally.
  2. Sub-5-second P90 Machine-create latency — globally, with Johannesburg and Hong Kong as the named regional outliers.

Numbers disclosed

  • P90 machine create: sub-5-seconds for every region except Johannesburg and Hong Kong.

Not disclosed

  • flaps implementation language (not named in JP's Rust-services list — fly-proxy, corrosion2, pilot — so likely Go).
  • Internal routing / discovery mechanism (how flaps finds the right flyd process for a given host).
  • Authentication / token model for Machines API calls (external Macaroons, internal service tokens).
  • Rate-limiting, quota enforcement, per-org isolation.
  • P99 and P99.9 latency.
  • Root cause for the Johannesburg + Hong Kong P90 regression (network topology? flyd density? worker fleet size?).

Seen in

Last updated · 200 distilled / 1,178 read