Skip to content
Docs

Upgrading

An upgrade is an image swap. Nothing about your deployment is regenerated.

Everything in the data volume: the model registry, users and roles, API keys, the audit log, downloaded models, cluster and node definitions, per-server settings, and the licence.

Keep the data volume. Losing it loses the licence binding along with everything else, and the licence has to be re-issued against the new cluster identity.

Terminal window
docker compose down
docker compose pull
docker compose up -d

On NVIDIA the host-setup step re-runs, which is idempotent and is what keeps GPU access working across driver upgrades.

Terminal window
helm repo update
helm upgrade lifeboat lifeboat/lifeboat --reuse-values

Download the new installer and install over the existing app, or use Check for Updates… in the tray. The data directory is untouched.

  • :latest, :latest-rocm, :lite roll forward.
  • :2.2.44 and similar are immutable — a version tag, once published, always resolves to the same image. Pin one in production.

Container and desktop versions are released on separate cadences and are not expected to match. A desktop version is not a pullable image tag. If the desktop app is several numbers ahead of the newest image, nothing is wrong.

  1. GET /api/version — confirm the version you expect.
  2. Start a server and make a request. A build that starts is not the same as a build that serves.
  3. Check the Alerts page for anything raised during the restart.
  4. If a model’s capabilities look wrong, use Refresh probe — though Lifeboat re-probes automatically when a cached record came from a version known to have recorded something incorrectly.

Version tags are immutable, so rolling back is pulling the previous tag. The data volume is forward-compatible within a major line; a downgrade across a schema change is not supported, so take a copy of the data volume before a large jump.