Upgrades & versioning

The platform and the operator version independently. How to roll each one forward, the one component Helm won't upgrade for you, and how to back out.

An Industric install has two independently-versioned halves: the platform image (adaptivelive/exo:vX.Y.Z) and the operator image (adaptivelive/autonomic-manager:vX.Y.Z), plus the CRDs that move with the operator. Apply database migrations explicitly before rolling out the new platform image.

Versioning

Both images are semver-tagged. The platform's /api/health stays green through a rolling update; with leader election, the operator's WebSocket reconnects within a second of the new pod taking the lease.

Upgrading the platform

First run exo-server --migrations from the target image in a migration job with the application's database and encryption configuration. Wait for success, then bump the image on the exo-app Deployment and watch the rollout. See Database migrations.

terminal· bash

kubectl -n exo set image deployment/exo-app exo=adaptivelive/exo:vX.Y.Z

kubectl -n exo rollout status deployment/exo-app

exo-install platform --namespace exo --image adaptivelive/exo:vX.Y.Z

Keep the secrets stable

Never regenerate EXO_ENCRYPTION_KEY or EXO_JWT_SECRET during an upgrade. A new encryption key makes existing encrypted columns unreadable; a new JWT secret logs everyone out. Upgrades touch the image, not the Secret.

Upgrading the operator

This is the same sequence the dashboard shows under Update the connector on your deployment's connect dialog: definitions first, then the chart, then a restart so the new image takes over even when the chart version is unchanged.

terminal· bash

kubectl apply --server-side --force-conflicts -f https://exo.assets.adaptive.live/manifests/crds.yaml

kubectl apply --server-side --force-conflicts -f https://exo.assets.adaptive.live/manifests/rbac.yaml

helm repo update exo

helm upgrade autonomic exo/autonomic --namespace autonomic-system --reuse-values

kubectl -n autonomic-system rollout restart deploy/autonomic-manager

Upgrading CRDs

Helm does not upgrade CRDs

CRDs ship in Helm's native crds/ directory, which Helm installs once but never upgrades or deletes. When a release adds fields to a CRD, apply the new definitions yourself before (or alongside) the operator upgrade:

terminal· bash

kubectl apply --server-side --force-conflicts -f https://exo.assets.adaptive.live/manifests/crds.yaml

CRD changes are additive within v1alpha1; applying the newer definitions is safe for existing objects.

Rolling back

Both halves are standard Deployments, so a bad upgrade rolls back the usual way:

terminal· bash

kubectl -n exo rollout undo deployment/exo-app

kubectl -n autonomic-system rollout undo deployment/autonomic-manager

An image rollback does not undo database migrations. Check the target release's schema compatibility and restore the pre-upgrade snapshot if the older image cannot use the migrated schema.