Walkthrough 4: roll back, restore or detach
Part 4 of 4. Previous: the second deployment.
Roll back code
Section titled “Roll back code”Settings → Source & delivery → Deployment history lists this site’s deployments. Latest deployment marks the newest completed one. Go back on an earlier version needs site:deploy; its tooltip reads “Redeploy this version”. Confirm “Redeploy this earlier version?” and the build deploys that revision’s recorded commit against the current database. It never undoes a migration or a media change, and it never restores your own tables. If that commit contains different content, its snapshot replaces the generated content tables.
The CMS refuses a rollback when:
| Reason | Meaning |
|---|---|
destructive_since |
A later deployment ran a destructive migration. |
unreported_since |
A later deployment did not report whether its migration was destructive. |
different_database |
The revision ran against another database. |
no_git_sha |
The revision recorded no commit. |
build_in_progress |
Another build is already running for this site. |
The deployment script itself refuses with rollback_database_missing when the recorded database is gone. Recover the database using the restore procedure in that case.
Restore data and media
Section titled “Restore data and media”Rollback moves code only. To bring back data or media, follow the standalone recovery runbook.
Detaching stops CMS-managed regeneration. Remove the build webhook, stop pressing Deploy, and keep the repository. The deployed API, its database, statically built pages, your owned code and your own tables keep working. Blog routes, search, Latest entries, comments and forms still need the Dee Wan installation. See the detachment contract and the detachment runbook.
Next: extend your backend while it stays connected.
Unreleased / pre-MVP; no stable version
Source revision: fe23db481c422b40e317b92fc98116b4c0c26a87 (modified checkout)
Build date (UTC): 2026-10-18T09:22:34.630Z
Upgrade target: unavailable: modified checkout. Release notes