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