04 / Release
Review the diff, schedule the release, and keep a way back. Your content history stays with you, on every plan.
Unlimited version history. No retention window. No upgrade required.
What this replaces
Most systems hand you a shallow undo stack, a fixed number of revisions, or a rolling 30 day window. Some sell full history as an enterprise line item. The result is a team that publishes nervously. That is the wrong kind of caution.
How a change ships
Every save becomes a version. What you do with those versions is the rest of this page.
Draft, autosave, publish, or edit. Each one writes a new version with the author and the time, and it stays for the life of the project.
Pick any two versions and see the fields that were added, changed, or removed. Readable output, not a wall of raw JSON.
Point your preview URL at any historical version or branch and look at the real page in the real layout, through the preview token API.
A branch is an isolated copy of your space. Rebuild a content model while editors keep publishing, then merge with conflict detection at field level.
Bundle a homepage update, a product page, and a new post into one named release. Preview the whole set, set a go live time, and it publishes atomically.
Any version is publishable. Promote the one you want, for a single entry or a single locale, without touching the rest of the site.
What you get
Tag a version with something a human can read, then search for it later. When someone asks what was live on launch day, you open the tag instead of hunting through timestamps.
Publish with a way back
Every version you have ever saved, always available. Branching and release planning come with it.