Rollback

A rollback returns your project to an earlier saved version after a change causes a problem, restoring the last snapshot that worked. It undoes a bad update by reusing a known-good state instead of trying to fix the broken one live.

A rollback returns your project to an earlier saved version after a change causes a problem, restoring the last snapshot that worked. Because your history holds labeled snapshots, you can step back to the one before the trouble started. Say you deploy an update to a to-do app and the page that lists tasks goes blank for every visitor. Rather than debugging under pressure while users stare at an empty screen, you tell the agent to roll back to the version from before the update; the working list returns in seconds, and you investigate the broken change on a copy. The earlier snapshot is unchanged and ready, which is what makes the recovery quick.

Builder example

When a deployment breaks something visitors depend on, rollback is the recovery that buys you calm. Imagine a password-reset flow that worked yesterday and now sends no email after your latest change ships. A rollback restores the prior version that did send the email, so people can reset their passwords while you diagnose the failure separately. Hosts and version-control tools both support this, so the safe habit is to confirm you can return to a known-good version before you push anything risky.

Common confusion: A rollback restores a whole earlier version of the project, while undo reverses your last edit inside an editor before it ships. What separates them is scope and timing: rollback reaches back to a deployed or committed snapshot after a change is already live, where undo only steps back through recent local keystrokes.