Fly.io: Application platform

Explore Fly.io’s application hosting and Machines, with practical context on deployment regions, persistent data and the difference between compute and caching.

Updated 8 September 2026

What Fly.io runs

Fly.io is an application platform built around Fly Machines. It provides tools for launching applications, configuring secrets, sizing machines and managing their lifecycle. Its documentation covers several language ecosystems, including Rails, Elixir, JavaScript, Python and Laravel.

This makes the application process part of the deployment model. A team is deploying runnable software, rather than only handing a directory of static pages to a CDN. The public proxy routes traffic to that software.

Placing compute near its dependencies

Choosing an application region is only one part of placement. Consider where the database and external services run as well as where visitors are located. A page may need several backend calls before it can respond.

For example, moving an API closer to a user could still leave each database query crossing a long distance. Measure the complete request path. An edge connection that establishes quickly does not necessarily mean that the application’s data is nearby.

Machines, private networks and persistent services

Fly Machines provides virtual machines that can be managed through an API as well as the deployment tools. This supports web applications and other workloads that need a process rather than just a static deployment. Private networking connects services, while Fly Proxy handles public routing.

Fly Volumes supplies persistent storage attached to Machines, and Managed Postgres provides a managed database option. Storage placement remains part of the architecture: running an application in several regions does not automatically replicate every attached volume. A stateful service needs an explicit data and recovery strategy.

Planning a production application

Fly.io documents machine state, restart policy, sizing and managed database options. Use those controls as part of a deployment plan that also accounts for application startup, health checks and persistent data.

Before adding instances, determine how they share state. Uploads, sessions and database writes need a defined home. Test a restart and a replacement deployment so that a working process is not mistaken for a durable storage strategy.

How DNSTrace.dev detects Fly.io

Detection correlates independent public signals. A single match is reported as strong evidence; agreement between a response header and the announcing network is reported as confirmed.

fly-request-id — Per-request identifier appended by the Fly proxy.
fly-region — The three-letter code of the region that handled the request.
CNAME targets under fly.dev — The default application hostname before a custom domain is attached.
Shared anycast A and AAAA records — Fly issues anycast addresses that several applications can share, so an address alone does not isolate one app.

What a detection proves

The request was routed by the Fly.io proxy, and the named region served it.

What it does not prove

Which application or organisation owns the instance, or whether the application also runs in other regions that did not answer this request.

Common questions about Fly.io

Is Fly.io a CDN or an application host?

Fly.io runs application workloads on Machines and provides the networking that exposes them. Hosting a running application is different from caching its responses; a Fly.io deployment does not imply that every response is cached.

What does fly-region tell me?

It names the Fly.io region that served this specific request. A different region may answer the same hostname from another part of the world.

Can two sites share a Fly.io address?

Yes. Fly anycast addresses are shared, so reverse lookups and address matching cannot attribute an address to a single application.

Frontend application platform