Question: I’ve set my app to standard scaling, min 1 machine, max 5 machines, with four available regions: fra, iad, nrt, sjc (interestingly, when I run flyctl regions list, I see those four, but also a newline at the top - bug?).
However, when I run flyctl status, I see that I have three instances running - one in fra, and two in nrt. Shouldn’t standard scaling mean that these instances are evenly distributed, per docs? Wondering if I’m missing something in our configuration.
With a min of 1 and max 5, the app should be deploying to 1 instance to 1 region (that min 1 ensures that). To evenly distribute an instance over all the regions, set the min to 4.
Note that when a region is unable to configure an instance, Fly will attempt to bring an instance up in a “nearby” region. This is likely whats happened here with two instances in fra and nrt, and one instance falling back into nrt.
In the next version of flyctl (currently in beta), this backup/fallback region behavior is more visible in flyctl status and regions list.
Got it! Makes sense. Scaled up to four, and now seeing one in sjc, one in nrt, and two in fra (both appear to be passing). Is it possible that it’s not able to configure the instance in iad, resulting in the two in fra?
It’s pretty likely. (You could confirm it with the The Fly Beta Shop edition of flyctl if you really need to know. Whichever way, your apps incoming traffic will still be routed to the fastest node.