Skip to main content

Operations

To check, back up, scale, upgrade, or remove a Platform as VM deployment, use this page. For installer-time issues, see Troubleshooting.

Access the cluster​

The installer writes a kubeconfig to your home directory and exports KUBECONFIG in ~/.bashrc. Open a new shell on the VM. kubectl then works:

kubectl get nodes
kubectl get pods -A

To reach the cluster from your laptop, copy the kubeconfig off the VM and update the server URL:

scp <user>@<vm-ip>:~/.kube/config ./openlm-vm.kubeconfig

# macOS
sed -i '' 's|127.0.0.1|<vm-public-ip>|' ./openlm-vm.kubeconfig
# Linux
sed -i 's|127.0.0.1|<vm-public-ip>|' ./openlm-vm.kubeconfig

export KUBECONFIG=$PWD/openlm-vm.kubeconfig
kubectl get nodes

This requires port 6443 to be reachable from your machine.

Health checks​

Check that all pods are running​

Run this command:

kubectl get pods -A | grep -v Running | grep -v Completed

On a healthy cluster, the output is empty. Anything in CrashLoopBackOff, Error, ImagePullBackOff, or Pending for more than a few minutes needs investigation. See Troubleshooting.

Check the Helm releases​

Run this command:

helm list -A

Every release shows STATUS: deployed. A release stuck in pending-install or failed is a problem.

Check the ingress​

Run this command:

kubectl get ingress -n openlm

The command lists all the routes Traefik serves. If OpenLM Platform is reachable but specific URLs return 404, check that the corresponding ingress exists here.

Logs​

This section shows how to read logs for one pod, for all pods of a service, and for audit events.

View logs for a single pod​

Run these commands:

kubectl logs <pod-name> -n openlm
kubectl logs <pod-name> -n openlm --tail 100 -f      # follow last 100 lines
kubectl logs <pod-name> -n openlm --previous         # crashed container's last logs

View logs for all pods of a service​

Address the deployment rather than a label. The OpenLM Platform pods do not carry a plain app label, so -l app=<service> matches nothing and returns No resources found:

kubectl logs -n openlm deploy/openlm-identity --tail 50

View audit events​

Audit events are not written to the OpenLM Platform pod logs. They are produced to Kafka and handled by the dedicated audit service. To read them, run this command:

kubectl logs -n openlm deploy/openlm-auditservice --tail 100
No centralized logging in the bundle

The deployment package does not include a log aggregation stack. kubectl logs reads directly from the node, and logs are lost when a pod is deleted or rotated. If you need retained, searchable logs, forward them to your own logging platform.

Scale services​

A single VM caps how far you can scale, but individual services can be adjusted.

Scale a service up​

Run this command:

kubectl scale deployment/openlm-licensemanager -n openlm --replicas=2
Not every service is safe to scale

Most OpenLM Platform services are stateless and tolerate multiple replicas. A few hold shared state and must stay at a single replica. Check with OpenLM support before scaling a service you have not scaled before. Running two replicas of a stateful service can cause duplicate processing.

Turn a service off​

Use one of two options, depending on whether the change should survive an upgrade.

To turn a service off temporarily, run this command. The next installer run reverts the change.

kubectl scale deployment/<service> -n openlm --replicas=0

To turn a service off permanently, set enabled: false for that sub-chart in the OpenLM Platform values and run the installer again.

Suspend a scheduled job​

Run this command:

kubectl patch cronjob/<name> -n openlm -p '{"spec":{"suspend":true}}'

Set suspend back to false to resume.

Back up and restore​

OpenLM Platform has two main classes of state to back up:

  • Persistent volume data: Kafka, MongoDB, PostgreSQL, and MariaDB data on disk. This is the bulk of the backup size.
  • K3s cluster state: The embedded datastore that holds Kubernetes objects (for example, deployments and secrets). Small and quick to restore.

Any external service you configured instead of a bundled one is out of scope here. Back up external SQL Server, managed Kafka, or external MongoDB with your usual tooling for those platforms. VM snapshots do not capture them.

VM-level snapshots​

For most customers the simplest reliable backup is a hypervisor- or cloud-provider snapshot of the whole VM. K3s, all persistent volumes, and system state are captured in one consistent image. Use VM-level snapshots when you can.

