Gateways vs Fly.io
Fly.io is designed for running applications close to users on Fly’s global platform. It is compelling when your main concern is low-latency placement of app processes, machines, and volumes on Fly’s network. Gateways is not a replacement for a global app runtime. It is the operating layer for infrastructure in your own AWS, Azure, and GCP accounts: servers, scalable servers, databases, DNS, functions, storage, and the connections between them.At A Glance
| Decision area | Gateways | Fly.io |
|---|---|---|
| Infrastructure boundary | Your hyperscaler accounts | Fly platform |
| Primary workflow | Design and operate cloud resources | Run apps globally on Fly |
| Best fit | Multi-cloud operations, resource governance, architecture visibility | Global application runtime and regional placement |
| Source of truth | Cloud resources and connections | Fly apps, machines, regions, and volumes |
Choose Fly.io When
- Your application benefits from Fly’s global runtime and network model.
- You want app placement near users more than broad cloud resource management.
- Your infrastructure can be represented mostly as Fly apps, machines, and attached services.
Choose Gateways When
- Your infrastructure spans AWS, Azure, or GCP and must stay in those accounts.
- You need to operate more than containers: databases, DNS, firewalls, storage, functions, and scalable servers.
- You want teams to see the architecture as a connected map, not scattered provider consoles and scripts.
- You need direct cloud-provider control, including the ability to inspect instances, networking, billing, and SSH access outside the Gateways UI.
- You need workspace, project, environment, and API structure around cloud operations.