TL;DR:
- Fly.io deploys Docker containers to 30+ regions globally, routing users to the nearest healthy instance via Anycast
- Fly Machines are lightweight VMs that start and stop programmatically — useful for on-demand compute at the edge
- Sits between Cloudflare Workers (serverless JS/WASM only) and self-managed Kubernetes (full control, full complexity)
Edge computing means different things depending on who you ask. In IoT, it means compute physically close to sensors and machines. In web application development, it usually means running your application server in multiple regions worldwide so users get low latency regardless of where they are. That second definition is what Fly.io is built for.
The case for running at the edge is straightforward. A user in Singapore hitting a server in Virginia adds 150–200ms of round-trip latency before the server has even started doing work. For API responses, database queries, and real-time features, that adds up fast. Fly.io’s answer is to run your container in 30+ regions simultaneously and route each user to the nearest one.
How Fly.io works
The core unit is a Fly Machine — a lightweight virtual machine that runs a Docker container image. When you deploy an app to Fly.io, you give it a Docker image and a configuration file (fly.toml), and Fly distributes it across whichever regions you specify.
Anycast handles routing: Fly.io uses a single IP address that routes to the geographically nearest point of presence. Users don’t need to know which region they’re hitting — the infrastructure handles it transparently. If a region is down or unhealthy, traffic automatically fails over.
The flyctl CLI handles most operations:
# Deploy your app to all configured regions
fly deploy
# Add a region
fly regions add sin # Singapore
# List running machines
fly machines list
# Scale to N instances in a region
fly scale count 3 --region lhrThe deploy process pushes your Docker image to Fly’s registry, distributes it to your target regions, and brings up instances. Typical deploy times are 30–60 seconds for a simple application.
Fly Machines: on-demand compute
Fly Machines can be started, stopped, and controlled programmatically via the Machines API. This is useful for workloads that don’t need to run continuously — spinning up a machine to process a job, then stopping it when done.
The practical applications at the edge are things like: image processing triggered by a webhook, a function that needs more memory or CPU than a serverless environment provides, or batch jobs that should run near a specific data source. You pay for machine-seconds rather than maintaining a fleet of always-on instances.
Cold starts are fast by traditional VM standards — typically under a second — because Fly Machines don’t boot a full OS from scratch. They’re essentially snapshots that resume rather than fresh boots.
What makes it different from Cloudflare Workers
Workers is Fly.io’s closest conceptual neighbour for edge deployment, and the difference matters depending on what you’re building.
Cloudflare Workers runs JavaScript and WASM in V8 isolates. The model is serverless: your code handles a request and returns a response, with no persistent state (beyond KV, Durable Objects, etc.). Cold starts are sub-millisecond. The constraint is that you’re working within a sandboxed JS environment — no arbitrary binaries, limited standard library, specific APIs.
Fly.io runs full containers. You can use any language, any binary, any runtime. You can run a Rust server, a Go binary, a Node.js app with native modules, or a Python service with C extensions. You have persistent volumes for local storage. You have more control over resources.
The trade-off is that containers are heavier than V8 isolates. Fly.io’s cold starts are fast for VMs, but not as fast as Workers’ instantaneous invocation. And deploying a new version to 30 regions in Fly.io takes minutes, while a Workers deploy is global in seconds.
Which fits depends on what you’re running. Simple request/response logic without native dependencies? Workers is simpler and cheaper. A full application server, a background service, or anything with native binaries? Fly.io handles it where Workers can’t.
Persistent storage and databases
One of the practical advantages for real applications is Fly Volumes: persistent block storage attached to specific Machines. This enables running stateful services at the edge — a database replica close to users, a cache that persists across restarts, or a full database where you want the data to live in a specific region.
Fly also runs Postgres on its infrastructure through Fly Postgres, which is a configuration of Postgres on Fly Machines rather than a managed database service. You get full control over the instance and the data, at the cost of managing the database yourself.
For latency-sensitive applications where you want both compute and data close to users, running Fly Machines alongside Fly Postgres in the same region is a legitimate architecture — not just theoretical.
When to use it
Fly.io is well suited for:
Latency-sensitive APIs where serving from a single region would be noticeably slow for international users. Chat applications, gaming backends, real-time collaboration tools.
Full application servers that don’t fit the Workers/Lambda serverless model — anything that needs persistent connections, background threads, or native binaries.
Regional data residency — if you need user data to stay in specific regions for regulatory reasons, Fly gives you explicit region control.
Replacing a VPS — a single-region Fly.io deployment is a reasonable alternative to a DigitalOcean or Linode VPS, with the ability to expand to more regions later without rearchitecting.
It’s less suitable for truly serverless workloads where you want to pay nothing at idle, or for anything that needs the very lowest possible latency (where Workers or Durable Objects are faster).
The learning curve is low. If you can write a Dockerfile, you can deploy to Fly.io. The move from one region to many regions is a configuration change rather than a new architecture — which is most of the appeal.