Machines being scaled to 0 even with `min_machines_running = 1`

[carderne]

We have an app that is configured like:

primary_region = "lhr"
[http_service]
  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?

[kaelynH]

Hey there,

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).

With auto_stop_machines and 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-

1. 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..
2. Fly Machines: an API for fast-booting VMs · Fly
3. Automatically Stop and Start Machines · Fly Docs

Hope this helps!

[senyo]

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?

[carderne]

@kaelynH
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.

@senyo
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).

[carderne]

So apparently this was caused by an invalid fly-proxy config on the machines.

Re-deploying with flyctl v0.1.54 has resolved.