If your VM platform supports it, schedule daily snapshots and retain them according to your recovery point objective (RPO) and recovery time objective (RTO) policy.

Database-level backups​

For more granular RPO, or when you need to extract data without restoring the whole VM:

PostgreSQL (reporting)​

Run these commands:

kubectl port-forward -n openlm-infrastructure svc/postgres-postgresql 5432:5432 &
PGPASSWORD='<postgres-password>' pg_dump -h localhost -U postgres \
  openlm_reporting_db | gzip > reporting-$(date +%F).sql.gz
kill %1

MariaDB (operational)​

Run these commands:

kubectl port-forward -n openlm-infrastructure svc/mariadb 3306:3306 &
mysqldump -h localhost -u root -p<mariadb-root-password> \
  --all-databases | gzip > operational-$(date +%F).sql.gz
kill %1

MongoDB​

Run this command:

kubectl exec -n openlm-infrastructure mongodb-0 -- \
  mongodump --archive --gzip \
  --uri "mongodb://admin:<mongodb-root-password>@localhost:27017/?authSource=admin" \
  > mongo-$(date +%F).archive.gz

Replace <postgres-password>, <mariadb-root-password>, and <mongodb-root-password> with the passwords you set in passwords.yaml.

Restores follow the reverse pattern: port-forward and pipe the dump into psql, mysql, or mongorestore. Scale down the consuming services first so they don't write while a restore is in flight.

Upgrade the deployment​

The deployment package is versioned. To upgrade:

  1. Receive the new deployment package from OpenLM.
  2. Unpack it on the VM at a new path (for example, ~/platform-as-vm-2026-05/). Don't overwrite the previous package, because you might want it for rollback.
  3. Copy your existing config.yaml into the new directory and reconcile any new options.
  4. Copy passwords.yaml from the previous deployment directly. It must contain the same passwords the bundled databases were initialized with.
  5. Run ./entrypoint.sh from the new directory.

The playbook is idempotent: it detects K3s, namespaces, and secrets and leaves them alone. It upgrades Helm releases in place with the new chart versions, rolling pods one at a time. Brief downtime of individual services is normal during the upgrade. Total OpenLM Platform downtime is normally less than a minute per service.

Note

Database schema migrations are handled automatically by the AllDbUpgradeAPI service on first startup of the new version. Do not delete that service.

For major version upgrades that skip multiple releases, contact OpenLM support. Some data migration steps might be needed between specific versions.

Rolling back​

If an upgrade fails or behaves incorrectly:

  1. cd into the previous deployment directory.
  2. Run ./entrypoint.sh again.

This downgrades each Helm release back to the previous chart version.

Warning

Schema migrations are not reversible. If the new version already ran AllDbUpgradeAPI, you cannot roll back the database. Restore from a backup if you need to undo schema changes.

Maintenance windows​

Plan upgrades and database-level operations during a maintenance window. OpenLM Platform tolerates pod restarts well, but:

  • Active end-user sessions might be briefly interrupted.
  • Reporting ETL jobs might need to run their last batch again.
  • Integrations with external systems (for example, ServiceNow) queue events in Kafka until services come back.

A 30-minute maintenance window is sufficient for a routine upgrade.

Uninstall OpenLM Platform​

To completely remove OpenLM Platform and K3s from the VM, run this command:

sudo /usr/local/bin/k3s-uninstall.sh
Uninstalling deletes all data

k3s-uninstall.sh removes everything under /var/lib/rancher/k3s: the cluster, all persistent volumes (including all your data), and all container images. You can't undo it. Take a VM snapshot first if you might want to recover.

It does not clean up the kubeconfig the installer placed in your home directory, or the export KUBECONFIG line it added to ~/.bashrc. Remove ~/.kube/config and that line yourself if you want a clean shell.

To also remove the certificate directory and the deployment package, run these commands:

sudo rm -rf /etc/openlm
rm -rf ~/platform-as-vm*
Last updated on by Maria Gilca

The documentation team might draft this page using a large language model. A technical writer reviews every page and verifies it against the product before publishing it. A human makes the final decision.