OpenBao Operator 0.4.2

Published 15 July 2026.

0.4.2 lets a healthy, idle OpenBaoCluster change spec.upgrade.strategy between RollingUpdate and BlueGreen. This gives an existing pre-2.6 BlueGreen cluster a supported path to use the validated rolling upgrade to OpenBao 2.6.0.

Decide whether to upgrade

Upgrade from 0.4.1 when an existing cluster needs to change its upgrade strategy. Clusters that already use RollingUpdate can remain on 0.4.1 for the validated OpenBao 2.6.0 rolling upgrade.

Switch an idle strategy

The operator accepts a strategy change only when every voter and configured read replica is Ready, the current and desired OpenBao versions match, and no disruptive operation, pending request, failure, operation lock, or recovery is active.

1. Apply the 0.4.2 CRDs before upgrading the controller. Helm does not upgrade installed CRDs.

   upgrade

   Apply the 0.4.2 CRDs

   Copy

   kubectl apply -f \
     https://github.com/dc-tec/openbao-operator/releases/download/0.4.2/crds.yaml

2. Upgrade the Helm release.

   upgrade

   Upgrade the operator

   Copy

   helm upgrade openbao-operator \
     oci://ghcr.io/dc-tec/charts/openbao-operator \
     --version 0.4.2 \
     --namespace openbao-operator-system \
     --reuse-values

3. Let the cluster return to its healthy, idle state.

4. Change only spec.upgrade.strategy.

5. Wait for status.acceptedUpgradeStrategy to report the requested strategy.

6. Change the OpenBao version, image, replicas, storage, or restart controls in a separate request.

Switching to BlueGreen also requires a resolvable upgrade executor image and a JWT role with the BlueGreen peer-management capabilities. Self-init policies created for a rolling-origin cluster are not rewritten later; update the role policy before requesting BlueGreen when necessary.

Open the published GitHub release for artifacts, signatures, provenance, and the complete generated change list.