Our service is often used by people/organizations that need to have their account’s data/operations pinned to a particular region (usually to satisfy statutory/regulatory data residency requirements).
Given this context, fly’s default multi-region handling (i.e. driving traffic to the closest region/replica) is sort of backwards; I need to pin a given session to a particular region, based on the customer’s setting, and regardless of where their browser/client is.
Is there any way to satisfy this requirement, short of creating N apps, each configured to operate in a single region?
That is one way. Our requirement for https://sxt.health/ was data at rest to be in a specific region, so we’ve pinned the database in each region (us/eu/au), and have the app forward the request to the correct region to facilitate region switching e.g. an customer needing to login their home region, but they are travelling, however, if you don’t need that, it might be simpler just to pin the app to a single region.
We make it work by forwarding the request to the correct region using the fly-replay header.
A feature to pin clients would be helpful, no doubt, but folks are indeed creating N apps in its absence (0).
Apart from fly-replay, one can also forward request to a particular instance with fly-force-instance-id (1). In a way, doing so (fly-force-instance-id) is better because the request ends up straight at the desired instance, instead of (fly-replay) being ricocheted off of another instance.
Speaking of ricochets, one can forward traffic to any instance over 6pn (2, 3, 4), too.
Thanks for the pointers!
I’m disinclined to use any fly-specific features (hopefully for obvious reasons). And I guess I should have mentioned that I do want to be able to address each region’s application/endpoint uniquely – while being able to give assurances about data at rest is essential, so too in some contexts / regulatory regimes is data in motion. This implies having per-region subdomains that can be routed to after a user has logged in via a very thin account-management frontend (which can run anywhere).
I think this probably forces the use of multiple apps – a shame, as that’s obviously a lot more admin/ops overhead on each deploy, etc.
1 Like
Don’t worry about it!
I’m disinclined to use any fly-specific features (hopefully for obvious reasons).
Since Fly assigns public IPs (albeit anycast) per-app and not per-instance (like other VPS out there), DNS-foo wouldn’t be of help, either. (see edit below) You are relegated to use N apps, I guess.
Also, if you do change your mind, a better Fly-specific solution (if you have a say over the code that runs on the clients) for your case would be to use the Fly-Prefer-Region header instead (1, 2).
Edit: Looks like one could assign regional IPv4s. Along with some DNS-foo (1), one could possibly redirect traffic to a specific Fly region. I’d guess the usual $2/mo charges apply for these additional (regional) public IPv4s.
# supported regions: iad, lhr, nrt, scl, sea, sin, syd
fly ips allocate-v4 --region iad
Ref: Unable to run allocate-v4 with the --region flag - #3 by kurt
1 Like