There is always a way back
Every change that worked leaves a point. Pick one from the list and the code — and where possible the data — returns to that moment.
When they are created
Every successful run leaves one. So does a visual edit and a hand edit in code mode.
There is nothing to press. The list is there when you need it.
Failed runs are recorded alongside them, so you can see what was attempted later.
Two kinds, and why
A full point is only recorded when the data can genuinely be captured. If the capture is attempted and fails, we mark the whole thing failed rather than quietly downgrading it — a half point that looks complete is worse than no point at all.
Artifacts from failed runs appear in the list for reference but cannot be restored.
- Full — source files and the supported database data
- Files only — source files; the database stays where it is
What restoring actually does
The first step is why a restore is safe to try. You can always undo the undo, and none of it costs credits.
It reaches as far as the preview. A site you already published changes when you publish again.
- Saves the current state as a new point
- Puts the source files back
- Reapplies the data design
- Rebuilds the preview
If a restore fails partway
You get told how far it got, in one of three states, rather than a single unhelpful failure.
- Stopped before touching anything — the project is untouched
- Stopped partway and rolled itself back
- Rollback did not complete — stop editing and contact us
Data is stored outside the code
Captured data sits beside the snapshot, not inside it. That keeps it out of exports and out of anything sent to a model.
It is read only during a restore, and it is deleted with the project when the project goes.