> ## Documentation Index
> Fetch the complete documentation index at: https://docs.metabind.ai/llms.txt
> Use this file to discover all available pages before exploring further.
# Rolling back
> Restore a previous version of a component, content type, or content entry — packages stay immutable, rollback creates a new version forward
Roll back when a published component, content type, or content entry has a problem you want to undo. Metabind keeps every published version available, so restoring an earlier one is fast and lossless. Packages themselves are immutable — there is no "package rollback"; instead, rolling back individual resources and then publishing produces a new corrected package.
## When to roll back vs. fix forward
Most fixes should be **fix-forward**: edit in MCP App Studio, publish a new version. History stays linear and the published state always reflects current intent.
**Roll back** when:
* A bug is causing user-facing failures and you can't fix it within minutes.
* The new version has a security issue that needs to be off production *now*.
* A change had a subtle effect you didn't catch in testing and you need to think before publishing again.
The decision is mostly about urgency. If the fix is 10 minutes away, fix forward. If you need to stop the bleeding first, roll back.
## What rollback acts on
| Resource | Rollback supported | Endpoint |
| ------------------- | --------------------------- | ------------------------------------------- |
| Component | yes | `POST .../components/:id/rollback/:version` |
| Type (content type) | yes | `POST .../types/:id/rollback/:version` |
| Content entry | yes | `POST .../content/:id/rollback/:version` |
| Package | no — packages are immutable | n/a |
Rolling back a *component* restores its definition; rolling back a *Type* restores its schema; rolling back a *content entry* restores its values. To restore the platform-wide state, roll back the affected resources and publish a new package; the new package captures the corrected resources.
## How rollback creates a new version
Resource versions in Metabind are monotonically incrementing integers — `1`, `2`, `3`, … — not semantic versions. Each publish of a component, Type, or content entry mints the next integer.
Rollback is **forward-only**. Rolling back resource X from version `3` to version `2` does not delete `3` — it mints a new `4` whose content matches `2`:
**Diagram needed:** A horizontal version timeline showing `1 → 2 → 3 → 4`, with `4` labelled "rollback to 2 (content of 2, new integer version)". The diagram should make clear that 3 is preserved and 4 was minted from 2's content. Place the rendered diagram at `/images/publishing/rollback-version-timeline.svg` and replace the placeholder above.
This means:
* **History stays monotonic.** Every version that was ever published remains in the audit trail.
* **The "rolled back" tag is metadata.** The new version's content is byte-equivalent to the target version, but it carries its own integer version number and timestamp.
* **Re-rolling back is fine.** Mistakes are recoverable — roll back the rollback, get a new version with the original content.
Note: per-resource versions (the integers) are distinct from the *project package* version, which uses semantic versioning (`1.4.0`, `2.0.0`). See [Package versioning](/guides/publishing/package-versioning) for the package-level model.
## How to roll back in MCP App Studio
1. Open the resource's edit page (a component, a Type, or a content entry).
2. Click **History** to see all published versions for that resource.
3. Pick the version you want to restore.
4. Click **Rollback to this version**.
5. Confirm.
A new published version is created with the target version's content. Connected hosts pick it up on their next list-tools call (for Types and components) or their next read (for content entries).
**Screenshot needed:** A resource's History view in MCP App Studio with several version rows visible and a "Rollback to this version" button highlighted on one row. Place the captured image at `/images/publishing/rollback-history.png` and replace this note.
## Rolling back via API
Each resource has its own rollback endpoint. Authenticate with a JWT scoped to publish.
```bash theme={null}
# Roll back a component to version 5
curl -X POST \
"https://api.metabind.ai/app/v1/organizations/{org}/projects/{project}/components/{componentId}/rollback/5" \
-H "Authorization: Bearer ${MB_JWT}"
# Roll back a Type to version 3
curl -X POST \
"https://api.metabind.ai/app/v1/organizations/{org}/projects/{project}/types/{typeId}/rollback/3" \
-H "Authorization: Bearer ${MB_JWT}"
# Roll back a content entry to version 7
curl -X POST \
"https://api.metabind.ai/app/v1/organizations/{org}/projects/{project}/content/{contentId}/rollback/7" \
-H "Authorization: Bearer ${MB_JWT}"
```
The response is the new published version (with a freshly-incremented version number). For full reference, see the [REST API rollback endpoints](/rest/components/rollback).
## After rolling back
After rolling back the affected resource, publish a new package so production picks up the change:
1. **Roll back the resource** that introduced the issue (per the steps above) — this mints the next integer version of that resource.
2. **Publish the project** to mint a new package version (semver) that captures the corrected resource.
3. **Optionally bump the package's MAJOR or MINOR** if the rollback restores breaking-change-era behavior.
Connected MCP hosts re-list tools on their next call and observe the new package version.
## What rollback doesn't reset
Rolling back a resource does not roll back:
* **Secrets.** If you rotated a key after the original version was published, the new key stays in place — the rolled-back handler will use it.
* **Allowed domains.** Editable in real time; current settings apply.
* **Tool descriptions and annotations.** Editable independently of resource versions.
* **Project Instructions.** Editable independently.
If you need to restore those too, edit them by hand in MCP App Studio. The publish history records what they were at the time of each publish.
## Cache implications
After a rollback + republish, hosts pick up the corrected schemas on their next list-tools call (typically within seconds). For details, see [Publish the MCP server: cache behavior](/guides/publishing/publishing-the-server#cache-behavior-on-connected-hosts).
If a host has cached the bad version's schemas and is mid-conversation, it may continue using the bad version until it reconnects. To make the cutover faster, bump the package version when you republish the rollback — most hosts re-list tools when they see a newer version, picking up the corrected schemas on their next call.
## Permissions
Rolling back requires the same role as publishing — Editor or higher. Viewers can see history but can't trigger a rollback.
## Audit trail
Every rollback is logged. The audit log records:
* Who triggered the rollback
* When
* Which resource and which version was restored
* The new version number that was minted
## Related
The forward-direction equivalent of rolling back.
Why packages are immutable and how versions are minted.
Per-publish and per-rollback audit records.
Roles and who can roll back.