We just released flyctl v0.1.101 and it speeds up fly deploy --strategy immediate by updating machines concurrently. flyctl will auto upgrade to this version in most cases; use fly version update otherwise. Read on for more details on the change.
fly deploy --strategy immediate updates all machines in an app “all at once” (see our docs for other deployment strategies). Prior to v0.1.101 this meant that flyctl would sequentially make api calls to update each machine in the app. flyctl does not wait for the machine to come back up or for health checks to pass or anything else like that with immediate deployments.
That felt pretty immediate for apps with a few machines. It felt a bit less immediate when there were 10 machines. And a lot less immediate with 30, 100, or even more machines.
In flyctl v0.1.101 we default to running the machine updates concurrently when using fly deploy --strategy immediate. The default is to start 16 concurrent machine update calls. As each individual machine update finishes, we immediately start another. Repeating that until all the machines are updated.
We also added a new --immediate-max-concurrent flag, which configures the number of concurrent updates that happen. For example, fly deploy --strategy immediate --immediate-max-concurrent 64 will run 64 machine updates concurrently. fly deploy --strategy immediate --immediate-max-concurrent 1 will run the machine updates sequentially.
I tested this change on a modest 35 machine cluster. It resulted in a pretty decent speed up. The results of running the deployments a few times for each configuration were:
| fly version | fly deploy flags | Time |
|---|---|---|
| flyctl v0.1.97 | --strategy immediate |
30-40 seconds |
| flyctl v0.1.101 | --strategy immediate |
7-9 seconds |
| flyctl v0.1.101 | --strategy immediate --immediate-max-concurrent 35 |
5-6 seconds |
There are other flyctl commands that would benefit from this kind of change when developers desire immediate changes. Things like fly secrets, fly scale, and probably others. We’re working on those , too. They will be opt-in (like --strategy immediate) so developers will be able to choose the right tradeoff of immediacy vs. safety for their specific needs.
Let us know how the new immediate deployments work for you, and if you run into any issues. Happy deploying!