Skip to main content

Upgrades & support

Premora upgrades use the same artifact model as installation: signed, versioned bundles applied with the premora CLI. The flow is identical across connected, registry, and air-gapped delivery.

Upgrading Core​

premora core upgrade \
  --catalog https://downloads.premora.ai/catalog.json \
  --values customer-values.yaml

Air-gapped:

premora core upgrade --offline-media /mnt/usb/premora-offline --values customer-values.yaml

Upgrades:

  • pull (or load, when air-gapped) the new signed bundle,
  • apply database migrations as part of the release, and
  • roll services forward with helm upgrade.

Review the bundle’s upgrade-notes.md / release notes before applying, and verify afterward:

helm list -n premora
kubectl get pods -n premora

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 locally without a cluster:

tar -xzf premora-install-<version>.tar.gz
cd premora-install-<version>
./install.sh --render-only --values customer-values.yaml > /tmp/premora-rendered.yaml