I have a repository that deploys via a CI hook on GitHub. I’m seeing Fly continuously redeploy the web application - every 10 minutes or so.
The worker app deployed from the same repositiory and CI hook doesn’t do this. Have revoked all access tokens (I got paranoid…) and this had no effect.
Seeing moderately high traffic at the moment, but nothing that OTT.
Only other potentially unusual thing I can think of is that it used to be configured to run multiple processes (using the ‘processes’ section of fly.toml), but split the two processes into separate apps because I wanted autoscaling.
Can you post your GIthub CI config? Perhaps it’s picking up commits from a branch you didn’t intend to trigger a deployment from?
Also, it’s possible you had enabled autoscaling on your app. If so, you can disable it with fly autoscale disable, or adjust concurrency settings in fly.toml to trigger it on the right conditions for your app.
Thanks for the quick response! Autoscaling is enabled. Intentionally so as I’m expecting realtively spikey usage.
Does a new instance created due to hitting a concurrency threshold show up as a ‘deploy’ w/ a new app version? I hadn’t really considered that – if so, it might be that and I’ve misunderstood the terminology.
If that’s the case, and it’s frequently scaling up then down, does that mean I want my hard and soft concurrency limits to be closer together or further apart? It’s currently 20 soft, 30 hard.
Here’s my CI script. Presumably if it was something to do with that, my worker application would be getting redeployed as well, though…
Yeah, autoscaling will issue a new release. You’ll probably want to try different concurrency settings. Not necessarily further apart, but higher, if you feel that you don’t need scale for the amount of traffic that’s triggering it.
Note also that autoscaling does not behave well with process groups, in case you have enabled those at any point.