Dora NodaFly.io spent years selling developers one irresistible idea: run your app close to your users, in 30-plus regions around the world. Then, in September 2025, it deleted 17 of those regions. If your app lived in Santiago, Bogotá, Buenos Aires, Rio de Janeiro, Hong Kong, Montreal, Seattle, Boston, or nine other cities, your region simply stopped being offered — and your app had to move whether the move suited you or not.
Here is the whole story on one map — every region that died, where tenants were told to go, what the forced move actually required, and why "the vendor can delete your region" belongs on your exit-strategy checklist next to price hikes and feature deprecations:
| What died | Where tenants were sent | Why it stung |
|---|---|---|
| 4 South American regions: Bogotá (bog), Ezeiza/Buenos Aires (eze), Rio de Janeiro (gig), Santiago (scl) | São Paulo (gru), the continent's only remaining region | An entire continent's edge presence collapsed to one city; every other South American deployment now crosses the Andes |
| Hong Kong (hkg) | Tokyo (nrt), Singapore (sin), or Mumbai (bom) | The Greater China-adjacent presence vanished; the nearest options are all a sea crossing away |
| Both Mexican regions: Guadalajara (gdl), Querétaro (qro) | Nearest US regions (Dallas, Los Angeles, Chicago) | Mexico went from two regions to zero — there is no longer any Fly.io compute in the country |
| 6 US regions: Atlanta, Boston, Denver, Miami, Phoenix, Seattle | Dallas (dfw), Secaucus (ewr), Ashburn (iad), LA (lax), Chicago (ord), San Jose (sjc) | The US map thinned to coastal hubs plus Dallas and Chicago; the Southeast, Mountain West, and Pacific Northwest lost local compute |
| Montreal (yul) | Toronto (yyz) | Canada's French-speaking business center lost its local region |
| 3 European regions: Madrid (mad), Bucharest (otp), Warsaw (waw) | Paris, Frankfurt, Amsterdam, London, Stockholm | Eastern and Southern Europe thinned out; Bucharest tenants learned about it from a failed deploy (below) |
Thirty-five regions became eighteen. The rest of this post covers what the move cost the tenants who had to make it, why regions die, and the checklist item this whole episode earns.
What the forced move actually required
Credit where it is due: Fly.io did not just switch the regions off. The Region Consolidation Project announcement offered two paths — Fly migrates most apps automatically, or tenants migrate manually — and published per-region destinations plus a migration guide. For a stateless app, the manual path really was close to what the docs promised: update primary_region in fly.toml, scale up in the new region, scale down in the old one.
But "most apps" was doing a lot of work in that sentence, and the exceptions were exactly the apps with the most to lose. Three categories of tenant paid real costs:
Apps with volumes paid a storage migration. Moving a stateless machine is a config change; moving state is a procedure. Fly's own guidance told volume owners to stop their existing machines, fork each volume into the new region, and create new machines from the forked volumes. Every step of that is downtime-shaped: stopped machines serve no traffic, forks copy data across long-haul links on somebody else's schedule, and the cutover has to be sequenced by hand. A Postgres cluster on Fly volumes in Santiago was not "seamlessly migrated" — it was stopped, copied across a continent, and restarted.
Apps with region-specific logic paid a rewrite. Fly flagged this one explicitly: if your app referenced its region — routing rules, FLY_REGION checks, multi-region Postgres replica roles, any "if I am the primary in bog" branching — the automatic migration could not fix your code. You had to audit every region assumption, rewrite it against the new region code, and test a topology you never chose.
Multi-region tenants paid in topology. Anyone running Bogotá plus São Paulo as a failover pair, or spreading across the US Southeast for redundancy, lost the shape of their own architecture — not one deployment but the relationship between two. Redundancy you designed is redundancy you now have to re-derive in cities you did not pick.
Everyone paid attention, on a vendor's timetable. The migration happened when Fly said so. Even a short move cost real work: one public commit log shows a team shifting Boston (bos) to Secaucus (ewr) — a few hundred kilometers — and still touching production and app config files to re-pin the region. And the rough edges showed up in public: in October 2025, a tenant hit Region otp is deprecated and cannot have new resources provisioned in the middle of an important deployment — learning from an error message, not the announcement email, that Bucharest was gone. Around the same time, flyctl platform regions was still listing dead regions like Hong Kong and Seattle as if they were available, so the CLI and the changelog disagreed about what the platform even was. None of this was catastrophic. All of it was the tenant's time, spent on a move the tenant never requested.
Why regions die
Regions die for the same reason free tiers die: the thing that won the customers became the thing that cost the money. Fly.io's entire pitch — the reason developers picked it over Heroku and Render — was the map. The company launched in 19 regions, expanded past 33, and raised $70M in June 2023 on the promise that a lone developer could run code next to users anywhere. Every region on that map was physical capacity: servers, contracts, power, support for hardware the company did not own in cities where it had no staff.
Then came the retrenchment sequence. Free allowances for new organizations were removed in October 2024. LiteFS Cloud was sunset the same month. And in September 2025, the region map itself was cut nearly in half. Each step was individually reasonable — capacity planning, focus, unit economics. Taken together, they trace a company discovering which parts of its launch pitch it could afford to keep. The edge footprint was the marketing; consolidating it was the margin.
This is not a Fly.io indictment. It is the structural shape of the business. Any vendor that rents you presence in cities where you have no machines of your own is making a bet that enough tenants want each city to cover its cost. When that bet stops paying in Querétaro or Bucharest or Miami, the region goes — and your deployment topology, which you designed around that bet, goes with it. The question was never whether some vendor would do this. It is whether your architecture notices before your deploys start failing.
Region removal is its own lock-in category
Platform teams already keep two checklists for vendor risk: what happens if the price changes, and what happens if the feature you depend on is deprecated. Region removal belongs on a third line, because it behaves differently from both:
Unlike a price hike, you cannot pay your way out. A 30% price increase is painful but legible — you budget, you optimize, you decide. A deleted region offers no tier that keeps it. There is no enterprise plan that brings back Santiago. The only response the vendor accepts is movement.
Unlike a feature deprecation, it moves your compliance posture, not just your code. Teams pick regions for latency and for data locality — regulatory, contractual, or customer-promised. An app that lived in Montreal for Canadian data-residency reasons and wakes up in Toronto is probably still compliant, but "probably" is doing compliance work the tenant never signed up for. An app that lived in Hong Kong to serve users across the border now serves them from Tokyo, and no code change fixes what that does to round-trip time or to the story you told your customers about where their data rests.
Unlike either, it compounds. Price hikes hit your bill; feature removals hit your roadmap. A region removal hits your latency, your data story, your failover topology, and your on-call runbooks in one changelog entry — and the labor of absorbing all four lands on your team, on the vendor's schedule.
That compounding is what makes "the vendor can delete your region" the entry most exit checklists are missing. Price changes and feature sunsets are negotiated, grandfathered, phased. Regions are just gone.
Put it on the exit checklist
So here is the reusable version — four questions to ask any platform before you pin a region, plus the structural answer that ends the questionnaire:
- Can this region disappear by vendor decision? If yes, what notice, what migration tooling, and what happens to volumes — not just machines?
- Which of my region choices are load-bearing? Latency-sensitive users, data-locality promises, region-branching code — inventory them before the vendor's email, not after.
- What does a forced cross-region move cost me in downtime? Stateless apps move in minutes; volume-backed state moves in maintenance windows. Price the worst case, not the demo.
- Who chooses the destination? Fly.io picked sensible consolidation targets. But "sensible" was the vendor's judgment about the vendor's capacity map — São Paulo for all of South America, nothing for Mexico. Your users were not in the meeting.
And the structural answer: on machines you own, regions do not get deleted by changelog. A Hetzner region you chose is still there next quarter, because nobody's unit-economics review can remove a server you rent directly. That is the actual line between renting presence and owning placement — not performance, not price, but who gets to decide that a city stops existing for your app.
This is the bet a self-hosted, Cluster-API-based platform makes explicit: your fleet runs on nodes you picked in regions you picked, reconciled from manifests you wrote. The vendor cannot deprecate your region because there is no vendor between you and the machine. The migration stories above — the stopped volumes, the rewritten region branches, the deploy that failed because Bucharest was gone — are all downstream of one architectural fact: somebody else owned the map.
Fly.io handled its consolidation about as gracefully as a forced migration gets — published destinations, automatic moves for simple apps, honest docs for the hard cases. The lesson is not that Fly.io is untrustworthy. It is that graceful or not, the move was mandatory, and mandatory moves are the ones your architecture should never be able to receive.
Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own, in regions you chose. Star the repo on GitHub or deploy your first app today.
