Deployment rollbacks are a new feature that allow you to quickly and confidently version your deployments. Rollbacks allow you to restore a previous successful deployment in one click: fix a broken build or a typo in seconds.
A quick tour
Let’s explore the new additions to the deployment experience.
Rollback activation
From the deployments history view, hover over any deployment to see the actions menu.
This will take you to a rollback confirmation view.
Secrets manager
You can also directly compare secrets across builds, ensuring the correct environment even as variables change. For example:
Scenario 1: If an API key was used in your previous deployment but not in production: select the value from the rollback build column. The absence of a secret in either the current or previous deployment is denoted with “No Value.”
Scenario 2: If an API key from your previous deployment has since expired, and you’ve replaced it with a new one in production → select the value from the production column.
After the rollback
Once your rollback is complete, it will be represented in deployment history as a pill (displays the previous build that the rollback references).
What's going on technically?
Supporting rollbacks involved technical considerations beyond our existing deployments infrastructure.
Creating a new rollback build
Since a deployment might have unique properties, like secrets, we treat rollbacks as their own new versions. This allows us to introduce changes without overwriting important data.
Deploying the rollback build
On Replit, deployments have 4 stages: provision, build, bundle, and promote. Since a rollback involves redeploying a previously working version, we are able to skip the first three steps and focus solely on promoting the existing image. This saves resources and accelerates the deployment process.
Managing secrets
The differences between the production and rollback candidate secrets are displayed, enabling a user to select the proper value. Once selected, only the new secrets are deployed.
Build availability
Please note that rollbacks are only possible if the old build is still available. We store up to the five most recent builds for each deployment, while older builds may be removed as needed.
