Upgrades
How to upgrade the control plane and your nodes to a new Rivet release.
Every control plane instance must run the same release. Keep each instance’s disk across an upgrade: it holds recent writes and the instance’s identity.
Upgrading the control plane
The first upgrade of this control plane requires a full stop. Stored formats do not support mixed versions, so never run two releases side by side. Schedule a maintenance window and preserve every disk and the bucket.
Stop every instance
kubectl -n rivet scale statefulset/rivet --replicas=0
kubectl -n rivet wait --for=delete pod -l app=rivet --timeout=700s
Wait until all control plane pods have terminated before changing the image. Clients get errors during this window; nodes reconnect when the cluster returns.
Change the image
Set the new pinned version everywhere, for example rivetdev/engine:2.3.32.
Start every instance
kubectl -n rivet scale statefulset/rivet --replicas=3
kubectl -n rivet rollout status statefulset/rivet
Later releases may support rolling upgrades when their release notes explicitly permit mixed versions. For those releases, restart one instance at a time, wait for it to become healthy and finish recovery, then move to the next. Preserve its disk throughout.
Upgrading nodes
Upgrade the Rivet SDK in your app and roll your nodes as you would any deploy. The control plane accepts nodes whose SDK release is behind its own, so upgrade the control plane first.