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

yelyseiruban · February 11, 2026, 7:26pm

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.

mayailurus · February 11, 2026, 7:33pm

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…

yelyseiruban · February 11, 2026, 8:58pm

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.

mayailurus · February 11, 2026, 9:35pm

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

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.

yelyseiruban · February 12, 2026, 12:15pm

Thanks, I tried the following steps

I manually started the previously stopped Machines using fly m start, and after a bit of idle time, two of them did successfully auto-suspend.
However, after running fly deploy, two out of my six Machines remain in the stopped state every time. They just don’t start, so they couldn’t suspend after some time

Here are the logs from one of the Machines right after fly deploy:

2026-02-12T09:36:42Z runner[080736df09ee68] ord [info]Pulling container image registry.fly.io/<hidden>@sha256:<hidden>
2026-02-12T09:36:48Z runner[080736df09ee68] ord [info]Successfully prepared image registry.fly.io/<hidden>@sha256:<hidden> (5.847512765s)
2026-02-12T09:36:49Z runner[080736df09ee68] ord [info]Configuring firecracker

And then nothing else happens, the Machine stays in the stopped state.
When I start these same Machines manually afterward, they boot normally and later auto-suspend as expected.

So the issue only occurs during fly deploy, not during manual commands.

Let me know what additional logs or details would help.

mayailurus · February 12, 2026, 6:25pm

Aha… This is normal. The auto_stop_machines setting governs only the Fly Proxy, which isn’t really the part making the decisions during deploy…

Stopped Machines stay stopped, and ones in the suspended state transition to stopped (which is the closest possible imitation of the senior stopped → stopped policy).

before deploy	after deploy
`started`	`started`
`stopped`	`stopped`
`suspended`	`stopped`*

*Not suspended.

Many users are vocally against all of their Machines getting started on every deploy. (They have gigantic fleets of Machines.)

A seemingly equal number of users is vocally of the opinion that obviously every Machine should be started at least once, .

The first group won out, since they see the most bad effects, basically.

Still, this is undeniably inconvenient for those who want the spare Machines to always be primed in suspend, for fastest possible auto-scaling…

yelyseiruban · February 12, 2026, 6:41pm

Thanks for the clarification - now it makes perfect sense. I consider the topic resolved.

system · February 19, 2026, 6:41pm

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.