Skip to main content

Upgrades & support

Premora upgrades use the same artifact model as installation: signed, versioned bundles applied with the premora CLI. Premora runs as a single-box omnibus (Docker Compose); an upgrade loads the new image and recreates the services in place. The flow is identical across connected and air-gapped delivery.

Upgrading Core​

premora update --channel stable

Air-gapped:

premora core upgrade --offline-media /mnt/usb/premora-offline

An upgrade:

  • pulls (or loads, when air-gapped) the new signed bundle,
  • takes an automatic, integrity-verified backup (every service database + the MinIO raw archive + the current compose/.env) so you can roll back, then
  • loads the new image and recreates the services (docker compose up -d), applying database migrations as the stack comes up.

Review the release notes before applying. Verify afterward:

premora backup list          # confirm a pre-upgrade backup was captured
docker compose ps            # (from the install dir) all services healthy

Backups​

Migrations are forward-only (the same model as Bitbucket/Jira/Confluence), so the way back from a bad upgrade is restore a backup. Upgrades back up automatically, and you should also take periodic backups so you can recover from problems discovered later — a backup is the recovery point:

premora backup create        # on-demand backup (schedule via cron for regular points)
premora backup list          # what's available
premora backup verify        # confirm the newest backup is intact and restorable

Rolling back a bad upgrade​

premora restore                    # return to the newest backup
premora restore --to <backup-id>   # or a specific one

Restore reloads the backed-up image, restores the databases and the MinIO archive, and brings the stack back up. It returns the box to the backup point, so writes made since that backup are lost — exactly like restoring an Atlassian Data Center backup. Catching a bad upgrade quickly (when the pre-upgrade backup is still current) keeps that loss at zero; periodic backups shrink it for issues found later. To de-risk a major upgrade, restore the latest backup onto a spare/staging box and upgrade that first.

Not supported: a second always-on "standby" server. A blue/green pair of live instances is a deliberate non-goal for the single-box product — it would double stateful storage (Postgres + the potentially very large MinIO archive) and requires control of a reverse proxy Premora does not own. Backup + restore delivers the fall-back outcome, the same way Atlassian Data Center does.

Upgrading Inference​

Inference upgrades separately, with the same model:

premora inference upgrade

Support bundles​

When you need help, collect a support bundle — logs, Helm/pod status, and version info — into a single archive for escalation:

premora support collect

Backups & continuity​

Because one deployment serves a single enterprise and runs inside your perimeter, back up the backing services you provisioned in requirements — Postgres, object storage, and the search/vector indexes — per your own continuity policy. The core browse-and-search path is designed to keep working through upstream connector failures (degraded mode), so a single source being unavailable does not take down knowledge access.

Verifying a bundle before applying​

You can validate a bundle on the host without starting it:

tar -xzf premora-install-<version>-linux-<arch>.tar.gz
cd premora-install-<version>-linux-<arch>
./preflight.sh                       # confirm Docker + Compose v2 are present
docker compose config >/dev/null     # confirm the compose file parses