When I run a fresh deploy on a Fly app with scale of 1, whose one machine is in a suspended or stopped state, the deploy completes successfully but the app does not actually start back up.
I would very much expect a successful deploy to involve actually starting up the app in question to make sure it can run, even if it happens to not be running at deploy time.
Am I missing something here? I can’t tell if this is expected behavior and I should modify my deploy scripts to manually ping the app and force a startup, or if I have a misconfiguration somewhere causing my deploys to not trigger the startup themselves.
Yeah I can see how it could make sense, I’m mostly just looking for clarification. My min machines is set to 0, I do want it to scale to 0 when idle, I’d just like it to scale back to 1 after a deploy goes off in order to ensure the app actually boots post-deploy.
I’m greenfield here for this initial project so just trying to make sure I have all the best practices worked out while things are simple. It’s simpler to not need to add a deploy script to ping the app to make sure it starts post-deploy, but obviously that’s also not that hard to do. I just don’t want to add that if all I’m actually missing is a fly.toml argument or a machine configuration or something along those lines which would do this for me.
IMO, the behavior is expected from an infrastructure perspective. Maybe you can open a feature request on the fltctl repo.
If your concern is making sure your deployed app is properly working, that should be done in your ci pipeline with an e2e test suite because a simple ping won’t be enough to ensure all the parts are working.