Skip to main content

Restoring a previous version

When the live version has a problem, you do not have to fix the code in a hurry: restore the previous version and investigate afterwards.

What restoring does​

The target version is still whole, with an artifact already approved. Restoring switches which one receives traffic. There is no rebuild, no new build, no recompilation.

That is why the platform can promise that the version that worked comes back the same — not as a rebuild of it.

Step by step​

  1. Open Deployments in the project.
  2. Find the deployment you want back.
  3. Click Restore.
  4. Check the confirmation: it shows both ends side by side — what is live now and what will be live.
  5. Confirm.

The state goes through Rolling back and ends at Previous version restored.

Why the confirmation shows both ends

A confirmation that only asks "are you sure?" hands you the job of remembering what you are leaving behind — and that memory is exactly what someone arriving in the middle of an incident does not have.

The history is not destroyed​

Restoring does not delete the version that was live. It stays in the history, with the evidence of what happened. You can restore it back once the problem is fixed.

When the new version does not become ready​

Then there is nothing to restore: the traffic switch never happened. The deployment ends in Could not deploy, with the reason and the action, and the previous version, if there was one, keeps being the one that answers. See Deployment states.

When restoring is not the right tool​

SituationWhat to use
The deployment is still in Preparing or BuildingCancel — nothing has been switched yet
The new version did not become readyNothing to restore — the previous one is still live. Fix it and deploy again
The problem is a wrong variableFix the variable and deploy again
The problem is insufficient resourcesAdjust resources and limits
The previous version had the problem tooRestore one before it, or deploy a fix

Next steps​