Rolling Deploys
Last updated October 15, 2024
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 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).