Updated: 2026-07-07

Fly.io is one of those platforms that easily splits opinions. Someone who discovers it because a colleague deployed an API in fifteen minutes and it works the same in Madrid and Sydney usually ends up delighted. Someone trying to build a complex application on top of it, with large databases, persistent storage, and many active regions, often runs into edges that demand reading docs and thinking the architecture through carefully. After several real projects on the platform through 2024 and 2025, this piece puts in writing what it does well, what is still fragile, and when it is worth choosing over more conventional alternatives.

Key takeaways

  • Fly.io brings your application up inside a Firecracker microVM in one of its regions, gives it an anycast IP, and places it behind its global network; deploying in multiple regions is fly scale count 3 --region mad,gru,sin.

  • The ideal use case is stateless or lightly stateful applications wanting to serve low latency to globally distributed users.

  • In 2024 Fly pulled out of the managed-database business; a later partnership with Supabase to manage Postgres on Fly was itself discontinued in April 2025, so the sturdiest path today is an external provider like Neon.

  • The platform has had non-trivial public incidents in 2023 and 2024; the team’s transparency with detailed postmortems is a positive point.

  • A classic VPS on Hetzner is still cheaper for applications that don’t need real multi-region.

What it offers and how it differs

Fly.io brings your application up inside a Firecracker microVM in one of its regions, gives it an anycast IP, and places it behind its global network. That means when a user’s DNS resolves the domain, traffic lands in the physically closest region, and from there the response can be served directly or routed to whichever region actually holds the process that must handle it.

The promise is that deploying in multiple regions is as simple as running fly scale count 3 --region mad,gru,sin, and in most cases the promise holds.

Behind that friendly interface lives an architecture that is not trivial: Firecracker as isolator, WireGuard as the internal network layer, a custom proxy called fly-proxy that receives traffic and forwards it, persistent volumes anchored to a specific region, and a control plane aware of the full topology. Fly’s own architecture documentation[1] puts it plainly: "every server in our infrastructure runs a Rust-based proxy named fly-proxy, responsible for accepting client connections, matching them to customer applications, applying handlers (eg: TLS termination), and backhaul between servers." Not magical, but well packaged.

The clearest difference against a classic provider like AWS or GCP is that Fly.io is built from day one for your application to live in multiple regions at once without that costing a large engineering effort. The big providers also support multi-region, but it usually means setting up virtual private networks, global load balancers, manual database replicas, and a healthy dose of Terraform.

Where it works well

Fly.io’s ideal use case is stateless or lightly stateful applications wanting to serve low latency to globally distributed users. SaaS product APIs, server-rendered websites, payment gateways with global users, mobile app backends: all of these benefit massively from Fly’s model.

Another case that works well is internal applications where you want a geographically distributed team to get fast access. An internal office tool with employees in Madrid, Buenos Aires, and Singapore will respond better with an instance on each continent than with everything running out of Virginia.

Pricing is competitive for small and medium workloads. Plans with free allowances were retired in October 2024, and everything since then is billed on actual usage; according to Fly’s own pricing breakdown[2], a minimal shared-cpu machine still costs a little over two dollars a month running always-on, and bills by the second if it shuts itself down when there is no traffic. For a side project or an early-stage company, keeping a global API with three regions for a figure around fifteen to twenty dollars a month is still realistic.

Where it gets complicated

The first challenge shows up with state. Fly Volumes are persistent volumes anchored to a specific region, not automatically replicated. If your multi-region application needs local persistence, each region gets its own independent volume, and the coordination is on you.

For PostgreSQL, Fly retired its managed-cluster product in 2024 and switched to recommending Postgres as a regular app, with an explicit warning that this is not a managed database[3]: if it runs out of memory or disk, getting it back is your job. They then tried a partnership with Supabase to manage Postgres on Fly, which Supabase itself discontinued in April 2025[4], so the middle ground has been unstable. Today the sturdier alternative is still an external provider like Neon. This makes sense for Fly but shifts operational work, and some continuity risk, onto whoever is deploying.

The second challenge is observability and diagnostics when something goes wrong. Fly exposes basic logs and metrics, but the experience of debugging a rare failure in one of fifteen regions is not as solid as AWS with CloudWatch. There are integrations with Grafana, Datadog, and similar tools that improve the experience, but you have to configure them.

The third challenge is that the platform has had non-trivial public incidents in 2023 and 2024, some with multi-hour outages affecting entire regions: an expired certificate broke the orchestration system for over six hours in October 2024, and a concurrency bug in fly-proxy took down request routing in September of the same year. Fly’s public incident history[5] documents these and other episodes with dates and durations. The team has been transparent with detailed postmortems, but if your application is critical you have to assume that risk exists and have a contingency plan.

Comparison with nearby alternatives

Railway and Render are the most direct competitors in the modern-platform segment. Railway is excellent on developer experience and managed databases but essentially lives in one central region. Render offers a similar range but is also focused mainly on single or dual regions. Neither really competes with Fly.io on the global-deployment axis; we cover that same comparison in Railway and Render: deployment platforms without surprises.

Against Kubernetes plus operators, the difference is stark: Fly hides almost all the complexity and you write a fifty-line file. For most projects that are not huge, the math favors Fly; for the ones that are, Kubernetes wins on flexibility and on not being tied to one provider, especially if the team already operates its own clusters, as we discuss when reviewing the operational balance sheet of Kubernetes 1.35.

A classic VPS on Hetzner or OVH remains reasonable for many applications. If you don’t need multi-region, if your application lives in one geographic domain, if you want full control over the operating system, a well-configured VPS running Docker Compose (or a layer like the one we describe in how to install Coolify on Docker) is perfectly viable and much cheaper. Fly.io shines when the globalness requirement is real, not when it has been bolted on as fashion.

Minimal deployment example

app = "mi-api"
primary_region = "mad"

[build]
  image = "ghcr.io/org/mi-api:1.4.0"

[[services]]
  internal_port = 8080
  protocol = "tcp"
  auto_start_machines = true
  auto_stop_machines = true
  min_machines_running = 0

  [[services.ports]]
    port = 443
    handlers = ["tls", "http"]

That file, plus a fly deploy, puts the application in Madrid. Adding Brazil and Singapore is fly scale count 3 --region mad,gru,sin. From a developer-experience standpoint, that simplicity is hard to beat.

My take

Fly.io is a very good tool for a specific kind of project: small or medium applications, with a real requirement to serve globally distributed users, without complicated local state (or with state pushed out to managed services), and with a small team that doesn’t want to spend time operating infrastructure. For that profile, Fly is probably the best option available in 2025, especially combined with an external managed database like Neon or PlanetScale.

Outside that profile, things get harder. Applications with heavy local state, strict regulatory requirements on data residency in specific countries, heavy data workloads, or complex orchestration needs fit better with classic providers or managed Kubernetes.

The question worth asking before moving a project to Fly.io is whether globalness is a real requirement measured in minutes of improvement for the user, or an aesthetic aspiration. When it’s real, Fly.io saves weeks of work and months of operational complexity. When it isn’t, it introduces a new provider with its own mental model without delivering enough value.

Conclusion

That distinction, drawn honestly, separates happy Fly deployments from those that end up regretting it six months in.

This article is also available in Spanish: Fly.io: desplegar globalmente sin complicarte.

Sources

  1. architecture documentation
  2. own pricing breakdown
  3. this is not a managed database
  4. discontinued in April 2025
  5. public incident history