Known Limitations

Known limitations and non-goals

Current constraints and explicit non-goals for the pre-GA line.

Reference table

Current constraints

Current constraints.

Area	Current limitation	What to do instead
CRD versioning	The current served and storage API is openbao.org/v1alpha1; multi-version conversion webhooks are out of scope today.	Treat API evolution through the pre-GA contract and review release notes carefully.
Cluster adoption	The operator assumes it manages clusters it created and reconciles; generic import of arbitrary unmanaged OpenBao clusters is out of scope.	Create operator-managed clusters directly, or use backup and restore workflows when you need to move data into a new operator-managed cluster.
Operator downgrade	Routine downgrades are unsupported.	Use the recovery and restore guidance when a release cannot move forward safely.
External backup cleanup	DeleteAll removes PVC-backed data but does not delete snapshot objects already written to external object storage.	Clean external backup objects explicitly as part of decommission procedures.
etcd encryption verification	The operator cannot directly prove cluster-level etcd encryption at rest and surfaces a warning condition instead.	Validate cluster-level encryption controls outside the operator.
Helm CRD lifecycle	Helm does not automatically upgrade or delete CRDs.	Use release crds.yaml assets for CRD lifecycle operations.
Built-in upgrade authentication	Built-in rolling and blue/green upgrade orchestration do not support spec.upgrade.tokenSecretRef; upgrade Jobs use JWT authentication only.	Configure spec.upgrade.jwtAuthRole, or use the default role created during initial selfInit.oidc bootstrap.
Audit file storage archival	spec.auditFileStorage provides a PVC-backed collector handoff and replay buffer; it does not provide rotation, pruning, tamper-proof retention, or a collector.	Mount the audit PVC read-only into a collector and ship records to external retention-controlled storage.
OpenBao 2.6.0 BlueGreen upgrade	OpenBao 2.6.0 cannot exchange Raft Autopilot health with pre-2.6 peers because its internal request-forwarding gRPC service name changed. The operator blocks pre-2.6 to 2.6-or-newer BlueGreen transitions before deploying Green until a compatible target is explicitly qualified.	Return the cluster to a healthy, idle BlueGreen state, change only spec.upgrade.strategy to RollingUpdate, wait for status.acceptedUpgradeStrategy=RollingUpdate, and then request 2.6.x. Fresh 2.6.x clusters and rolling upgrades remain supported.

Related caveat and recovery pages

Support policyMaintenance contract and release lines that remain in scope.Upgrade compatibilityRollback stance and CRD sequencing for operator upgrades.Decommission a clusterOperational decommissioning workflow for external-backup caveats.Restore from backupRecovery or migration workflow when an in-place change is not available.