Dashboard fly.toml not updating after deploy; machines still stopping instead of suspending

,
1

Hi everyone,

I’m running into an issue where the Fly.io dashboard does not reflect changes made to my fly.toml, and the platform seems to ignore the updated config.

In the Fly.io dashboard under the fly.toml tab, I still see:

[http_service]
auto_start_machines = true
auto_stop_machines = false
force_https = true
internal_port = 3_000
min_machines_running = 7
processes = [ “app” ]

[http_service.concurrency]
hard_limit = 1_000
soft_limit = 400
type = “connections”

But in my project root, my updated fly.toml is:

[http_service]
internal_port = 3000
force_https = true
auto_stop_machines = “suspend”
auto_start_machines = true
min_machines_running = 4
processes = [‘app’]

[http_service.concurrency]
type = “requests”
hard_limit = 1000
soft_limit = 400

After deployment, the dashboard still shows the old version.
But when I run:
fly config show

I see the updated configuration with auto_stop_machines = "suspend".

Despite this, Machines continue to stop instead of suspend, so it looks like the updated config isn’t being applied at runtime even though the CLI reports it correctly.

Is this a dashboard caching issue, or is Machines ignoring the new config?
Do I need an additional step to force a config sync?

Any insights would be appreciated.

1 Like
2

Hi… How exactly are you doing the deployment? (The option in the Web UI is still considered somewhat experimental, last I heard.)

Also, you can use fly m status -d as another way to check configuration. This will inspect an individual Machine.

Aside: it’s best to post the entire fly.toml, since there can be non-obvious subtleties with that format…

4

Thanks for the reply

I’m deploying using the CLI with:

fly deploy

I also checked the machine configuration using:

fly m status -d <machine-id>

For one of the machines that is currently stopped, the output shows the correct values, including "autostop": "suspend":

"services": [
  {
    "protocol": "tcp",
    "internal_port": 3000,
    "autostop": "suspend",
    "autostart": true,
    "min_machines_running": 4,
    "ports": [
      {
        "port": 80,
        "handlers": ["http"],
        "force_https": true
      },
      {
        "port": 443,
        "handlers": ["http", "tls"]
      }
    ],
    "concurrency": {
      "type": "requests",
      "hard_limit": 1000,
      "soft_limit": 400
    },
    "force_instance_key": null
  }
]

That is my full fly.toml:

app = <hidden>
primary_region = "ord"

[env]
TZ="Europe/Warsaw"

[http_service]
  internal_port = 3000
  force_https = true
  auto_stop_machines = "suspend"
  auto_start_machines = true
  min_machines_running = 4
  processes = ['app']

  [http_service.concurrency]
    type = "requests"
    hard_limit = 1000
    soft_limit = 400

So the CLI and the machine details reflect the updated configuration, but the Fly.io dashboard still shows incorrect values. However, the machines still fully stop instead of suspending — this is the main issue I’m trying to solve.

Let me know if you need any additional info.

1 Like
5

Hm… I’m not seeing any such discrepancies in my own apps, so this might be a localized glitch. (The ord region has been short on capacity lately, although that shouldn’t really lead to this kind of anomaly, :snowflake:.)

Here are a few things that I would try…

  • Use fly m start and then fly m suspend to manually confirm that the Machines really are eligible to suspend. (Not all Machines are compatible with that feature, and you don’t get a noisy warning when they aren’t.)
  • Use fly m clone to create a new† Machine, and see if that one correctly auto-suspends over the next few minutes.
  • As above, but clone into the ewr region.‡
  • Post the logs (fly logs) from around the time of an incorrect auto-stop event. There should be at least a little chatter from the Fly Proxy about what it’s thinking, etc.

Hope this helps a little!

†This assumes that your app isn’t sensitive to the exact number of Machines. (Most apps that lack volumes are indifferent to that.)

‡Likewise, most apps can be spread out across regions without ill effects, but there are occasional exceptions.