Rollbacks
Quickly revert your service to a previous deploy.
Sometimes you need to quickly revert a change to your service, and don’t want to wait for a full build cycle of pushing a new commit and waiting for a new build. When you already have a previous deploy you wish to make live again, Render lets you quickly roll back to that deploy.
Rolling back to a previous successful deploy
-
Go to the Events tab for your service. Find the successful deploy you wish to roll back to, and click Deploy to go to the deploy’s page.
-
If the deploy was successful and is not the current deploy for your service, you will see a Rollback to this deploy button. Click that button, confirm the rollback, and you will be redirected to your new rollback deploy. The build step will be skipped, and the deploy will begin immediately.
Build retention
Render only retains rollbacks for the most recent deploys of your services. The number of previous builds available for a rollback depends on your workspace’s plan. For details, see the pricing page.
Preventing automatic deploys
If automatic deploys are enabled for your service, rolling back to an old deploy will turn off Auto-Deploy. It can be enabled again on your service’s Settings tab.
What is rolled back
Some configuration for the service will be rolled back, but some will not.
| Configuration | Rolled back? | Details |
|---|---|---|
| Run command | ||
| Health check path | ||
| Docker command | ||
| Build asset | ||
| Number of instances | ||
| Environment variables | ||
| Environment groups | See Environment Groups | |
| Disks | Disks are stateful between deploys, and cannot be rolled back | |
| Plan | If a previous deploy requires a larger plan, consider changing your service’s instance type before rolling back | |
| Custom domain | ||
| Redirects & Rewrites | ||
| Headers | ||
| Owner | If a service has been migrated to a Team from an individual User since the original deploy, the new deploy will belong to the team |
The Render platform itself will not be rolled back. For example, services that are not using Docker will run with the latest runtime environment available on Render. That may include, among other things, a new language runtime for interpreted languages.
For image-backed deploys, a rollback deploy will use the specific image and digest from the previous deploy. This requires Render to pull the specific digest from the image registry again. If that digest no longer exists on the registry, the rollback deploy will fail.
Environment groups
Environment groups are designed to provide a common source of configuration for multiple services. Therefore, rollbacks will not roll back to the original value of environment group variables, but will only roll back the list of linked environment groups. The most recent value for variables defined in the groups will be used. Any deleted environment groups will be ignored.
Rollbacks skip the build step, so any use of environment group variables in the build process will not be reflected in the new deploy.
Rolling forward
A rollback will only change configuration for the rollback deploy and will not change the service’s configuration. Any deploys that are not rollbacks will continue to use the latest configuration from a service.