“We can always go back” is a database guarantee here
Every save appends a snapshot of the entire entry — its values and every one of its links — inside the same transaction as the save itself. A version cannot exist for a change that did not commit, and a change cannot commit without leaving one.
For editors, and for whoever gets the call when something is wrong
One transaction, both writes
When you save, the live row is updated in place and a new version is appended — both inside the same database transaction. There is no background job, no queue and no window in which the row has moved and its history has not. Either both landed or neither did.
The snapshot is the whole document: every field value, the foreign keys of single relations, and the full ordered link sets of every many-relation. That last part is what makes a restore trustworthy — putting back an article without putting back the order of its tags would be a restore that quietly lost something.
Version numbers are serialised by a lock held on the entry, so two people saving at the same moment cannot be handed the same number. Nothing is ever rewritten: a restore appends a new version equal to the old one rather than reverting the timeline, so the history is append-only and the fact that somebody restored is itself part of the record.
A version timeline of four entries, with version 5 marked live and version 6 a newer draft, beside the two fields that changed between them.
Publishing an old version does not copy it
Publishing version 2 of a six-version entry marks that version live and re-applies its content to the live row so the two agree. What it does not do is mint a version 7 that is a copy of version 2 — the timeline stays six long, with version 2 flagged as the live one and whichever version was live before it marked superseded.
At most one version is live at a time, which is what lets the timeline show a Live badge that means something. Unpublishing returns that version to draft.
There is one consequence worth knowing: after publishing an earlier version, the newest version is no longer the live content — it is a newer draft nobody published. The next save appends a version that matches the live row again.
What you can do with the timeline
- Compare any two versions
- Field by field, with the previous value beside the new one. Relations are resolved to the records they point at rather than shown as raw identifiers.
- Restore one
- Re-applies that snapshot through the ordinary save path — same validation, same audit row, and a new version appended. Restoring is a normal edit that happens to have an old shape.
- Publish one
- Skip the restore-then-publish dance: take any version live directly. It re-validates on the way, and a failure leaves the content re-applied as a draft rather than half-done.
- See what was live and when
- Each version carries live, draft or superseded, so the timeline answers "what did the public see in March" rather than only "what did somebody type in March".
What a snapshot contains
| Part | What is captured |
|---|---|
| Field values | Every scalar, both per-language and shared, exactly as stored. |
| Single relations | The foreign key, so the linked record is part of the version. |
| Many relations | The full ordered link set of every join-backed relation. |
| Media fields | Asset ids, because media values ride the values bag like any scalar. |
| Status | Whether this version was ever live, and whether it is live now. |
A snapshot that outlived a removed field is still restorable — which is one reason an unknown key is dropped rather than rejected on the internal write path.
The call you get at 4pm
Somebody replaced the pricing page an hour ago and the numbers are wrong. You open the entry, see six versions, compare the last two, and see exactly which three fields moved. You publish the version from this morning. The page is correct before the call ends, and the whole sequence — the bad save, the compare, the publish — is in the audit log with names on it.
Questions about relying on it
How many versions are kept?
All of them, for as long as you keep them. Nothing prunes your history on your behalf, so the record of what happened is as complete in year three as it was in week one.
Does a translation share history with its original?
History is keyed per language row, so each translation carries its own timeline. That is what lets you roll back the German wording of a page without touching the English that was fine.
What happens to a version if I delete the field it used?
The snapshot keeps the value. Restoring it puts back the fields that still exist and drops the ones that do not, rather than refusing.
Does the AI assistant show up here?
Yes, as ordinary versions. An assistant edit goes through the same save path, so it appends a version like any other change and is undone the same way.
Next
Every feature is included, free
The core is MIT licensed and every feature is in it — none of them is paid-only. Community runs free in production; a plan buys room and governance, not a different product.