MCP Deployment # Versioning & Releases Vectoralix uses immutable version snapshots — closer to AWS Launch Templates than to Git tags. This page covers the active/default split, the five-table snapshot, the deletion rules, and the waterfall that decides which version a live request actually sees. ## Why immutable versions Versions are append-only snapshots: once cut, a version never changes. That gives you four things at once — instant rollback by re-activating an older version, A/B comparison without redeploying, an audit trail of what was served when, and a guarantee that "the version I tested last week" still serves bit-for-bit the same response today. ## The version lifecycle - Create — takes a transactional snapshot of the server's current state. Version numbers auto-increment from 1. - Activate — points the live endpoint at this version. Exactly one version is active at a time; activating a new one demotes the previous active to inactive. - Set Default — designates the fallback version. The default does not have to be the most recent one — pick whichever you trust as a known-good baseline. - Delete — removes a version and all its child snapshot records via cascade. Creating, activating, and setting default require mcp\_servers.can\_view + mcp\_servers.can\_edit. Deleting a version requires mcp\_servers.can\_view + mcp\_servers.can\_delete. ## Active vs default These are two distinct pointers on the server record: - Active — what the endpoint is serving right now. - Default — the fallback. If the active is cleared (typically by deleting it), the endpoint falls back to default automatically. ## The version-1 rule When you cut version 1 for a server, it is automatically set as both active and default. From version 2 onward, activation and default assignment are explicit clicks — Vectoralix never silently promotes a new version into production. ## What gets snapshotted Each version is materialised across four content-side tables: - mcp\_server\_versions — version metadata (number, optional release note, who created it, when). - version\_contents — content records, with category names denormalised inline (renaming a category later does not rewrite history). - version\_content\_relations — relations stored by slug rather than ID, so they remain meaningful as records evolve. - version\_content\_groups + version\_content\_group\_items — groups with their pivot membership frozen at cut time. Tool configuration is deliberately not snapshotted — it is read live on every request. See "What is NOT snapshotted" below for the reasoning. ## What is NOT snapshotted - The server-to-tool pivot itself — which tools are enabled is read live on every request, not from the snapshot. - The server's name, description, and visibility — those are server-level fields, also read live. - Cross-server relations — a relation whose target lives on a different server is skipped, because the external record would not be reachable from this version. **Important caveat for tools:** Because tool enable/disable and tool configuration are live, a tool change is not captured in version history. If you want a deliberate audit trail for tool edits, treat them as standalone releases — note them in your own changelog, not in the version release notes here. ## Request-time resolution (the waterfall) On every inbound request, the runtime resolves the version like this: ``` 1. Is active_version_id set? yes -> serve the active version 2. Is default_version_id set? yes -> serve the default version 3. Neither set -> 503, no version available ``` Switching the active version is immediate — the next request observes the new snapshot. There is no rebuild, no redeploy, and no warm-up. ## Deletion rules - The default version is protected — Vectoralix refuses to delete it. To remove it, you must reassign default to another version first. - The active version can be deleted. When that happens, the active pointer is cleared and the endpoint immediately falls back to the default version. - A version that is neither active nor default can be deleted freely. - Deleting a version cascade-removes all of its child snapshot rows — version\_contents, relations, groups, tools — automatically. ## Change tracking - Every version records who created it and when. - There is no automatic diff between versions; Vectoralix does not generate a changelog. - The optional release note attached at create time is the only human-readable summary of what changed — keep it short and operational ("added Q4 onboarding bundle, removed deprecated FAQ entries"). ## See also - [Server Configuration](https://vectoralix.com/docs/deployment/configuration) — why tool changes are live and not versioned. - [Content & Resources](https://vectoralix.com/docs/deployment/content) — the source data the snapshot freezes.