Publishing a CMS entry feels high-stakes for a reason: if something goes wrong, getting back to where you were isn't always straightforward. Some platforms give you a shallow undo stack. Others limit history to a fixed number of revisions or a rolling 30-day window. Several treat full version history as an enterprise feature you pay separately to unlock.

The result is a content team that publishes carefully — not because they're disciplined, but because they're nervous. That's the wrong kind of caution.

b10cks keeps every version, forever, on every plan. Experiment freely. Roll back confidently.

Every time content is saved in b10cks — draft, autosave, publish, or edit — a new version is created and stored. There is no retention limit. No cap on the number of revisions. No "older versions are purged after 30 days."

• Full change record: see every version, who created it, and when
• One-click restore: promote any previous version back to draft or live
• Per-field history: inspect exactly which fields changed between any two versions
• Audit trail: compliance-friendly record of who changed what and when, across your entire content space

The version history for your content is as long as your project's lifetime. If you need to see what your homepage looked like six months before a rebrand, it's there.

A content branch is an isolated working copy of your content space. Editors work freely — rearranging structures, drafting new pages, testing new content types — without any risk of disrupting the live site.

How branches work in b10cks:

• Create a branch from any point in your content history — from the current live state, from a tag, or from another branch
• Edit independently: changes on a branch don't affect any other branch or the main space
• Merge when ready: bring branch changes back into the main space, with conflict detection and field-level merge resolution
• Delete safely: branches that didn't work out can be discarded with no consequence

This is the workflow that lets a developer rebuild a site's content model in staging while editors keep publishing to production. No freezes. No "please don't touch the CMS this week."

Not every version is equal. Some represent a milestone — a product launch, a seasonal campaign, a pre-redesign snapshot, a signed-off copy review.

Version tags let you mark any version of any content with a meaningful name:

• v2.0-launch · black-friday-2025 · pre-rebrand-snapshot · legal-approved-Q1
• Tags are searchable and filterable across your version history
• Restore or branch from a tag at any time — no hunting through timestamps
• Use tags as stable reference points in multi-team handoffs

When the CEO asks "what exactly was live on launch day?" — you have the answer, immediately.

A release in b10cks is a named collection of content changes — across multiple entries, block types, and locales — that are staged together and published as a single coordinated event.

• Group changes: bundle a homepage update, a product page revision, and a new blog post into one release
• Preview the release before it goes live — see the entire set of changes as they'll appear to your audience
• Schedule it: set a go-live time and walk away; b10cks publishes everything in the release atomically

This is what launching a campaign looks like when your CMS actually supports it.

Every version in b10cks history is publishable — not just the current draft. If you need to revert a live page to a previous state, you don't need to manually undo changes or paste from a backup. You promote the version you want and it goes live.

• Instant rollback: promote a previous version to published in one action
• Selective rollback: revert a single entry without touching anything else on the site
• Cross-locale control: rollback a specific locale's content independently; your other language versions are unaffected
• Publish from a branch: merge and publish a branch's state without going through the main working copy

No "restore from backup" process. No developer required. Just pick the version you want live and publish it.

Live Preview of any version Point your frontend preview URL at any historical version, tag, or branch — not just the current draft. See exactly how a past content state rendered in your actual site, in the actual layout, before you decide to restore or discard it. Works with any frontend framework via the b10cks preview token API.

Side-by-side Diff Select any two versions of an entry and get a field-level diff — what was added, what changed, what was removed. Displayed as clean, readable output: not raw JSON, not a wall of red and green lines.

• Compare draft vs. published
• Compare a branch against main
• Compare any two arbitrary versions from history
• Diff a single field or the entire entry

When a stakeholder asks "what changed since last Tuesday?" you have the exact answer in three clicks.

For developers
Branch the content model itself — not just entries. Test new block types and schema changes in an isolated branch before promoting them to your live space. Schema branches reflect instantly in the API, so your frontend branch can build against the new content structure in parallel.

For content teams
Seasonal campaigns, A/B copy tests, and site relaunches all benefit from branches. Draft in isolation, preview in context, merge when signed off. No more "don't publish anything until the launch" email chains.

For agencies
Create a branch per client deliverable. Build and review in isolation. Merge to main when approved. Each client's in-progress work stays invisible to production until it's ready.