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").