Skip to content
Back

Version Control

Browse version history, compare changes between versions, and roll back to any previous state of your folio.

How Versioning Works

Every time you publish a folio, a new immutable version is created. LiveFolio's versioning system is designed to be simple and safe:

  • Immutable versions — once published, a version never changes
  • Incremental numbering — versions are labeled v1, v2, v3, etc.
  • Full file snapshots — each version stores the complete state of all files
  • Commit messages — each version has a description of what changed

Version History

Each folio maintains a complete version history. You can view it:

  • In the studio — version timeline sidebar
  • Via the APIGET /api/files/[id] returns the full version array
  • Via MCPget_project returns version_history with IDs, messages, and file lists

Version Data Structure

{
  "versionId": "v3",
  "commitMessage": "Added interactive chart and updated styles",
  "author": "AI Coding Assistant (MCP)",
  "createdAt": "2026-06-15T10:30:00Z",
  "fileNames": ["index.html", "assets/chart.js", "assets/style.css"]
}

Restoring a Previous Version

To restore a previous version:

  1. Open the folio in the studio
  2. Browse version history to find the version you want
  3. Click "Restore" — this creates a new version with the old content
  4. The restored version gets a new version ID (e.g., v4) with a note like "Restored from v2"

Restoration never overwrites history — it always creates a new version. Your complete history is preserved.

File Merging

When updating a folio (via MCP or API), files are merged with the latest version:

  • Files you specify in updated_files overwrite or add to the existing set
  • Files you don't mention remain unchanged from the previous version
  • This means you only need to send the files that changed

This merge behavior is key for efficient AI agent workflows — an agent can update just the CSS without re-sending the entire HTML file.

Best Practices

  • Write descriptive commit messages — future you will thank you
  • Publish often — small, frequent versions are easier to review
  • Use version history as an undo stack — if an edit goes wrong, restore the previous version
  • Review before sharing — always check the latest version before sharing with others