Feature · Build & deploy
Roll back a bad deploy in one click.
A rollback puts a previous, working version of your app back into production. Runex keeps your deployment history, so if a release breaks something you redeploy the last good version in one click, no git revert, no rebuild.
- Full deployment history
- No rebuild needed
- Every rollback is logged
- current
- #128 · a1f9c3e · errors
- previous
- #127 · 7be20d4 · healthy
- action
- roll back to #127
- rebuild
- not needed
- status
- live on #127
Definition
What is a deployment rollback?
A deployment rollback replaces the current release with an earlier one that's known to work. You restore service first, then fix the bug calmly.
Without rollbacks, a bad release means writing a hotfix under pressure while users see errors.
Runex keeps a history of your deployments (commit, time, and status) and each entry keeps its built image. Rolling back redeploys that image, so it skips the build step entirely.
A rollback restores code, not data. If a release changed your database schema, check that the older version still works with it.
How it works
How do instant rollbacks work on Runex?
Pick a past deploy, click roll back. Runex swaps it in and keeps the history intact.
-
You
Spot a bad release
Errors or failed checks show up after a deploy.
-
You
Open deployment history
Every deploy is listed with its commit and status.
-
Runex
Redeploy the good build
The saved image goes live, no rebuild.
-
Runex
Keep the record
The rollback is logged as its own deployment.
Benefits
Why do instant rollbacks matter?
Recovery takes a click, not a hotfix.
Recover fast
No waiting on a fresh build to undo a mistake.
See what shipped
Every deploy's commit, time, and status in one list.
Release with less risk
Ship more often when undo is always one click away.
Keep git clean
No revert commits needed just to restore production.
Compare
Rollback vs git revert: what's the difference?
A rollback restores a previous build; a git revert creates a new commit. Roll back first to stop the damage, then revert or fix in git.
| Rollback on Runex | git revert | |
|---|---|---|
| What changes | Which build is live | Your repository history |
| Rebuild | Not needed | Triggers a new build and deploy |
| Speed | Immediate | As long as a full build |
| Best for | Stopping an incident now | Permanently undoing a change |
Example
Example: undoing a broken release
A release breaks the login page; the team is back on the last good version in one click.
- Commit a1f9c3e ships to main
- Login errors start right after the deploy
- An engineer opens deployment history
- They roll back to 7be20d4, the previous release
- Production is healthy again, no rebuild
- The team fixes the bug and ships a new deploy
- #128
- a1f9c3e · login errors
- #127
- 7be20d4 · last healthy
- rollback
- #127 · by priya
- build
- reused
- status
- healthy
How do I roll back a deployment?
Open your app's deployment history, pick the last version that worked, and redeploy it. On Runex that's one click, and it reuses the saved build.
Does rolling back a deployment undo database changes?
No. Rollbacks restore application code and its build, not data. Plan schema changes so the previous version can still run against the new schema. Keep data safe with backups on managed databases.
What is deployment history?
A record of every release: which commit shipped, when, and whether it succeeded. It's what makes one-click rollbacks possible.
Should I roll back or fix forward?
Roll back when users are affected and the fix isn't obvious. Fix forward when the bug is small and the fix is quick to ship. Either way, zero-downtime deployments keep users on a working version while the fix ships.
Next step
Ship with instant rollbacks today.
Sign up, install the GitHub App, and deploy your first app. It's free to start.