Upgrades & versioning

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:vX.Y.Z

kubectl -n exo rollout status deployment/exo-app

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

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.

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

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.