Fly.ioExplainer
Fly Machines: an API for fast-booting VMs
Summary
Fly Machines are virtual machines exposed through a fast REST API, with boot times of about 300ms, intended to support cost-effective standby capacity and scale-to-zero applications. Creation is deliberately separated from starting: it performs a centralized database preflight, reserves host capacity through NATS, records the machine, and prepares the OCI image locally. A later start request goes to the nearest regional API, which sends a direct message to the known host, avoiding database coordination and image pulls; examples cite roughly 10ms locally and 150ms across regions. Processes can exit when idle to leave machines intact for clean restarts, while fly-proxy can start them for incoming HTTP requests. The design trades simplicity for hardware pinning, so capacity or host failures may require fallback machines and redundancy; stopped machines currently incur image-storage charges, such as about $0.15 per month for a 1GB Docker image.
Context
Fly.io customers want applications to scale to zero, primarily to reduce costs, and some want to build their own functions-as-a-service systems. Fast VM startup is constrained by API coordination, cross-region network latency, and remote Docker image downloads.
Approach / What changed
Machines are created ahead of demand, with centralized accounting and host reservation completed before startup. The image is stored on the selected host, allowing a regional API to send a direct start message without database coordination or an image pull. Idle processes can exit, leaving machines intact for later starts.
Takeaways
Machine creation is relatively slow because it performs centralized consistency and billing checks, reserves capacity through NATS, and coordinates host selection.
Starting a prepared machine avoids database and image-pull latency; the source gives approximate start-message times of 10ms within a region and 150ms between Los Angeles and São Paulo.
Hardware pinning simplifies startup but introduces host and capacity failure modes, so applications should use fallback locations or redundant machines.
Source and freshness
- Source
- fly.io
- Published
- Added to Yomu
- Last updated
Summaries are generated from the original by a language model. Check the original before relying on it.
Keep reading
Related reading
The Good Stuff
Paid picks we use ourselves. Links carry a referral code — a subscription through one earns us a commission at no extra cost to you.
The best engineering reads, once a week
One useful email. Unsubscribe anytime.