How can I do this? How do I prevent instances of the same app from being started in the same region? I am less concerned about tying each instance to a particular region and more with ensuring two instances of a given app don’t share a region…
When you add multiple regions, we spread instances out as much as possible. If you add, say, 5 regions and then run 4 instances, you should always get one per region on a deploy.
You can get really tight control over regions by adding volumes, if you need to. That would prevent a second instance from ever running in the same region.
Excellent! I’ll make sure I have more regions added than running instances.
I’m so pleased that everything is working out and I found my new app hosting platform! 
1 Like
Hey, has there been any movement on either session or IP affinity since this post? I’m considering some changes to one of my apps and some kind of request affinity would really help. I often run more app instances than there are regions (often 25 or 30 containers) so regional affinity wouldn’t work for me.
No worries if no work has been done here yet! It’s useful to know either way so I can change my approach as necessary.
Thanks!
We haven’t done anything here yet! You can likely do this yourself with two apps:
- Haproxy or nginx with session affinity configured
- App instances listening on 6pn
Haproxy makes it very easy to configure load balancing across <region>.<appname>.internal, we use this for our postgres clusters: postgres-ha/haproxy.cfg at main · fly-apps/postgres-ha · GitHub
1 Like
--max-per-region is a neat command shared with me for future readers.
Full command looks like fly scale count 6 --max-per-region 1
3 Likes
Sorry to bring up an old thread, but I was wondering whether any further work had been done to enable Session Affinity within Fly? I’m sure a number of your customers (including me!) would find this particularly useful. Even a “soft” implementation would be of great help (not guaranteed, but highly likely). Thanks!
(cc @kurt)
Kurt has previously written about achieving “sticky sessions” with Nginx’s hash-based load balancing here: The 5-hour CDN · The Fly Blog
I’m running into the same need. I tried the 1 machine per region approach, but requests are being load balanced across different regions, even when I use a VPN to put myself very close to a specific region. Any ideas?
1 Like
Sorry for the lame reply, but same here. It would be super handy to add a
handlers = http, sticky
to do this without private network nginx setup.
1 Like
would also love this feature for session affinity, we would be able to launch some features much sooner if it were available (and speed of building is why we love using fly!)
Any useful materials around this need? I’m also considering setting up private load balancer between my machines but I have no idea where to start.
Something that is not in the docs but what I could figure out searching this forum:
You can use the request header fly-force-instance-id to make the router pick a specific instance (even though load balancing would suggest another?).
This has the caveat that if the instance doesn’t respond the router doesn’t bother further and the request will just be dropped. And it needs to be a http-based / websocket protocol for the router to look at the headers in the first place.
But with this it should be easy to let a web-frontend hold a session with a process running on a specific machine.