The Visual Website Builder
You Actually Own. React + Next.js, low-code, self-hosted. Your data, your infrastructure, every feature included.
© ChaiBuilder. All rights reserved.
Revisions are the safety net: a history of a page's earlier states that you can compare against and restore from.
They are an optional feature. If your project has them enabled, a Revisions section appears in the publish dropdown with View revisions. If you do not see it, the feature is not turned on for your project - see Configuration.
Two kinds of entry, from two different moments:
Published revisions are taken when you publish. The snapshot captures the version that was live before your publish - so after publishing, the top published revision is the page as visitors saw it a moment ago. A page's first publish creates no revision, because there was no previous live version.
Draft revisions track work in progress and are optional on top of the feature itself. When enabled, they capture the draft as you save.
Draft revisions do not accumulate one per save. Each editor gets a single rolling draft entry per publish cycle: your saves keep updating the same entry with a fresh timestamp until someone publishes, after which the next save starts a new one. That keeps the list readable, but it means you cannot step back through this morning's individual saves - only to the last published state.
View revisions opens a panel down the right side. The newest entry is always your current page, tagged live. Below it, each revision shows:
#2, #3, …)The numbers are positional, not permanent. #2 today becomes #3 when a new revision
appears above it. Use the date and the editor to identify a version, not the number.
Tick Compare on two entries and click Show diff. The comparison opens as a line-by-line diff with tabs for Blocks, SEO, and Tracking, a split-view toggle, and an option to hide unchanged sections.
The diff is over the underlying JSON, so it shows you exactly what differs but reads like code rather than like a page. It is good for answering "did someone change the SEO description?" and less good for "what does this look like?". Moving a block shows up as a large delete-and-insert rather than a move.
The same diff powers View unpublished changes in the publish menu, comparing live against your current draft. That one is available whether or not revisions are enabled.
From an entry's ⋯ menu, Restore this version. The confirmation asks how to handle your
current work:
Take Save as draft unless you are certain. There is no undo on a restore.
Restore replaces the page's blocks - its layout and content - and nothing else.
| Restored | Not restored |
|---|---|
| Blocks: layout, content, styles | SEO title, description, JSON-LD |
| Tracking settings | |
| Page name and slug | |
| Theme and design tokens |
This surprises people. Restoring a page to last week's version brings back last week's content but leaves today's SEO fields in place. If SEO is what went wrong, use the diff to read the old values and re-enter them by hand.
Restore does not publish. It updates the draft. The live site is unchanged until you publish, which gives you a chance to preview the restored page first - and that is the right order: restore, preview, then publish.
The ⋯ menu also offers Delete this version, with a confirmation. It removes that
snapshot permanently and does not affect the page. Deleting is rarely necessary, since
retention prunes old entries automatically.
A project sets a maximum number of revisions per page - 20 by default. Once the cap is reached, the oldest are pruned as new ones arrive.
Drafts and published revisions share the cap. With draft revisions on and a low cap, a busy page can push its published history out faster than you would expect. If you want a long publish history, raise the cap rather than turning drafts off.
Translations have no separate history. Revisions are kept on the default-language page. Because translated wording is stored on that page's blocks, restoring does bring back the translations that existed at the time - but you cannot browse or restore a translation's history on its own.
Partials are versioned separately. A partial has its own revision history, as its own page. Restoring a page that uses a partial does not roll the partial back - the page returns to its old layout, still showing the partial's current content. Restore the partial separately if that is what changed.
Theme and design tokens are not versioned at all. There is no history for site-wide styling. Before a big theme change, note the values you are replacing - the 15-second Undo on a preset is the only built-in way back. See Theming.
There is no per-block restore. Restore is whole-page. To recover one block, open the diff, find it, and rebuild it by hand.
There are no named snapshots. You cannot create a revision on demand or label one "before redesign". Revisions only appear as a side effect of saving and publishing. If you want a marked point to come back to, publish - a published revision is the closest thing to a bookmark.
Viewing, restoring, and deleting revisions are three separate grants. A common arrangement is editors with all three, designers and reviewers with view only. See Roles and permissions.
Restore has no lock check. A restore can land while another editor has the page open, and their next save may overwrite it. Coordinate before restoring a page someone else is working on.
A restore does not mark the page as changed. The publish indicator may not update after restoring, so do not rely on it - publish deliberately once you have previewed.
Draft entries mutate. The #N draft entry you looked at an hour ago may now hold newer
content. Only published entries are fixed points.
