Fly.io

Definition: A platform that runs apps as lightweight VMs close to users worldwide, positioned as a modern alternative to both traditional cloud VMs and edge-function platforms. Founded in 2017 by Kurt Mackey and Jerome Petazzoni, the latter previously well known for his work and writing on Docker, Fly.io built its platform around Firecracker microVMs to combine real VM isolation with near-serverless boot speed. It has increasingly positioned itself around stateful, multi-region workloads — persistent connections, distributed databases — that don’t fit neatly into a pure edge-function model.

Core Services & Concepts

Fly Machines — Virtual Machines (VMs), fast-booting micro-VMs via Firecracker, the same technology AWS Lambda uses under the hood, that start in a few hundred milliseconds and can scale to zero
Anycast networking — Content Delivery Network (CDN) and Edge Computing, a single anycast IP automatically routes each user to their nearest healthy running instance across dozens of regions
Fly Volumes — Cloud Storage Systems, persistent, region-pinned block storage that can be attached to a Machine for stateful workloads
6PN private networking — a WireGuard-based private IPv6 network connecting all of an organization’s apps and Machines without exposing them publicly
LiteFS — an open-source distributed SQLite replication tool built by Fly.io, letting a lightweight SQLite database run replicated across multiple regions
Managed Postgres — regionally distributed Postgres clusters offered as a managed service on top of Fly Machines, an evolution from the earlier self-managed “Fly Postgres” app pattern

How Pricing Works

Usage-based, billed per Machine resource (vCPU/RAM allocation) and per second of run time, plus data transfer by region
No traditional generous free tier anymore — Fly.io moved to a model requiring a payment method on file, with a small monthly usage allowance
Volumes, Managed Postgres, and outbound data transfer are billed separately from compute
Machines can be configured to scale to zero when idle, meaning low-traffic apps can cost very little if configured correctly
Costs can be harder to predict than a flat-rate PaaS because they depend on region count, instance size, and how aggressively Machines scale up under load

Pros

Full VMs, not restricted like edge functions, but still deployed globally close to users across dozens of regions
Good fit for apps needing persistent connections like WebSockets or long-lived TCP connections at the edge, unlike most serverless/edge-function platforms
Fast Machine boot times make scale-to-zero genuinely practical without the multi-second cold starts typical of traditional VMs
6PN private networking and Volumes make it possible to run genuinely stateful, multi-service architectures across regions
Attractive to teams wanting infrastructure closer to raw compute than a PaaS while still avoiding the operational overhead of a hyperscaler

Cons

Smaller company and community than the major players, meaning fewer third-party tutorials and a smaller hiring pool of engineers who already know the platform
Less mature tooling and support for very large-scale enterprise needs compared to AWS, GCP, or Azure
No longer has a truly free tier, a payment method is required even for small hobby projects
Multi-region deployments shift real operational complexity, like data replication and regional failover, onto the developer rather than fully abstracting it away
Managed Postgres and other higher-level services are newer and less battle-tested than the equivalent offerings from Render, Railway, or the hyperscalers

Comparison: Fly.io vs Railway vs Render

	Fly.io	Railway	Render
Primary strength	Global VM deployment close to users	Simplest full backend + database hosting	Heroku-style PaaS with strong docs & IaC blueprints
Typical pricing model	Usage-based, billed per VM resource plus region	Usage-based, billed roughly per second	Free tier plus flat per-instance pricing
Best fit	Apps needing real multi-region presence or persistent connections	Full-stack apps needing a database alongside the app	Teams wanting a modern, well-documented Heroku replacement
API/product style	`fly.toml` plus CLI-driven deploys of Firecracker micro-VMs	Git-push deploys, Nixpacks, private networking	Git-push deploys, `render.yaml` Blueprints, managed Postgres

Best For

Apps needing real global presence with full VM flexibility, like WebSocket servers, multiplayer games, or latency-sensitive APIs
Teams that want more infrastructure control than a typical PaaS offers, without managing raw cloud VMs and networking themselves

Real Examples

Used by several dev-tool startups for globally distributed backend services
A common choice for real-time and WebSocket-heavy applications — chat, multiplayer, collaborative editing — that need low-latency connections worldwide
Popular with teams migrating off Heroku who specifically need multi-region deployment rather than a single-region PaaS

Use Cases

Globally distributed APIs
WebSocket and real-time servers
Latency-sensitive applications
Multiplayer games and collaborative-editing backends
Edge-adjacent workloads needing full VM capabilities, such as custom binaries or non-HTTP protocols, that a serverless function can’t run

Integration Notes & Common Pitfalls

Removing the free tier caught some long-time hobby users off guard, a payment method is now required to deploy even small apps
Volumes are pinned to a single region, running a truly multi-region stateful app requires explicit replication, such as LiteFS or Managed Postgres, rather than automatic cross-region storage
fly.toml and the flyctl CLI have a steeper learning curve than a pure git-push PaaS, reflecting the platform’s closer-to-the-metal positioning
Scaling to zero saves cost but reintroduces a cold-start delay on the next request, teams need to explicitly decide per-app whether always-on or scale-to-zero fits their latency requirements

Code Example

# fly.toml — app configuration for flyctl deploy
app = "my-app"
primary_region = "iad"

[build]

[http_service]
  internal_port = 8080
  force_https = true
  auto_stop_machines = true
  auto_start_machines = true
  min_machines_running = 0

[[vm]]
  cpu_kind = "shared"
  cpus = 1
  memory_mb = 256

FAQ

Is Fly.io serverless like Vercel Edge Functions? Not exactly — Fly Machines are full, fast-booting VMs rather than a restricted edge-function runtime, so they can run arbitrary long-lived processes and protocols, though they can also scale to zero similar to serverless when configured that way.

Does Fly.io still have a free tier? No longer a traditional always-free tier — a payment method is required, though a small monthly usage allowance and scale-to-zero configuration keep costs low for genuinely low-traffic apps.

Why would someone choose Fly.io over Railway or Render? Fly.io is the better fit when an app specifically needs multi-region presence, persistent connections like WebSockets, or lower-level VM control, Railway and Render are generally simpler for a single-region full-stack app with a database.

History

Founded in 2017 by Kurt Mackey and Jerome Petazzoni, the latter previously well known for his work and writing on Docker
Built its platform around Firecracker microVMs, the same lightweight virtualization technology AWS created for Lambda, to get VM isolation with near-serverless boot speed
Released LiteFS, an open-source distributed SQLite replication tool, reflecting its focus on making stateful multi-region apps practical
Removed its free tier and introduced Managed Postgres as the platform matured from a hobbyist-friendly edge-VM host toward a more complete production platform

Referenced by

Dig deeper

Spot an error in this note?