Rollbacks: putting the previous version back
How to return a Voroa service to an earlier working version without a rebuild, what a rollback restores, and the one thing it deliberately does not restore.
What this covers
A rollback returns a service to a version that was already working, without a build. It matters because the moment you most need a fix is the moment you are least able to write one carefully, and putting back a known-good version buys you the time to diagnose properly.
How it works
Each successful deploy keeps its built version. From your service’s Deploys tab, a deploy that can be restored shows a Roll back to this version action. Choosing it puts that version back with no build step, so it is live in seconds rather than minutes.
A rollback is itself a deploy: it appears in your deploy history as its own entry, marked with the version it restored, and it goes through the same health check as any other deploy. If the restored version fails to come up, the version that was running stays running. You are never left with nothing serving.
Only deploys that actually went live can be restored. A deploy that failed, or that built but never started successfully, is not offered — putting back a version that never worked is not a rollback.
What rollback does not restore
Your environment variables and service settings stay exactly as they are now. A rollback restores your code, not your configuration.
This is worth being precise about, because it is the one case where a rollback will not help:
- If a code change broke your service, rolling back fixes it.
- If an environment variable change broke your service — a wrong database URL, a missing API key, a changed secret — rolling back will not fix it. The old code will start up and hit the same wrong value. Correct the variable and deploy again.
The same applies to your build command, start command, root directory, health check path and every other setting on the service: whatever is set now is what the restored version runs with.
Your service’s number of instances is also unchanged. Rolling back never scales your service up or down, because that is what you are billed on and an action taken to fix an outage should not quietly change your bill.
Auto-deploy after a rollback
If your service deploys automatically on every push, the next push will replace the version you just restored — often within minutes, and usually from the same branch that caused the problem.
The confirm step therefore offers to pause auto-deploy, and it is selected by default. With it paused, your restored version keeps serving until you turn auto-deploy back on from the service’s settings. If you would rather keep deploying automatically, clear the checkbox before confirming.
How far back you can go
A limited number of recent versions are kept for each service — keeping every version ever built would consume disk without bound. Older deploys stay visible in your history but can no longer be restored, and those entries simply do not offer the action.