Manage Fly.io apps, machines, volumes, secrets, certificates and IP addresses
Machine.List used
GET /v1/orgs/{org}/machines, which Fly documents as "a point in time" whose
"recent machine changes, including creations and destructions, may take time
to propagate" — in practice a machine created seconds earlier is absent from
it for minutes, so every discovery scan reported zero machines while Read
answered for the same machine immediately. List now fans out over the org's
apps and uses the per-app endpoint, which is immediately consistent. That is
N+1 requests instead of one, the same trade Secrets.List already makes.
Volume keeps the org-wide endpoint: it carries no such caveat and discovery
finds a fresh volume on the first scan.Credential resolution matching flyctl exactly: FLY_ACCESS_TOKEN, then
FLY_API_TOKEN.
Discovery for all six types. Volume uses the org-wide endpoint (one cursor-paged call); Machine, Secrets, Certificate and IPAddress fan out per app — for Machine because Fly's org-wide machine index lags recent creations by minutes, for the others because no org-wide endpoint exists.
Conformance coverage — CRUD lifecycle and discovery — for App, Secrets, Machine, Volume, IPAddress and the whole Managed Postgres graph (cluster, database, user, extension, attachment) in one forma, so a single billable cluster serves every child. Ten of the fourteen types are exercised against the live API.
SecretKey is covered too, so twelve of the fourteen types are exercised against the live API.
Not conformance-tested, deliberately: Certificate never converges without
DNS records on a domain the suite controls, and VolumeSnapshot /
Postgres::Backup have no delete endpoint, so every run would leak an
artifact. Reasoning is on the resource classes in schema/pkl/core/fly.pkl.
examples/basic/ — one publicly reachable Fly app.
examples/fullstack-fly-supabase-vercel/ — a three-tier application across
Fly, Supabase and Vercel wired with cross-plugin resolvables, plus a
two-provider variant.
Design notes on every resource class in schema/pkl/core/fly.pkl, covering
the API behaviour each one was written against.