We have an app that is configured like:
primary_region = "lhr"
internal_port = 3000
force_https = true
auto_stop_machines = true
auto_start_machines = true
min_machines_running = 1
And with additional machines created in two other regions.
We frequently find it scaling to 0.
Is that expected?
That’s a great question, check this out here- Machines constantly scaling up and down after enabling auto_stop_machines. With “lhr” being your primary region it would make sense as to why the other two machines aren’t running continuously (scaling to 0).
auto_start_machines being set to true, this means that the machines for that app will scale to 0 when there is no traffic and start back up when there is (mainly to help with cost).
Here are a few docs for this-
- Machines are also the spawning ground for new platform features like wake-on-request (also known as scale-to-zero ). You can stop a running machine to save on compute costs. It then may be started automatically when a request arrives at the Fly proxy..
- Fly Machines: an API for fast-booting VMs · Fly
- Automatically Stop and Start Machines · Fly Docs
Hope this helps!
Looking at what I think is your application. It looks like the machine configuration has some invalid data on our end (this isn’t your fault). What version of
flyctl are you using? And was this app always on the apps v2 platform or was it migrated over?
Sorry for the confusion. All of our regions are scaling to 0, including
lhr. i.e. it does not seem that
min_machines_running is being respected at all.
I’m email support with the name of the app. This app was always on v2, deployed using v0.1.48 (happy to bump to latest if that could be relevant).
So apparently this was caused by an invalid fly-proxy config on the machines.
Re-deploying with flyctl v0.1.54 has resolved.
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.