Clarification on machine configuration persistence (CPU, autostop, regions vs fly.toml)

, ,
1

Hi Fly Team,

I need clarification on how Machine configuration interacts with fly.toml during deployments.

Here is my scenario:

  1. I initially deployed my app it has cpus = 1 and auto_stop_machines = “stop” in fly.toml.

  2. Later, I manually updated my running machine using the Fly dashboard (UI) to:

CPU = 2
Autostop = off (with command)

  1. I did not update the fly.toml in my repo.

  2. The next day, I deployed a code change using fly deploy, and I noticed that the machine reverted back to:

    • CPU = 1

    • autostop = “stop”

My questions:

  1. Does fly deploy always override manual machine changes (CPU/RAM/autostop) with the values defined in fly.toml?

  2. Are machine-specific overrides (e.g., changing CPU in UI or via fly machine update) intended to be temporary unless updated in fly.toml?

  3. If I add additional machines in different regions, do I need to update fly.toml? Is yes how can I get that config?

  4. Is fly.toml considered the single source of truth for machine configuration during deployments?

Just want to confirm the expected and correct behavior so I can set up my deployment workflow properly.

Thanks!

3

Hi… Yes, it says exactly that in the docs, for CPU and RAM:

Once compute requirements are set, fly deploy and fly scale count commands will enforce them. If you change the size of the Machines using fly scale vm (or its sibling fly scale memory) then it will be reset on next fly deploy unless fly.toml is updated accordingly.

Well… Source of truth would be putting it a bit too strongly, in my opinion. It’s not a fully consistent design in either direction, having parts that are declarative and larger parts that are imperative. (I don’t work for Fly.io, by the way, and, in general, you can’t expect to reach them here in the community forum.)

Region placements are completely imperative, for example.

Personally, I’m more of a fan of the declarative style, :bluegreen_dancer:, but a person needs to do their own orchestration if they want that (which is conveniently covered at the end of the official “without Terraform” doc).