Don't bolt on a CMS to answer 'what did this look like last quarter'
The standard pattern is to add a separate headless CMS for content governance, then sync product fields between the CMS and the commerce backend. You debug two systems, you reconcile two data models, and the "single source of truth" is whichever one was most recently updated.
Vendure ships versioning natively. It works on the same Vendure entities your storefront reads, captures translations per language, and stores snapshots through the same plugin layer the rest of the platform extends through.
Snapshots, drafts, diff, restore, on your data
Snapshot, draft, diff, and restore are all available through the dashboard and the GraphQL admin API.
Snapshot mode
Every save creates an immutable version. The active entity updates immediately, the prior state is preserved as a SNAPSHOT row. Configurable per-entity via ProductVersionStrategy({ mode: 'snapshot' }) and analogous strategies you write for your own entities.
Draft mode
An alternative mode for editorial workflows that need staging. Saves create DRAFT versions without affecting the live entity. Editors publish explicitly when the change is ready. At most one draft per entity, so there is no ambiguity about which draft is "the" pending change.
Per-entity strategies
VersionStrategy<T> is the extension point. Product is provided. Define your own for collections, facets, custom entities. Each strategy owns its serialize, restore, and preview semantics. The strategy guide covers resolver patterns for entities whose core resolvers always query by ID.
Visual diff and one-click restore
The dashboard ships a VersionList, a VersionDiffView, and a VersionedSaveButton that integrate into entity detail pages. Pick any two versions, see field-level differences side by side, restore to a prior version with one click. Translations and custom fields are surfaced in the same view.
A coherent lifecycle, not a bag of side tables
Every save flows through the same path. A versioning service hands the entity to the strategy registered for it, the strategy returns a typed snapshot (core fields, translations, related IDs, custom fields, and an extra bucket for anything that doesn't fit), and that snapshot lands as a row with a version number and a status: active, draft, or snapshot.
Restores read the same shape back through the same strategy, so what you saved is what you get back. Drafts stay invisible to the live storefront until you ask for them: pass a draft-mode key to the Shop API to preview unpublished content in context, then publish immediately, or on a schedule you set.
The dashboard talks to this model through the admin GraphQL API. The same handful of operations (versioningInfo, saveDraft, restoreVersion) are available to your own plugins, so an internal editorial workflow uses the same surface the built-in UI does.
Three scenarios this plugin was built for
Versioning answers 'what'. Audit answers 'who'.
Snapshots tell you what a product looked like at any point. Audit logs tell you which administrator changed it and when. Together they are the editorial-governance evidence regulated catalogues need.
Each plugin is configurable independently. Versioning runs the strategies you nominate. Audit captures the change events the platform emits, including the operations that update versioned entities.
Versioned restores show up in the audit trail like any other write. A rollback is itself evidence.
Trusted by complex B2B commerce and enterprise retail.
What content, merchandising, and engineering teams ask
The questions every editorial-governance evaluation asks before signing.
