Fly deploy changes for process groups and auto-scaled services

:wave: I have two new fly deploy improvements to share:

1. Deploy to specific process groups

As of flyctl v0.1.120, You can now run fly deploy --process-groups [groups] to deploy to a set of specific process groups!

This can be helpful for complex, multi-process apps with distinct workloads, for example heavier, stateful machines running alongside lightweight, stateless, auto-scaled machines. In some cases, you may want to quickly deploy updates or configuration changes to the lightweight service while leaving the heavier one unmodified, whether it’s to complete deploy more quickly or to minimize the impact of restarting machines in a process group. This is now possible using the --process-groups flag.

2. Deploy to auto-scaled services

As of flyctl v0.1.119, deploying to machines with auto-scaled services (with either auto_stop_machines or auto_start_machines enabled) will no longer restart machines currently in the stopped state. Previously, fly deploy would restart all machines in the app, effectively scaling your service up to its max count on every deploy. Now with this change, all machines will still be updated with the new app configuration, but machines associated with an auto-scaling service will remain stopped so your service will continue running at its current scale. This change should make deploys to auto-scaled services quicker, and allow for smoother scaling across deploys.

Hope these changes are helpful! Please let me know if you have any related questions or feedback.


Love the change for auto-scaled services! Hated the fact that every time we would deploy we would need to start up to 40 stopped machines!

1 Like

Is there a way to force the primary instance to wake up if no instances are awake during deployment? I find that deployments will now fail presumably due to the lack of any awake instances.

1 Like