Rollbacks
If a deployment breaks something in production, you can roll back to any previous deployment directly from the dashboard — no git revert needed.
How to roll back
- Go to your app → Deployments tab.
- Find the deployment you want to roll back to. Previous deployments show with a Superseded status.
- Click the Rollback button next to that deployment.
- Vessl redeploys the Docker image from that exact deployment — same build, same code, same configuration as it was then.
The rollback goes through the same deploy process as a regular deploy: canary health check first, then swap. If the rollback itself fails the health check, your current (broken) version stays up rather than going to something that's also broken.
What gets rolled back
A rollback redeploys the Docker image from the selected deployment. This means:
- Code — exactly what was built and running at that point.
- Build-time configuration — Nixpacks/Dockerfile as it was then.
What does not get rolled back:
- Environment variables — the Variables tab is the source of truth. If you changed env vars after that deployment, they remain as-is.
- Add-on data — database contents are not affected. If a migration ran with the broken deployment, the schema change stays.
- App settings — replica count, health check path, etc. remain at their current values.
If you need to undo a database migration, run the rollback command manually via the Console tab (e.g. php artisan migrate:rollback for Laravel, python manage.py migrate <app> <previous> for Django) before or after the code rollback, depending on your migration strategy.
Deploy history limit
The number of deployments available to roll back to depends on your plan:
| Plan | Deploy history |
|---|---|
| Hobby | 10 deployments |
| Starter | 30 deployments |
| Pro | 100 deployments |
Older deployments beyond this limit are pruned automatically and can no longer be rolled back to.