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 Exo 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. Upgrades are ordinary rolling updates; the backend re-runs its idempotent migrations on the new pods at boot.
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
Bump the image on the exo-app Deployment and let the rollout run. Migrations apply automatically as the new pod starts.
kubectl -n exo set image deployment/exo-app exo=adaptivelive/exo:v0.4.8
kubectl -n exo rollout status deployment/exo-app
exo-install platform --namespace exo --image adaptivelive/exo:v0.4.8
Upgrading the operator
helm repo add exo https://exo.assets.adaptive.live/charts
helm repo update
helm upgrade autonomic exo/autonomic \--namespace autonomic-system --reuse-values
kubectl -n autonomic-system set image deployment/autonomic-manager \manager=adaptivelive/autonomic-manager:v0.3.1
Upgrading CRDs
Rolling back
Both halves are standard Deployments, so a bad upgrade rolls back the usual way:
kubectl -n exo rollout undo deployment/exo-app
kubectl -n autonomic-system rollout undo deployment/autonomic-manager
Schema migrations are forward-additive, so an image rollback usually works without a database restore. If a release note flags a destructive migration, restore the database snapshot you took first.