Cloud Parts

Fly.io

Fly.io turns your Docker image into fast-booting Firecracker microVMs on its own servers in regions around the world, and routes each user to the nearest one.

What it is
Platform as a service (PaaS)
Used for
MicroVMs
Type
Commercial product
Made by
Fly.io, Inc.
License
Proprietary
Facts checked
12 October 2026
Website

What it is

Fly.io runs apps on Fly Machines: Firecracker microVMs on physical servers that Fly.io owns, in 17 regions. fly launch scans your source code, can generate a Dockerfile for frameworks such as Phoenix, Laravel, Rails and Django, and writes a fly.toml config; fly deploy builds the image and rolls it out; fly scale count 3 --region iad,fra,sin spreads Machines across cities. Under Fly Launch sits the Machines API, a REST API for creating, starting, stopping and destroying individual VMs, which you can also call directly.

Every app gets shared IPv4 and IPv6 addresses announced over BGP Anycast from all of Fly.io’s data centers, so a user’s connection lands at the nearest one. A Rust proxy on every server terminates TLS and forwards the connection to the closest running Machine, over WireGuard if it is in another region. The proxy can also stop or suspend idle Machines and start them again when requests arrive; a stopped Machine boots in well under a second, and while stopped you pay only for its root filesystem.

A Machine’s root filesystem is ephemeral. For data that must survive, a Fly Volume is a slice of an NVMe drive on the same physical server, attached to one Machine and not replicated. Billing is per second for running Machines: the smallest, a shared-cpu-1x with 256 MB, costs $2.19 per 30 days. New organizations get a short trial but no free tier.

Why teams pick it

  • One app can run in many regions with one command, and Anycast sends each user to the nearest Machine
  • Any Docker image runs inside its own Firecracker microVM, a stronger boundary than containers sharing a kernel
  • Autostop and autostart cut the bill for quiet apps: a stopped Machine costs $0.15 per GB of root filesystem a month and restarts in under a second
  • The Machines API gives direct control of individual VMs, so you can build your own functions platform or per-user environments on it

Watch out for

  • Volumes live on one server in one region with no replication; if the drive fails that Machine goes down, so Fly.io tells you to run at least two and replicate data yourself
  • The ephemeral root filesystem is capped at 2,000 IOPS and 8 MiB/s whatever the Machine size
  • Autostop never creates Machines: the most that can run is the number you created, its stop loop runs every few minutes and stops at most one Machine per region per pass, and min_machines_running only applies in the primary region
  • No free tier for new organizations: the trial lasts 2 hours of Machine runtime or 7 days, then a credit card is required

Alternatives

What all platform as a service (paas) have in common →
AWS Elastic BeanstalkAWSUpload your code and Elastic Beanstalk builds the AWS setup to run it (EC2 instances, a load balancer, an Auto Scaling group) in your own account, where you can still see and change every piece.Azure App ServiceAzureAzure’s platform for web apps and APIs: you rent a pool of VMs called an App Service plan, and every app you put in it runs on those VMs without you managing them.Cloud FoundryOpen sourceAn open-source PaaS you run yourself: `cf push` uploads your code, a buildpack stages it into a droplet, and Diego keeps the requested number of instances running behind the Gorouter.DokkuOpen sourceA Heroku-like PaaS on one server of your own: `git push` to it, and Dokku builds the app with buildpacks or a Dockerfile and runs it in Docker containers behind nginx.Google App EngineGoogle CloudGoogle’s original platform as a service: describe your app in an `app.yaml`, run one deploy command, and Google runs and scales the instances.HerokuCommercialThe platform that defined PaaS: `git push` your code, and Heroku builds it with a buildpack and runs it on managed containers called dynos behind its own HTTP router.RenderCommercialRender builds and deploys web services, background workers, cron jobs and managed Postgres and Key Value stores from your Git repo, all described in one `render.yaml` file if you like.

How it fits with other technologies

Launch an app with flyctl and run it in three regions · bash

# Scan the source, write fly.toml (and a Dockerfile if needed)
fly launch

# Build the image and roll it out to the app's Machines
fly deploy

# Three Machines spread over Ashburn, Frankfurt and Singapore
fly scale count 3 --region iad,fra,sin

# Boot a throwaway VM with a shell, removed when you exit
fly machine run --shell

See it in a real stack

No architecture uses Fly.io yet. Drop it into the playground and wire it up yourself.Open playground →
Where it came from2017–2024

Kurt Mackey had helped build Ars Technica and spent much of that time making the site fast. A content delivery network made pages fast for anonymous readers, but paying subscribers wanted personalized pages and community features that the CDN couldn’t speed up, so they waited on servers far away (often in Virginia). The fix, Mackey argued, was to run the app itself close to users rather than bolt a CDN onto an app in one region.

Fly.io launched in 2017 and went through Y Combinator in Winter 2020. In the Launch HN post that March, Kurt, Jerome and Michael described it as “a platform to run Docker applications close to end users”: Fly.io converted a Docker image into a root filesystem, booted it in Firecracker VMs, and used a Rust router, Anycast IPs and a WireGuard mesh to send each user to the nearest VM, with three commands to deploy to 17 cities. The founders had grown up on Heroku and modeled deploys on it. For its first year the platform was that proxy plus a HashiCorp Nomad driver that started Firecracker.

In May 2022 Fly.io opened Fly Machines, VMs controlled by a REST API that boot in about 300 ms, built so apps could scale to zero. In 2023 it began moving apps from Nomad to flyd, its own orchestrator (internally “AppsV2”), because Nomad expected federated regional clusters and asynchronous placement, while Fly.io ran one global cluster of many small apps. In October 2024 it discontinued its plans with free allowances; new organizations now pay as they go.

Why it’s built this way

MicroVMs instead of containers
Fly.io runs many customers on the same hardware, and Thomas Ptacek wrote that Docker’s isolation “isn’t strong enough for that”, so it unpacks each container image into a Firecracker microVM instead.
Its own hardware, not another cloud
TechCrunch reported that most investors first thought running its own physical servers was silly, but came around once they saw it was cheaper than EC2 instances and let Fly.io control its costs.
Run the app near users instead of a CDN
Mackey called a CDN “a misfeature for most developers building dynamic applications”, because the app still runs in one region; Anycast plus a global proxy moves the whole app instead.
Create Machines ahead of time, start them on demand
Pulling a large image to a distant region can take minutes, so Fly.io made Machines cheap to keep stopped. Starting an existing Machine skips the slow part and makes scale to zero practical.

Timeline

  1. 2017

    Fly.io launches

  2. 2020

    Launch HN as part of Y Combinator Winter 2020: Docker apps in 17 cities on Firecracker

  3. 2022

    Fly Machines API: VMs that boot in about 300 ms

  4. 2023

    Apps start moving from Nomad to flyd, Fly.io’s own orchestrator

  5. 2024

    Plans with free allowances discontinued in October

Sources10 · facts checked 12 October 2026

Improve this page on GitHub