Version History
Every time you save a site, Vivreal takes a point-in-time snapshot of the whole site document — pages, business info, social links, analytics config, everything. If a change causes a problem, you can roll back to any prior version without losing subsequent work (the revert itself is versioned, so you can undo it too).
What Gets Captured
Each version snapshot includes the full shape of the site document at save time:
- Site details (name, subdomain, theme)
- Pages and page configs
- Business info
- Social links
- Analytics configuration
- Any other fields on the site document
Versions are stored per-site. They don't include content inside your content groups — those have their own version history on each content item.
How Pruning Works
Versions pile up per tier:
| Tier | Versions kept per site |
|---|---|
| Free | 5 |
| Pro | 50 |
| Pro Plus | 500 |
| Enterprise | unlimited |
When you exceed your tier's limit, the oldest version is dropped. Upgrade your tier any time to lift the cap retroactively — existing versions aren't pruned until a new save happens.
Viewing Versions
Open the site
Tap Sites from the navigation, then select the site you want to inspect.
Open Version History
In the site detail pane, tap Version History. Versions show newest-first with a timestamp, author, and a short change summary.
Inspect a version
Tap a version to see its snapshot side-by-side with the current site. Fields that differ are highlighted.
Reverting to a Version
Pick the target version
From the Version History drawer, find the version you want to restore and tap Revert to this version.
Confirm
Review the diff and confirm. The site document is rewritten to match the snapshot.
Redeploy
Reverting only changes the data in the CMS. For the rolled-back content to appear on your live site, trigger a redeploy from the site detail page.
Reverting does not redeploy automatically. If you revert and your live site still shows the old content, that's expected — hit Redeploy to publish the rolled-back version.
Each revert creates a new version entry describing what was reverted and to which prior version. That means reverts are reversible too — just revert again to the post-revert version.
Via the API
If you're managing sites programmatically, the Secure API exposes three endpoints:
| Method | Path | Purpose |
|---|---|---|
GET | /api/siteVersions?siteId={id} | List versions for a site (newest first) |
GET | /api/siteVersion?siteId={id}&version={n} | Fetch a specific version snapshot |
PUT | /api/siteVersion/revert | Revert to a version (body: { siteId, version }) |
The MCP server exposes matching tools: list-site-versions, get-site-version, revert-site-version.
When Not to Rely on Versions
Site version history is designed as a safety net for content mistakes — mistyped copy, accidental page deletions, broken theme settings. It's not a substitute for:
- Pre-launch staging — set up a staging site and iterate there before touching the live one
- Git-style branching — versions are linear, not parallel. You can't have "draft" and "production" on the same site simultaneously
- Audit trail — for who-did-what tracking, use the Audit Log on the Group page