Upgrades & versioning

An Exo install has two independently-versioned halves: the platform image (adaptivelive/exo:vX.Y.Z) and the operator image (adaptivelive/agentkube-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 throughout a rolling update; the operator's leader-election means the 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.

1kubectl -n exo set image deployment/exo-app exo=adaptivelive/exo:v0.2.146
2kubectl -n exo rollout status deployment/exo-app
3 
4# or re-run the installer pinned to the new image
5exo-install platform --namespace exo --image adaptivelive/exo:v0.2.146

Upgrading the operator

1# Helm
2helm upgrade agentkube ./agentkube/helm/agentkube \
3  --namespace agentkube-system --reuse-values \
4  --set image.manager.tag=v1.0.12
5 
6# or raw
7kubectl -n agentkube-system set image deployment/agentkube-manager \
8  manager=adaptivelive/agentkube-manager:v1.0.12

Upgrading CRDs

Rolling back

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

1kubectl -n exo rollout undo deployment/exo-app
2kubectl -n agentkube-system rollout undo deployment/agentkube-manager

Schema migrations are forward-additive, so an image rollback generally works without a database restore — but if a release note flags a destructive migration, restore the database snapshot you took first.