Feedback on `fly migrate-to-v2`

I have a basic HTTP app that I’ve been deploying to Fly for ~months.

I saw the v2 migration notification and decided to apply it.

Please review the following from the perspective of someone who (had) considered themself passably familiar with Fly but not using Fly as a daily-driver platform as feedback on the documentation for the migration:

  1. I was surprised (didn’t expect; am naive) that flyctl migrate-to-v2 requires (doesn’t stipulate) that the app must be (currently) deploy to Fly to work. I was expecting that the migration could be effected through a migration of the app’s config (TOML)
  2. My previous config (TOML) did not include an app property and the fact that my app was not deployed and then, once deployed, did not create the app property, result in several errors.
  3. After deploying the app, flyctl migrate-to-v2’ing it, deleting it (!) and then trying to re-deploy using the revised TOML, I expected the app to deploy as a v2 (machine) app. It does not.
  4. Rummaging through the docs, it became clear that I should flyctl orgs apps-v2 default-on {slug}, redeploying after this change, correctly deploys as v2 (machines). My expectation was the the app config TOML would include a property apps: v2.
  5. I now have 2 machines running though (unexpectedly). I think I should add a flyctl scale count 1 to reduce that (even if temporarily) to keep my costs down. I expect to be able to define scale in the app config.
  6. It appears that my App config’s [experimental] is legacy (Nomad) and so presumably I must revise this. migrate-to-v2 didn’t flag this and the documentation doesn’t appear to provide a pointer.

Other than the above hiccups, my deployment script is now revised and the app is working under v2.

thanks so much for these detailed notes! rest assured that this is making its way to the right people, and I really appreciate you taking the time to write it all.

for what it’s worth, you probably don’t need to worry about the experimental section. if you’re using the latest version of flyctl, pretty much all of the experimental section is now supported on apps v2 (this is only within the past few days, so the docs have not yet been updated about this!)

Also, with regards to the unexpected two instances, that’s because the default deployment on apps v2 is high availability. The idea is that if something goes wrong (say, a network outage), your apps
stay online because there’s a fallback.
This can be disabled with the --ha=false when deploying, but you can also enable autostart/autostop in your config file to keep the high availability deployment without paying for machines that aren’t in use.


@allison thanks for the prompt and helpful reply!

Yes, my intent is to help folks who are close to this, see how it appears to those of us who aren’t.

Reassuring news about [experimental], I’ll just forget about changing that.

I’ll review the autostart|autostop docs.

Thank you!

1 Like


Note that the docs about automatically stopping and starting Machines don’t yet include the new field to set a minimum number of machines to keep running when using that feature. We’re working on that update now. :slight_smile:


@andie you read my mind!

I was reviewing the docs and thinking … if only … :wink:

Is there a plan for max_machines_running too?

Ideally, I’d like to be able to define lower and upper bounds and have an app scale on demand within this range.

I appear to be able to apply this today using the scale command’s --max-per-region

Thank you!

The maximum number of machines is determined by the number of machines in your app. So that count number is the upper bound and the min_machines_running is the lower bound.

Apologies, I don’t understand.

If I have auto_start_machines = true, isn’t my upper bound limited by Fly’s datacenter capacity?

Or do you mean that --max-per-region becomes my (per region) upper-bound and I can limit the number of regions too?

auto_start_machines starts machines that already exist - essentially, it’s like taking a computer that was put to sleep and waking it back up. Your maximum machine count is just how many machines you create (e.g. through fly scale count or fly m clone), and the minimum is how many machines must stay awake, and can’t go to “sleep.” (metaphorically)

Stop/start aren’t the same as delete/create - the actual number of machines never changes.

1 Like

edit: oops I didn’t see @allison’s reply :slight_smile:

The auto start/stop feature isn’t creating any new machines, it’s only working on machines you’ve created: The number of machines you specify using fly scale count or create manually using fly m clone. You can see the count for each process group when you run fly scale show, and that’s your upper bound for the number of machines.

Check out the Scale the number of machines docs for details.

You don’t need to use --max-per-region to set your max machines in a region. You would just initially create the exact number of machines you want as your maximum number of machines in that region.

Here’s an example that @Sam-Fly provided to help me:

A user wants to run min 1 machine and max 10, BUT they want a maximum of 8 machines in region1 and only 2 in region2 they would:

  • Create 8 machines in region1, fly scale count 8 --region <region1>
  • Create 2 machines in region 2, fly scale count 2 --region <region2>
  • Set min_machines_running = 1

@andie (and @Sam-Fly) thank you!

Sorry to appear to belabor the point… this assumes I don’t set auto_start_machines = true, correct?

My understand is that

if I set auto_start_machines = true

and I had excessive demand (>> soft_limit)

machines would be created until the demand < soft_limit

Sorry to appear to belabor the point… this assumes I don’t set auto_start_machines = true, correct?

This discussion assumes you are using:

auto_start_machines = true
auto_stop_machines = true

machines would be created until the demand < soft_limit

It only works on existing machines, and never creates new ones for you. You can always create more machines if the ones you have aren’t meeting the demand at peak.

Machines will be restarted until either all your machines are running, or until the demand < soft_limit. There’s a more detailed explanation here for how this works: Automatically Stop and Start App V2 Fly Machines · Fly Docs

If there’s anything in the docs or our community posts that’s particularly unclear, please let us know. We’re always up to improve things!

Thank you everyone!

I missed @allison previous reply too.

I got it! Thank you.

1 Like

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