Roll back a deploy or undo a restore
Put an earlier version of your code back live in seconds, and take back a restore you didn't mean.
Roll back a deploy or undo a restore
Something went out that shouldn't have. How you get back depends on what went wrong:
| What went wrong | What to use | What changes |
|---|---|---|
| A deploy shipped broken code | Roll back to an earlier release | Your code only. Data is left alone. |
| Your data is wrong (a bad import, a deleted record) | Restore a restore point | The data on disk. See Restore points. |
| You restored and wish you hadn't | Undo restore | Puts back the data you had before the restore. |
All three start from your application's Protection page.
Roll back a deploy
strackt keeps your most recent releases ready on the server, so going back to one is a switch, not a rebuild. It takes seconds, your site stays up, and you can roll forward again the same way.
To go back one release:
- Open your application and go to Protection.
- Find the release you want in the timeline. Use the Releases filter to see only deploys.
- Choose Roll back next to it.
To pick a specific release:
- On the Protection page, choose Choose an earlier revision…. You can also open the command palette and run Roll back to a revision….
- Pick a release. Each one shows its commit, message, and when it was deployed.
- Choose Roll back.
Progress shows in the deploy drawer. Once it completes, the release you picked is live.
What a rollback does and doesn't do
- It swaps your code. The chosen release goes live and your application's caches are cleared, so visitors see that release, not a leftover of the one you left.
- It doesn't undo database migrations. If the release you're leaving changed your database, those changes stay. Make sure the older code can work with the current database. If it can't, restore your database from a restore point as well.
- It runs your rollback hooks. Any On rollback hooks in your deploy flow run after the swap, so you can notify your team or warm an external cache. On success hooks don't run, because a rollback isn't a new deploy. See Customize your deploy.
Which releases you can roll back to
You can roll back to any release still kept on the server. By default that's your last five. To change it, go to Settings → Source & triggers → Releases to keep and choose a number from 2 to 20. Lowering the number removes older rollback points on the next deploy.
Older releases still show in the timeline as history, but you can't roll back to them.
One-click rollback needs Zero-downtime deployments turned on (Settings → Source & triggers). If you turn it off, strackt deploys in place and no earlier release is kept to switch back to.
Resume after a restore
Restoring a restore point overwrites your current data, so strackt pauses new deploys afterwards. This gives you time to check the result before anything new ships on top of it.
When you see Restored to … on the Protection page, check your site. When you're happy, choose Resume and deploys can run again.
Restores are separate for each environment, so restoring staging never pauses production.
Undo a restore
When you restore from an off-server backup, strackt saves your data as it was just before the restore. While that saved copy exists, the Protection page shows Last restore can be undone with two options:
- Undo restore puts your pre-restore data back and redeploys. The saved copy isn't removed until the restored data is gone, so a failed undo never loses it.
- Discard keeps the restored data and deletes the saved copy. You can't undo this restore after that.
Only the most recent restore can be undone. A new restore replaces the saved copy from the one before.
Related
- Restore points: what each restore point covers
- Backups: off-server copies of your data
- How deploys work: why your site stays up during a deploy
Was this helpful?