Your subscription has no region. Your apps do.

Until now, an app subscription here worked the way it works almost everywhere: you bought it in a region, and every app you deployed went there. Reasonable on day one, wrong by day ninety. The wiki wants to be near your team in Europe. The game server wants to be near the players, who are not your team. The client project wants to be near the client. One subscription, one region, and suddenly you are either buying capacity you do not need in a second location or putting an app an ocean away from its users. That coupling is gone. Your subscription has no region. Your apps do.

Capacity is just capacity

A subscription is now pure capacity -- CPU, RAM and disk with no location attached. It is not "4 GB in Detroit". It is 4 GB, and Detroit is a decision you make later, per app, as many times as you have apps.

Billing is unchanged. Same subscriptions, same prices, same renewal dates. Nothing about your invoice knows or cares where your apps landed. The region moved from being a property of what you buy to a property of what you deploy, which is where it always belonged -- location is a fact about an app's users, not about your wallet.

If you already have a subscription, nothing happens to it and nothing is asked of you. Your existing apps stay exactly where they are. The change shows up the next time you deploy: the wizard asks where this app should live, and the answer no longer has to match the last one.

Every app picks its own region

At deploy, each app chooses from three regions:

• US East -- Detroit. The right call for the American east coast and most of the central time zones.
• US West -- Los Angeles. The west coast, and the better half of the Pacific.
• Europe -- Amsterdam. European users, European latency, and data that stays on the continent.

There is a fourth option for when you genuinely do not care: Best available places the app on the emptiest host. Use it for the tools where latency is irrelevant -- an RSS reader does not mind an ocean. Pick a region deliberately when the app has users in a place; let the platform pick when it does not. Best available is also the honest default for the app you are just trying out: it will land somewhere with room, and if the experiment turns into something people use, the mover below exists for exactly that moment.

The distinction sounds small until you have lived without it. Latency is not a benchmark number; it is whether the wiki feels like a local file or a remote one, whether the game is playable, whether the client stops mentioning that the board "takes a second". Region choice per app means each of those gets the answer its users need, not the answer your first purchase happened to lock in.

One subscription can have apps spread across all three regions at once. A pool with a wiki in Amsterdam, an uptime monitor in Detroit and a game server in Los Angeles is one subscription, one invoice, one capacity number -- three continents' worth of placement without buying three of anything. The usual alternative is a subscription per region, each with its own headroom you are paying for and not using; here the headroom is shared, because the pool never cared where the apps went.

Moving an app later

Deploy-time choices age. The client's team grows a European office; the game's community turns out to be mostly west coast; the tool you deployed on Best available becomes the tool your whole team lives in. So a placement is not a life sentence: you can move a single app to a different region from its Resources tab.

The move carries what matters. The app's address comes with it. So does a custom domain if you attached one. So do the app's files -- all of them -- and your SFTP login keeps working on the other side. From the outside, the app is the same app in a different place; nothing that points at it needs to be updated.

Two honest caveats, stated up front because the panel states them too. The mover is in beta, and it asks for an explicit acknowledgment before it starts -- you are approving a real operation, not clicking through a formality. And the app is briefly offline during the data transfer: its files are being physically copied between regions, and we would rather pause the app than migrate a database while it writes. Pick a quiet hour for a busy app; for most apps the pause is the kind of thing only your uptime monitor notices.

Why there is no bulk mover

There is deliberately no "move everything to Amsterdam" button, and this is a choice, not a gap in the roadmap.

Moves are per-app decisions because placement is a per-app fact. Each app has its own users, its own tolerance for a pause, its own quiet hour. A bulk mover flattens all of that into one click -- it takes apps offline in a batch, on one schedule, for a decision that was probably only right for the app you were thinking about when you clicked. The app that needed to move and the app that was fine where it was do not deserve the same downtime window.

Moving three apps means three moves, each one considered, each one acknowledged. That is mildly more work on the day you rearrange everything, and the correct amount of friction every other day. Deliberate placement is the feature; a button that undoes deliberateness in bulk would be a strange thing to ship next to it.

Try it

Region-per-app is live on every subscription -- existing pools gained the ability without changing price or shape, and the next app you deploy will ask where it should live. Pick a capacity subscription, deploy your first app in the region its users are in, and put the second one somewhere else entirely. Apps deploy in minutes, with HTTPS, backups, SFTP and a browser terminal included.