---
title: "Fly Machines: an API for fast-booting VMs"
description: "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."
---

# Fly Machines: an API for fast-booting VMs

[Fly.io](https://yomu.fyi/company/fly-io) · May 24, 2022

**Type:** Explainer

## 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.

**Tags:** [Firecracker](https://yomu.fyi/topic/firecracker), [Fly Machines](https://yomu.fyi/topic/fly-machines), [REST APIs](https://yomu.fyi/topic/rest-api)

- Source: [Fly.io](https://fly.io/blog/fly-machines)
- Source URL: https://fly.io/blog/fly-machines
- Ingested by Yomu: 2026-09-03T01:24:10.768Z

[Read original post](https://fly.io/blog/fly-machines)