Upgrade

To upgrade an existing OpenLM Platform deployment, follow the steps on this page.

First-time installation

For first-time installation, start with Deployment paths to select your setup path, and then continue with Platform installation.

Platform as VM upgrades differently

If you deployed with Platform as VM, do not use the Helm commands on this page. That deployment's release is named openlm-platform, so helm upgrade monohelm fails with release: not found. Even with the right name, a direct helm upgrade skips the installer's values rendering, password handling, Kafka topic creation, and post-upgrade rollout.

Upgrade it by unpacking a newer deployment package and running ./entrypoint.sh again. See Platform as VM upgrades.

The following steps apply to the manual Kubernetes deployment paths: on-premises machines, AWS, and Azure.

Before you upgrade

Complete these steps before starting the upgrade:

• Obtain the new deployment package from OpenLM, along with the release notes for that version. Review them for breaking changes, migration steps, or required database changes.
• Back up your databases before applying the upgrade. A backup makes a rollback possible, as described in Rollback.
  • For managed databases (RDS, Azure SQL), take a snapshot through the provider.
  • For in-cluster databases, the dump commands in Platform as VM operations apply to any Kubernetes deployment.
• Confirm that all pods are healthy before starting (kubectl get pods -n openlm).

Apply the upgrade

Run this command:

helm upgrade monohelm openlm_mono-<new-version>.tgz \
  -f mono-values.yaml \
  -n openlm \
  --timeout 20m

Use the same release name you installed with, and the values file from your current deployment. The longer timeout is deliberate: with over 100 services, the default 5 minutes is often not enough.

After you upgrade

Complete these steps after the upgrade finishes:

• Monitor pod startup: kubectl get pods -n openlm -w
• Verify core services are healthy and responding.
• Validate data flows (license events, reporting pipeline, directory sync).
• Check the OpenLM Platform UI for errors.

Rollback

If the upgrade causes issues, Helm can roll the release back to the previous revision:

helm rollback monohelm -n openlm

Helm rollback does not undo schema migrations

The AllDbUpgradeAPI service applies database schema migrations automatically when the new version starts, and they are not reversible. helm rollback reverts only the Kubernetes objects, which leaves the previous application version running against an already-migrated schema.

If the new version has already migrated the schema, restore the databases from the backup you took before upgrading.