Fly.io, list all regions available

To list all the regions available on Fly.io, run fly platform regions in your terminal. The same list also lives in the docs, at https://fly.io/docs/reference/regions/.

fly platform regions

The command prints a table with every region: a three-letter code and the city it maps to. Codes like ams for Amsterdam, fra for Frankfurt, iad for Ashburn (Virginia), lhr for London, gru for São Paulo, syd for Sydney.

If your CLI is installed as flyctl, that works too. fly and flyctl are the same binary.

Why do these codes matter?

Fly.io runs your app as machines placed in specific regions, and everything region-related in the platform uses these codes.

You’ll find one in your fly.toml, deciding where new machines get created by default:

primary_region = 'fra'

You’ll type them when scaling to more regions:

fly scale count 2 --region ams

And fly status shows which regions your machines are currently running in, using the same codes.

So when you set up a new app, this list is the first thing to check. Pick the code closest to your users and put it in primary_region.

How to pick a region

The obvious instinct is to pick the region closest to you. Resist it. Pick the one closest to your users, which for a public app is often not the same place.

There’s a bigger trap, though: putting your app machines far from your database. If your Postgres runs in fra and you scale app machines into sjc, every single query crosses the Atlantic and back. A page that fires ten queries pays that latency ten times, and the app feels slow even though every machine is healthy.

The fix is to keep app machines in the same region as the database. Only spread the app to other regions once you have a plan for the data too, like read replicas in those same regions.