# How to Rollback a Deployment When Your Production is Broken
> Your production is broken and every second costs you. Here is exactly how to rollback a bad deployment fast, fix the damage, and get your app back online.
- **Author**: tom-weston
- **Published**: 2026-06-20
- **Modified**: 2026-06-20
- **Category**: Deployment Guides
- **URL**: https://kuberns.com/blogs/how-to-rollback-a-deployment/
---
Your last deployment just broke production. Users are hitting errors, your inbox is filling up, and every minute of downtime has a cost. Stop reading context, start here: roll back to the last working version now, then figure out what went wrong.
A deployment rollback means reverting your live application to a previously working version. You can do it with git commands in under two minutes, or on platforms like [Kuberns](https://kuberns.com) with a single click from the dashboard. This guide covers both, in the order you actually need them.
### TL;DR
- Run `git revert HEAD` and push to trigger an immediate rollback via your CI/CD pipeline
- On Kuberns, open your deployment history and click Roll Back to any previous version instantly
- Heroku needs CLI, Render disables auto-deploys on rollback, Railway has no native rollback
- If your deploy included a database migration, roll back the DB first or your app will still be broken
- Every Kuberns deploy is versioned automatically - no setup needed to get rollback capability
## How to Rollback a Deployment Right Now
If your pipeline triggers on push, either of these two git approaches will get a rollback live in the time it takes your build to run.
### Using Git Revert to Undo a Bad Deploy
`git revert` creates a new commit that reverses the changes from a previous commit. It is the safest rollback method because it does not rewrite history, making it safe to use on shared branches.
```bash
# Revert the last commit (the bad deploy)
git revert HEAD
# Revert a specific commit by hash
git revert a3f2c91
# Revert multiple commits at once (last 3)
git revert HEAD~3..HEAD
# Push to trigger a new deployment
git push origin main
```
Your CI/CD pipeline picks up the push and deploys the reverted code. The original bad commit stays in history, which means you can trace exactly what changed and when.
### Redeploying a Previous Commit Manually
If you need to bypass the revert commit and go directly back to a specific known-good state, you can reset the branch pointer and force push.
```bash
# Find the commit hash you want to go back to
git log --oneline
# Reset to that commit (replaces working tree)
git reset --hard a3f2c91
# Force push to remote (this rewrites history - use with care)
git push origin main --force
```
Use `--force-with-lease` instead of `--force` if other team members may have pushed since the bad commit. It will abort if the remote has diverged, preventing you from overwriting someone else's work.
> If your deployments keep breaking in ways you did not expect, see [why software deployments fail](/blogs/why-do-software-deployments-fail/) for the common root causes and how to address them upstream.
## Roll Back to Any Previous Deployment in One Click
The git approach works, but it still depends on your build pipeline completing successfully before the rollback goes live. If your pipeline takes 4 minutes and production is down, that is 4 minutes too long.
Kuberns versions every deployment automatically. Every time you deploy, Kuberns snapshots the full build artifact, environment configuration, and service state. Rolling back does not trigger a new build. It switches your live traffic to the previous artifact instantly.
Here is how it works:
1. Open your [Kuberns dashboard](https://dashboard.kuberns.com) and navigate to your service
2. Click **Deployments** in the left sidebar to see your full deployment history
3. Find the last known-good deployment from the list
4. Click **Roll Back** next to that version
5. Kuberns switches live traffic to the previous build in seconds, no rebuild required
No CLI. No git commands. No waiting for a build. And because every deploy is versioned, you can roll back not just to the previous version but to any version in your history.
For teams using [one-click deployment](/blogs/what-does-one-click-deployment-do/), rollback works the same way - the same simplicity that got the app live gets it back live.
## Why Rollback Is Harder Than It Should Be on Other Platforms
If you are not on Kuberns, here is the reality of rollback on the platforms most teams use. None of them make it easy when you are already in a crisis.
**Heroku:** Rollback exists but requires the CLI. You run `heroku releases` to find the release number, then `heroku rollback v{number}` to revert. If you do not have the Heroku CLI installed on the machine you are working from right now, you are blocked. It also only rolls back the application slug, not environment variable changes or add-on configuration that may have changed alongside the deploy.
**Render:** Render lets you deploy a specific past commit from the dashboard, but selecting a specific commit automatically disables automatic deploys for the service. After the rollback stabilises, you have to manually re-enable auto-deploys. In a live incident, this is an easy step to forget, leaving your service stuck on manual deploy mode until someone notices.
**Railway:** Railway has no native rollback feature. If your deployment breaks on Railway, your only option is to use `git revert` locally, push the change, and wait for Railway to build and deploy the reverted commit. There is no version history in the dashboard to click back to.
**Kubernetes:** `kubectl rollout undo deployment/{name}` works if you have cluster access, the correct kubeconfig context active, and sufficient RBAC permissions. It rolls back the pod spec to the previous revision. It does not roll back ConfigMaps, Secrets, Ingress rules, or anything outside the Deployment object. If your bad deploy touched any of those, the undo command will not fully fix the problem.
> For a comparison of deployment platforms beyond just rollback capability, see the [best web application deployment tools in 2026](/blogs/best-web-application-deployment-tool/).
## The Part Nobody Warns You About: Database Migrations
Rolling back your application code is the easy part. The problem most teams hit is that the deployment they are trying to undo also included a database migration that has already run.
Here is what happens: your new code runs a migration that adds a column, renames a table, or drops a field. You roll back the application code to the previous version. But the database schema is still in the new state. The old code does not know about the new schema. Your app is still broken, just differently broken.
The rule is: **always run the down migration before rolling back application code.**
```bash
# Run your down migration first (example using a common migration tool)
npm run migrate:down
# or with Rails
rails db:rollback STEP=1
# or with Alembic (Python)
alembic downgrade -1
# Then roll back the code
git revert HEAD
git push origin main
```
Three habits that prevent this from becoming an emergency:
- **Back up before every deploy that includes a migration:** A database dump takes seconds and saves hours.
- **Write and test your down migrations:** Most teams write up migrations and never test the down path until they need it in production under pressure.
- **Never deploy schema changes and application changes in the same commit** if you can avoid it. Separating them gives you a clean rollback path for each.
> Misconfigured environment variables cause as many production incidents as bad code. See [how to fix environment variables in production](/blogs/environment-variables-in-production/) before your next deploy.
## How to Stop Needing Emergency Rollbacks
The best rollback is the one you never need. Most production incidents that require a rollback are preventable with a few non-negotiable practices.
**Deploy to staging before production:** Every change should run in a staging environment that mirrors production before it touches live traffic. If something breaks in staging, you catch it before users do. If your team skips staging because it is slow or painful to maintain, that is a tooling problem worth solving.
**Automated health checks after every deploy:** Configure your deployment pipeline to run a health check endpoint immediately after deploy. If the check fails, the deploy is automatically reverted before it ever serves real traffic. Most [CI/CD tools](/blogs/best-cicd-tools/) and PaaS providers support post-deploy hooks for this.
**Feature flags for risky changes:** Deploy the code but keep the feature disabled until you are confident it works. If something goes wrong, you flip the flag off. No rollback needed, no downtime, no emergency.
**Never deploy on a Friday:** This is not a joke. Most production incidents that turn into weekend crises start with a Friday afternoon deploy. If it can wait until Monday, wait.
> The most common reason apps break after deploy has nothing to do with the code itself. See [why your app works locally but breaks after deploy](/blogs/app-works-locally-fails-in-production/) for the real causes.
## Conclusion
When production breaks, you have two priorities: get it back up, then figure out what went wrong. `git revert HEAD` and a push gets you back up in the time your pipeline takes to run. On Kuberns, it takes the time it takes to click a button.
The longer-term answer is a deployment workflow where rollback is built in by default, not something you have to engineer under pressure. Every Kuberns deployment is versioned, every rollback is one click, and you never need to remember a release number or install a CLI at midnight to use it.
[Deploy on Kuberns](https://dashboard.kuberns.com) and make rollback the least of your worries.
## Frequently Asked Questions
### How do I rollback a deployment?
To rollback a deployment, run `git revert HEAD` and push to trigger a new deploy of the reverted code. On platforms like Kuberns, open your deployment history from the dashboard and click Roll Back next to any previous version. No CLI or git commands needed.
### How do I undo a deployment?
Run `git revert HEAD` to reverse the last commit while keeping history intact, then push to trigger a new deploy. To undo multiple commits, use `git revert HEAD~n` where n is the number of commits to reverse. On Kuberns, select any previous deployment from the dashboard and click Roll Back.
### What is a deployment rollback?
A deployment rollback is the process of reverting a live application from a broken or buggy version back to a previously working version. It is triggered when a new deployment introduces a bug, breaks functionality, or causes downtime that cannot be fixed forward quickly enough.
### How do I rollback on Heroku?
On Heroku, use the CLI: run `heroku releases` to list previous releases, then `heroku rollback v{number}` to revert. Heroku has no dashboard rollback button. This only rolls back the application slug, not environment variable changes or add-on configuration.
### How do I rollback on Kubernetes?
Run `kubectl rollout undo deployment/{deployment-name}` to revert to the previous revision. To rollback to a specific revision, use `kubectl rollout undo deployment/{name} --to-revision={number}`. Note this only reverts the pod spec and does not rollback ConfigMaps, Secrets, or database migrations.
### Does Railway have a rollback feature?
Railway has no native one-click rollback. To revert on Railway, use `git revert` locally and push, which triggers a new deployment of the reverted code. There is no dashboard option to select and restore a previous deployment version.
### What is the difference between a rollback and a redeploy?
A rollback reverts your application to a specific previous version using an already-built artifact, so it is faster. A redeploy runs a fresh build and deployment of a specific commit from source, which takes longer but ensures a clean build.
### Should I rollback the database when I rollback a deployment?
Yes, if the deployment included database migrations, run the down migration before rolling back the application code. Rolling back code while the database schema reflects the new version will cause the reverted app to fail. Always backup your database before deploying migrations.
### How do I revert a bad deploy on Render?
Go to your service in the Render dashboard, open Manual Deploy, and select Deploy a specific commit. Choose the last known good commit. Note that this disables automatic deploys for the service, so re-enable them after the rollback is stable.
### How do I prevent needing a rollback in production?
Deploy to staging before production, use automated health checks after every deploy, implement feature flags for risky changes, back up your database before every deploy that includes a migration, and avoid deploying on Fridays.
---
- [More Deployment Guides articles](https://kuberns.com/blogs/category/deployment-guides/1/)
- [All articles](https://kuberns.com/blogs/)