I’m not sure if this is really an issues or something more like “just pay attention to it and make sure that there is an instance in the primary region” but I’m seeing this problem: I have two regions, fra and gru where fra is set as main region on my Rails app.
Whenever I use scale count 1 or autoscale set min=1 max=xxx to scale in, it ends up preferring the instance on gru causing the app to stop working, since POST requests are redirect to fra where there is nothing running
vscode ➜ /workspaces/sumiu (main ✗) $ fly regions list
Region Pool:
fra
gru
Backup Region:
vscode ➜ /workspaces/sumiu (main ✗) $ fly autoscale show
Autoscaling: Enabled
Min Count: 1
Max Count: 10
vscode ➜ /workspaces/sumiu (main ✗) $
is there a way to ensure that when scaling it, fly keeps instances on the primary region as much as possible?
Personally, I’d disable autoscale as it has been on life-support ever since Fly shifted its focus to Apps v2 (aka Machines).
I don’t know what primary_region means in the context of regular Fly apps (I thought it only holds meaning for Fly-automated Postgres)… but something similar has been asked and answered before:
For Ruby apps, specially, you need to set the primary region in the app so POST requests are routed to an instance in the primary region, while GET requests could be handled in the servers in other regions
Personally, I’d disable autoscale as it has been on life-support ever since Fly shifted its focus to Apps v2 (aka Machines).
Ok, I guess I will do that then, wait for the Autoscaling apps on machines that was mentioned in one of the links you posted
ah, quick question since we are talking about it anyway: do Machines have load balancing? I deployed an app using Machines, cloned and put two in the same region but I don’t see the traffic being load balanced
(at least I haven’t seen any announcements regarding it).