Fly.io Regions, Deployment & Data Residency 2026
Fly.io runs 18 regions, with Anycast routing each request to the nearest Machine. Volumes pin to their region; five EU regions cover residency.
Fly.io Regions & Deployment verdict
Fly.io runs 18 regions across six continents on its own hardware.
A global Anycast network routes each request to the nearest running Machine, and 13 regions act as WireGuard gateways for private networking. You set primary_region in fly.toml, then add regions with fly scale count or fly machine clone.
Set primary_region near your users and database, then add regions with fly scale count for global reach and let Anycast route to the nearest Machine. One trap sits in the warm floor. It is per-primary, so keep min_machines_running at 1 or more in each latency-sensitive region, not just the primary, or the others cold-start. For EU residency, pin to ams, fra, cdg, arn or lhr. Verify HIPAA or GDPR needs directly, since the docs only document SOC 2.
- Volumes and Machines pin to their creation region. Moving a stateful service means recreating it elsewhere.
- min_machines_running keeps a warm Machine only in the primary region, so other regions can still cold-start under auto-stop.
- Fly.io documents SOC 2 Type 2 and ISO 27001 datacenters, but no explicit HIPAA or GDPR page, and no published numeric SLA.
- Regions
- 18
- Gateway regions
- 13
- EU regions
- 5
- Routing
- Anycast nearest
- Region binding
- Volumes pinned
This page covers where Fly.io deploys and how residency works. Performance and pricing live on their own pages.
Pick your Fly.io region and deployment
18 regions across 6 continents · nearest failover ewr · residency: ams, arn, cdg +2
Set iad as the primary region and keep a warm floor there in fly.toml.
app = 'my-app'
primary_region = 'iad'
[http_service]
internal_port = 8080
auto_stop_machines = 'stop'
auto_start_machines = true
min_machines_running = 1Fly Proxy routes each request to the nearest running Machine over Anycast, and auto-starts stopped Machines on demand. min_machines_running keeps a warm floor only in the primary region; volumes and Machines are pinned to their region.
Real Fly.io regions and deployment commands. Confirm residency guarantees against your contract.
Deploy Fly.io: fly.toml, flyctl and Machines API
primary_region sets where new Machines are created (and FLY_PRIMARY_REGION). [http_service] holds the auto-stop policy: auto_stop_machines (off | stop | suspend), auto_start_machines and min_machines_running (a warm floor in the primary region). concurrency soft/hard limits drive when Fly Proxy adds capacity. [[vm]] picks the Machine size.
app = 'my-app'
primary_region = 'iad'
[build]
dockerfile = 'Dockerfile'
[http_service]
internal_port = 8080
force_https = true
auto_stop_machines = 'stop' # off | stop | suspend
auto_start_machines = true
min_machines_running = 1 # warm floor in the primary region
[http_service.concurrency]
type = 'requests'
soft_limit = 25
hard_limit = 50
[[vm]]
size = 'shared-cpu-1x'
memory = '512mb'fly launch generates the app and fly.toml; fly deploy ships it. fly scale count places Machines across regions (pre-creating the capacity Fly Proxy can auto-start), and fly machine clone --region copies a Machine into another region for multi-region reach.
# Create and deploy
fly launch
fly deploy
# Place Machines across regions (pre-create capacity)
fly scale count 4 --region iad,lhr
fly scale count 11 --max-per-region 5
# Clone a Machine into another region
fly machine clone --region syd <machine_id>
# Inspect placement
fly scale show
fly regions listThe Machines REST API at api.machines.dev creates and controls Machines directly with a Bearer token. POST to /v1/apps/{app}/machines with a guest object (cpu_kind, cpus, memory_mb) or a named size. Rate limit is 1 request/second per action, burst 3.
export FLY_API_HOSTNAME='https://api.machines.dev'
export FLY_API_TOKEN=$(fly tokens deploy)
curl -i -X POST \
-H "Authorization: Bearer ${FLY_API_TOKEN}" \
-H "Content-Type: application/json" \
"${FLY_API_HOSTNAME}/v1/apps/my-app/machines" \
-d '{
"region": "lhr",
"config": {
"image": "registry-1.docker.io/library/nginx:latest",
"guest": { "cpu_kind": "shared", "cpus": 1, "memory_mb": 256 }
}
}'Fly.io regions and locations
| Region | Location | WireGuard gateway |
|---|---|---|
| iad | Ashburn, Virginia, USA | Yes |
| ewr | Secaucus, NJ, USA | Yes |
| ord | Chicago, Illinois, USA | Yes |
| dfw | Dallas, Texas, USA | Yes |
| lax | Los Angeles, California, USA | Yes |
| sjc | San Jose, California, USA | Yes |
| yyz | Toronto, Canada | Yes |
| gru | Sao Paulo, Brazil | No |
| lhr | London, United Kingdom | Yes |
| ams | Amsterdam, Netherlands | Yes |
| cdg | Paris, France | Yes |
| fra | Frankfurt, Germany | Yes |
| arn | Stockholm, Sweden | Yes |
| bom | Mumbai, India | Yes |
| sin | Singapore | Yes |
| nrt | Tokyo, Japan | Yes |
| syd | Sydney, Australia | Yes |
| jnb | Johannesburg, South Africa | No |
Fly.io region selection and routing
| Aspect | Behavior | Notes |
|---|---|---|
| Primary region | primary_region in fly.toml | Default for new Machines; sets FLY_PRIMARY_REGION |
| Add a region | fly scale count --region | --max-per-region caps Machines per region |
| Clone to a region | fly machine clone --region | Copies a Machine into another region |
| Request routing | Anycast, nearest Machine | fly-replay header for dynamic routing |
| Warm floor scope | Primary region only | min_machines_running has no effect on other regions |
| Region binding | Volumes + Machines pinned | Tied to the region they're created in |
Fly.io data residency and compliance
| Control | Option | Notes |
|---|---|---|
| EU regions | ams, arn, cdg, fra, lhr | Pin Machines and Volumes for EU residency |
| Infrastructure | Own hardware, ISO 27001 DCs | Firecracker microVMs, no shared kernels |
| Compliance | SOC 2 Type 2 + BAAs | Explicit HIPAA/GDPR pages not found in docs |
| Private network | 6PN WireGuard mesh | All intra-network traffic encrypted |
| Encryption | Encrypted volumes + TLS | Keys in redundant secret storage |
What to verify before you commit to Fly.io
- Volumes and Machines are tied to the region they are created in, so moving a stateful workload across regions means recreating it and migrating data
- min_machines_running keeps a warm Machine only in the primary region, so secondary regions can still cold-start under auto-stop unless you size capacity there
- Fly.io documents SOC 2 Type 2, ISO 27001 datacenters and BAAs, but no explicit HIPAA or GDPR compliance page was found in the docs, so confirm regulated requirements directly
- Fly.io publishes no numeric uptime SLA, so region availability carries no contractual guarantee
Fly.io Regions & Deployment FAQ
How many regions does Fly.io have?
Eighteen, across six continents. North America has seven: iad, ewr, ord, dfw, lax, sjc, yyz. Europe adds lhr, ams, cdg, fra, arn. Asia has bom, sin, nrt, with gru in South America, syd in Oceania, jnb in Africa. Thirteen are WireGuard gateway regions, and apps reach the nearest running Machine through a global Anycast network.
How do I deploy to multiple regions on Fly.io?
Set primary_region in fly.toml for default placement, then add regions with fly scale count <n> --region iad,lhr, which pre-creates Machines, or fly machine clone --region syd <id>. Fly Proxy never creates Machines on its own, so you provision capacity per region. Anycast then routes each request to the nearest running Machine, and the fly-replay header lets you override routing.
Does Fly.io support EU data residency?
Yes, through five European regions: ams in Amsterdam, arn in Stockholm, cdg in Paris, fra in Frankfurt, lhr in London. Pin Machines and Volumes there for EU residency. Fly.io runs its own hardware in ISO 27001 datacenters, is SOC 2 Type 2 certified and signs BAAs. The docs harvested published no explicit HIPAA or GDPR page, so verify regulated needs directly.
Are Fly.io Machines tied to a region?
Yes. Both Fly Machines and Fly Volumes are tied to the region they are created in, and the active region shows up at runtime in the FLY_REGION environment variable. Moving a stateful workload to another region means creating new Machines and a new volume there and migrating the data, rather than relocating the existing ones.
Does auto-stop affect every region?
Auto-stop applies wherever Machines run, but the warm floor does not. min_machines_running keeps running Machines only in the app's primary region. Secondary regions can still scale to zero and cold-start on the next request. For low latency in several regions, size enough always-on capacity in each, not just the primary.
Sources & verification
| Source | What was checked | Last checked |
|---|---|---|
| Fly Official | Official product page | July 10, 2026 |
| Fly Api Working With Machines Api | API Working With Machines API | July 10, 2026 |
| Fly Launch Autostop Autostart | Launch Autostop Autostart | July 10, 2026 |
| Fly Launch Scale Count | Launch Scale Count | July 10, 2026 |
| Fly Networking Private Networking | Networking Private Networking | July 10, 2026 |
| Fly Reference Configuration | Configuration | July 10, 2026 |
| Fly Reference Regions | Regions and residency | July 10, 2026 |
Every fact on this Fly.io page is tied to a named source and a verification date. Freshness-sensitive figures trace to the sources above; verify against the vendor before relying on them.
Explore Fly.io
Every page on Fly.io in one place, you are on regions & deployment.
Snapshot, score and verdict
You are here
Latency, throughput, uptime and behaviour under scale
Every tier and the entry price
Compared and ranked vs peers
Price and feature change history
Browse the full Cloud Hosting category