> For the complete documentation index, see [llms.txt](https://docs.flowcp.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.flowcp.ai/guides/version-history.md).

# Version history

Every change to a server's configuration is tracked, and the full configuration can be committed as a restorable version at any time. Open it from **Servers → History** (or via the **History** button on the Deploy page).

> **Naming note:** "branches" (Live, Main, …) are separate servers — see [Managing branches](/guides/manage-branches.md). The History page tracks *versions of one server's configuration over time*, like commits in git.

## What is tracked

The History page is organized into four tabs:

* **Versions** — restorable snapshots of the server's complete configuration: server settings (description, auth mode, tool exposure, agent auth), tools, skills, widgets, prompts, and resources.
* **Deployments** — every promotion to production and recall back to development.
* **Change log** — every individual configuration change (a tool enabled, a skill edited, the server published, a version restored), with who made it and when.
* **Spec imports** — every import of the server's API spec, with diffs of what changed upstream.

## How versions are created

| Trigger                   | Kind                      | When                                                                                                                                    |
| ------------------------- | ------------------------- | --------------------------------------------------------------------------------------------------------------------------------------- |
| Deploying to production   | `Published`               | Automatic on every deploy. Re-deploying an unchanged configuration does not create a duplicate.                                         |
| **Commit version** button | `Commit`                  | Whenever you want a named checkpoint, with a message.                                                                                   |
| Restoring a version       | `Restore` + `Pre-restore` | A restore records the restored state as a new version, and automatically saves the state it replaced as a `Pre-restore` snapshot first. |

## Restoring a version

Click **Restore** on any version. The current configuration is replaced by that version's snapshot:

* **Nothing is ever lost.** A pre-restore snapshot of the current state is saved automatically, and the restore itself is recorded as a new version — so you can undo a restore by restoring the pre-restore snapshot.
* **Later additions are removed.** Tools, skills, widgets, prompts, and resources added after the restored version are deleted from the current configuration (they remain inside later snapshots).
* **Identity fields are untouched.** The server's name, branch, URLs, deployment status, and import source are never changed by a restore.
* **Live servers stay safe.** Restoring onto a server that is in production re-runs the full publish validation; if the snapshot would put a blocked configuration live (for example a destructive tool without confirmation), the restore is rejected and nothing changes.

Use **View changes** on a version to see exactly what differs before restoring. The diff shows each changed setting and entity field with its **before → after** values — long values (skill bodies, widget HTML) are truncated and large schemas summarized (e.g. `object (12 keys)`) to keep the view readable. By default the version is compared against the current configuration; use the **Compare against** selector inside the panel to diff it against any other version instead.

## Credentials are never stored in history

Version snapshots deliberately exclude secrets. For servers using a shared credential (`api_key`/`bearer`), the snapshot records the auth *mode and placement* but never the credential itself:

* Restoring keeps whatever credential is currently stored.
* If you restore an auth mode that needs a credential and none is stored, the restore succeeds with a warning, and publishing stays blocked until you re-enter the credential under the server's Auth settings.
* If a referenced OAuth provider config or shared auth config was deleted after the snapshot was taken, the restore clears that assignment and warns you, rather than pointing at a missing config.

## Deployments

The **Deployments** tab lists every promotion to production and every recall back to development, newest first — who triggered it and when. Deploys made after version-linking shipped also show a **v{n}** chip identifying the exact version snapshot that went live (deploying creates that snapshot automatically), so you can open it in the version list or restore it later. Older deploys, recorded before the link existed, appear without a version chip.

## Change log

The **Change log** tab records each individual mutation — entity, action, author, and timestamp — so you can see exactly what happened between two versions. Secrets and request payloads are never logged; auth changes record only the mode transition.

## Spec import history

The **Spec imports** tab lists every import of the server's API spec, newest first. While versions track *your* configuration, spec imports track *the upstream API* — what your Bubble app, OpenAPI URL, or git repository actually exposed at each import.

Each import row shows:

* **Validation status** — `Valid`, `Invalid` (with the error), or `Pending`.
* **Spec summary** — the spec's title, endpoint count, and declared version.
* **No changes** — shown when a re-import produced an API identical to the previous import, so you can tell no-op re-imports apart from real changes at a glance.

Click **View changes** on an import to see what changed in the upstream API since the previous import:

* **Added endpoints** (`+`) — new in this import; their generated tools start disabled as always.
* **Removed endpoints** (`−`) — gone from the API. If any of your *enabled* tools reference a removed endpoint, a warning names them — those tools will fail at runtime until you disable them or the endpoint returns.
* **Changed endpoints** (`~`) — same method and path, but a different summary, input schema (parameters/body), output schema, or auth requirement. Input-schema changes list the affected properties.

Spec diffs compare the normalized endpoint definitions, so cosmetic reordering inside the raw document never registers as a change. Imports created before spec history was introduced cannot be diffed and do not offer **View changes**.

> **Storage note:** the full raw spec document is retained for the three most recent valid imports per server; older imports keep their normalized endpoint list (used for diffs) indefinitely.