Currently, dstack fleets are optional for cloud backends, which means users have two ways of provisioning via dstack: using fleet configurations or run configurations. Moreover, fleet configurations are not supported for container-based backends, so the same users may have different provisioning UX depending on the backend. The proposal is to make provisioning UX fleet-first. Ultimately, this means that users always configure fleets explicitly, and run apply should not able to create new fleet. More specifically, this involves several steps:

• Support elastic cloud fleets, i.e. users can create fleets with 0 or more instances, empty fleets can be used by runs for provisioning (For fleets, support ranges (0.., 1..10, 1.., etc) in addition to a fixed number of nodes #1448).
• Implement smart fleet choice for runs – dstack should consider fleet capacity and prioritize fleets that can fit run without additional provisioning (currently only considers instance price, which leads to [Bug]: dstack chooses a fleet with too few instances #2221 ).
• Consider backend offers when choosing optimal fleet for run #3020
• Respect fleet spec when provisioning on run apply so that the instances do not contradict the fleet spec (Respect fleet spec when adding new instances on run apply #2969).
• Support fleet retry – dstack should maintain the specified min number of instances in the fleet ([Feature]: Fleet Retry #2921).
• major Respect nodes.max fleet property #3056
• major [Feature]: Support placement groups for elastic fleets #3256
• major [Feature]: Return run plan offers wrt fleets #3294
• major [Feature]: Fleet in-place update #2644
• Forbid creating new fleets on run apply (ultimate goal)