Rolling Deploys
Last updated April 08, 2025
Table of Contents
This feature is only available for apps in Private Spaces.
When an app first deploys to a Private Space, it can take several minutes for the app to be available due to setup of the underlying dedicated infrastructure.
For subsequent releases, such as code deployments or config var changes, there’s a much shorter delay, with little to no downtime. If there’s only one dyno for the app, there can be brief downtime. With multiple dynos, zero downtime is possible with the rolling deploy feature. Rolling deploys are available for both generations of Private Spaces.
Rolling Deploy Behavior
Rolling deploys are analogous to Preboot on the Common Runtime. Both enable zero downtime during new releases. Preboot’s method is to ensure that new web dynos start and receive traffic before the existing ones terminate. Rolling deploys stop and change up to only 25% of the existing dynos at a time, while the remaining dynos handle requests and tasks. The effect is that all requests get handled with no user downtime, while we gradually push the new release to the entire formation.
To be more precise, if the following are true, there’s zero downtime during a new release for a Private Space app:
- The app has deployed at least once and is running.
- The app has at least two dynos and they’re not currently at capacity.
Not being at capacity means the app has enough dynos to service requests with up to 25% of its dynos missing. If the app has only 2 or 3 dynos, then the remaining 1 or 2 dynos must be able to handle the existing load while the release rolls out.
Scaling an existing app in a Private Space doesn’t incur downtime, as long as there is enough capacity to handle the existing load. Changing the dyno size does incur a short downtime, under some circumstances, while we create the new dynos and switch traffic over.
Any databases attached to the app don’t incur schema changes and are compatible with both the old and new app release (forwards- and backward-compatible).
Fir-Generation Apps
When Fir-generation applications restart in response to new releases, the dyno count can temporarily exceed the configured scale. This behavior exists to prevent degraded availability. We create new dynos and confirm they’re ready before those running the older release are terminated, ensuring that there are more available dynos while releases roll out.
Dynos that can’t start as a result of the latest release continue to exist in addition to the dynos running the previous release. In this case, the dyno count exceeds the configured scale until the newest dynos run successfully.