# Updating

> Update plugins and Railbase itself in one click, and how version compatibility is enforced.

_Updated: 2026-06-08_

Railbase updates two things independently: the **plugins** you've installed and
the **core** binary itself. Both are driven from the **Marketplace** in your
admin: when something newer is available, an **"Updates available"** banner
appears there with one-click actions. Both respect a version-compatibility gate.

## Updating a plugin

When a newer version of an installed plugin is published, the Marketplace flags
it (a badge on the plugin, plus the banner up top). Updating:

1. fetches the new build and **verifies it's authentic and unmodified** (the same
   check as a fresh install — see [How plugins work](how-plugins-work)),
2. stops the running version, and
3. starts the new one — **reusing your existing license**, so there's no second
   checkout.

If the new version needs a newer core than you're running, the update is blocked
until you update the core (below).

## Updating Railbase

Railbase can update itself in place. When a newer core is published, the banner
shows **Update Railbase** — one click and your instance:

- fetches the new build and **verifies it's authentic**,
- installs it, and
- restarts into the new version (a few seconds of downtime).

You can also do it the manual way described in [Installation](installation):
download the latest build and restart. Either way, your data is forward-compatible
and schema migrations apply automatically on the next boot.

> [!TIP]
> Take a snapshot before a core update so you can roll back instantly if needed:
> `./railbase backup`. See [Backups & restore](backups-and-restore).

## Compatibility

Every plugin declares a **minimum core version** (`min_core`). The core enforces
it:

- A plugin whose `min_core` is **newer than your core** won't install or run — the
  Marketplace tells you to update the core first.
- The Marketplace also flags when a **core update is available** (comparing your
  running version to the catalogue), so the banner tells you when it's worthwhile.

This is why you occasionally update the core before a plugin: the plugin needs a
capability the older core doesn't have.

## Recommended order

1. **Snapshot** — `./railbase backup`.
2. **Update Railbase** if a plugin needs it (or to pick up fixes), then let it
   restart.
3. **Update plugins** — they pick up the newer core's capabilities.

Because licenses are reused across updates, none of this re-charges you — updates
are purely fetch, verify, and install.