What Fly.io is

Fly.io runs your code in hardware-isolated Firecracker microVMs on servers it operates in 17 regions, behind a global Anycast network. You hand it a container image, it turns that into a Fly Machine, and you pay for the resources you use with no monthly platform fee (https://fly.io/docs/about/pricing/, https://fly.io/docs/reference/regions/).

That is the short version. The rest of this page is the longer version you can give in a meeting, using Fly.io’s own words where possible.

This page is drawn from https://fly.io/docs/getting-started/essentials/, https://fly.io/docs/machines/overview/, https://fly.io/docs/reference/architecture/, https://fly.io/docs/about/pricing/, https://fly.io/docs/sprites/ and https://fly.io/, plus the Fly.io blog posts cited inline.

The 30-second version

Fly.io’s home page says “Launch computers for agents, code sandboxes, and your next app.” and describes Machines as “hardware-virtualized containers that launch instantly and run only when you need them.” (https://fly.io/). In practice:

• A Machine is a fast VM. “Fly Machines are fast-launching VMs with a simple REST API” (https://fly.io/docs/machines/overview/). Under the hood they are Firecracker microVMs (https://fly.io/docs/getting-started/essentials/).
• You bring a container image. fly launch and fly deploy build or fetch an image and run it on Machines, configured by a fly.toml file (https://fly.io/docs/getting-started/essentials/, https://fly.io/docs/launch/deploy/).
• It runs near your users. Apps run in 17 regions, and users connect “to the nearest server through our global Anycast network” (https://fly.io/docs/reference/regions/).
• You pay for what runs. “Fly.io bills for the resources you use, with no monthly platform fee” (https://fly.io/docs/about/pricing/).
• There is a second product for agents. Sprites are “persistent, hardware-isolated Linux environments for running arbitrary code” (https://fly.io/docs/sprites/).

The two-minute version

Three nouns: Machines, Launch, Apps

Fly.io’s docs say there are “Two big concepts to know about how Fly.io works, and one small one: Fly Machines, Fly Launch, and Fly Apps” (https://fly.io/docs/getting-started/essentials/). Here is each one:

• Fly Machines are “the compute on Fly.io”, the lowest level of orchestration. If you are thinking about individual VMs, you are thinking about Machines (https://fly.io/docs/getting-started/essentials/).
• Fly Launch is “our built-from-scratch-for-Fly-Machines orchestrator”. It gives you fly launch, fly.toml, fly deploy and fly scale (https://fly.io/docs/getting-started/essentials/).
• Fly Apps are “how we group Machines on the Fly.io platform”. An app can be a web app, a database or a set of task Machines (https://fly.io/docs/getting-started/essentials/).

Say: “An app is a named group of Machines. Launch manages the group, and you can still reach down and drive one Machine by hand.” Both paths are documented in https://fly.io/docs/machines/overview/.

Machines start fast, if they already exist

The headline trick is startup speed. A started Machine usually boots in well under a second, and a stopped Machine keeps its components assembled on the worker host so it can restart quickly (https://fly.io/docs/machines/overview/). Creating one is slower: the docs say the created state “can take some time, maybe low double digit seconds” while Fly reserves space, fetches your container and builds a root file system (https://fly.io/docs/machines/overview/). The Sprites design post says “Creating a Fly Machine can take over a minute” (https://fly.io/blog/design-and-implementation/).

Fly Proxy can start existing Machines for you when traffic arrives (https://fly.io/docs/reference/fly-proxy-autostop-autostart/).

A shared front door with Anycast

Fly.io announces IP blocks from all of its datacenters over BGP. New public apps get a dedicated Anycast IPv6 address and a free shared IPv4 address (https://fly.io/docs/networking/services/). Dedicated IPv4 costs $2 a month (https://fly.io/docs/about/pricing/). The proxy layer behind those addresses is covered in Architecture.

Storage is local, not network-attached

A Fly Volume is “a slice of an NVMe drive on the same physical server as the Machine on which it’s mounted” (https://fly.io/docs/volumes/overview/). The same page says “It is not network storage”, that a volume attaches to one Machine, and that Fly.io does not replicate between volumes for you (https://fly.io/docs/volumes/overview/). That choice buys speed and costs flexibility, and it is the first thing to probe in any stateful design.

Sprites: the agent-shaped product

Sprites launched shortly before 2026-01-14, when the design post said “last week, we launched Sprites”. That post says they “create in just a second or two”, have a “100GB durable root filesystem” and “put themselves to sleep automatically when inactive” (https://fly.io/blog/design-and-implementation/). The docs table contrasts them with serverless functions: persistent state, a full ext4 filesystem, per-second billing and “compute free when idle” (https://fly.io/docs/sprites/). Sprites are billed by the second and are free when idle (https://fly.io/docs/sprites/).

The company behind it

• Its own hardware. Fly.io says it runs “applications physically close to users: in datacenters around the world, on servers we run ourselves” (https://fly.io/docs/reference/regions/). Its sub-processor list names hosting providers including CacheNetworks, DataPacket, Hivelocity, Latitude, NetActuate, Vultr and Zenlayer (https://fly.io/legal/sub-processors/, last updated 2026-10-29). Which provider hosts which region is not stated there [verify].
• Direction in 2026. In a post dated 2026-07-24, Fly.io describes itself as “a public cloud platform that is both our favorite way to put an app on the Internet and our favorite way to safely let a frontier agent coding harness cook”. The same post says the company raised more money, is focusing on Sprites, and named Scott Johnston CEO (https://fly.io/blog/kurt-scott-money-sprites/). The amount raised is not in that text [verify].
• GPU roadmap is unsettled. A post dated 2025-02-14 (February 2025) says “we’re not getting rid of them” about Fly GPU Machines, but that anyone waiting for “a v2 of the product” will be waiting awhile (https://fly.io/blog/wrong-about-gpu/). Treat GPU roadmap questions as unsettled [verify].

A short history

Who it is for

What you can and cannot do

You can:

• Run any container image as a Machine, in a region you pick, from a CLI or the Machines REST API (https://fly.io/docs/machines/overview/).
• Scale out with fly machine clone or fly scale, and up with fly machine update (https://fly.io/docs/machines/overview/).
• Join apps over a private network of WireGuard tunnels called 6PN (https://fly.io/docs/networking/private-networking/).
• Pick shared or performance CPUs. Shared vCPUs get a 5ms baseline quota per 80ms period plus a burst balance, while performance vCPUs get the full period (https://fly.io/docs/machines/cpu-performance/).

You cannot, or must plan around:

• Choose a specific server. You pick the region; Fly.io picks the host (https://fly.io/docs/machines/overview/).
• Assume capacity. “we can run out of capacity in particular regions”, and a scale operation across regions fails as a whole if one region is full (https://fly.io/docs/machines/overview/, https://fly.io/docs/machines/guides-examples/machine-placement/).
• Share a volume. One volume, one Machine, one app, one server (https://fly.io/docs/volumes/overview/).
• Rely on built-in volume replication. The app or database must replicate (https://fly.io/docs/apps/app-availability/).

The vocabulary you need

• Machine. A Firecracker microVM with a Machine ID, in one region (https://fly.io/docs/getting-started/essentials/).
• App. A named group of Machines, plus config and routing (https://fly.io/docs/machines/overview/).
• fly.toml. The app configuration file (https://fly.io/docs/getting-started/essentials/).
• Fly Proxy. The routing layer on every edge and worker (https://fly.io/docs/reference/fly-proxy/).
• 6PN. The private IPv6 network joining an organization’s apps (https://fly.io/docs/networking/private-networking/).
• Volume. Local NVMe persistent storage for one Machine (https://fly.io/docs/volumes/overview/).
• Sprite. A persistent hardware-isolated Linux VM for agents and dev environments (https://fly.io/docs/sprites/).

Facts people get wrong

1. It is a container host. Not quite. Containers are the packaging, but each runs inside a Firecracker microVM. Fly.io says its Machines are “approximately OCI containers repackaged as KVM micro-VMs” (https://fly.io/blog/design-and-implementation/).
2. The disk is shared network storage. It is local NVMe on one server (https://fly.io/docs/volumes/overview/).
3. Autostop creates and destroys Machines. It does not. It “only works on existing Machines and never creates or destroys Machines for you” (https://fly.io/docs/reference/fly-proxy-autostop-autostart/).
4. One Machine is enough in production. The docs warn that a single Machine with a single volume risks downtime and data loss, and a first fly deploy creates “one or two Machines for every process group” depending on services and volumes: two for groups with services, one when a volume is mounted (https://fly.io/docs/volumes/overview/, https://fly.io/docs/launch/deploy/, https://fly.io/docs/apps/app-availability/).
5. Sprites are just small Machines. They share infrastructure today, but the design post says Sprites drop user containers and use object storage as the root of disks (https://fly.io/blog/design-and-implementation/).

When Fly.io is the wrong choice

This is advice, with the facts underneath:

• You need a shared network filesystem across many VMs. Volumes are single-server and single-Machine (https://fly.io/docs/volumes/overview/).
• You need guaranteed capacity in a hot region. The docs say some regions “tend to be in high demand” and placement can fail (https://fly.io/docs/machines/guides-examples/machine-placement/).
• You have thousands of mostly idle Machines in one app. The autostop loop stops one Machine per region per cycle, so at that scale the docs point you to one app per user or app-driven shutdown (https://fly.io/docs/reference/fly-proxy-autostop-autostart/).
• You want a roadmap for GPU workloads. See the 2025 post above (https://fly.io/blog/wrong-about-gpu/).

Where to go next

• How it is built: Architecture
• How much it costs: Economics
• Proving it in an hour: POC