Should I upgrade to OpenBao 2.4 to 2.5 now?
Teams already running OpenBao need change awareness for the 2.4 to 2.5 line, including security-fix cadence and whether to standardize on the current supported branch.
Blockers
- No blockers identified in the graph.
Who this is for
- enterprise
- compliance
- low-ops
Candidates
Standardize on OpenBao 2.5.x
As of 2026-04-08, the OpenBao docs mark 2.4.x as no longer actively maintained and point users to 2.5.x as the latest version. The 2.5.x line released v2.5.0 on 2026-02-04, v2.5.1 on 2026-02-23, and v2.5.2 on 2026-03-25, showing active patch cadence. Verified security fixes in 2.5.x include a breaking secure default for unauthenticated rekey endpoints in 2.5.0, dependency security updates in 2.5.1, and two JWT direct-callback auth fixes in 2.5.2. The official support policy says fixes go into the next release and that the latest release does not EoL, so 2.5.x is the branch to standardize on for ongoing support.
When to choose
Use this when you want the currently supported branch with the shortest path to future security fixes. It is the right default if your team can absorb one config-default change and a few API or plugin-surface removals now instead of carrying branch lag.
Tradeoffs
Best support posture and freshest fixes, but it is not a zero-risk patch jump. You must validate listener config, db plugin integrations, audit format expectations, and any custom automation that depended on removed or deprecated SDK and API fields.
Cautions
2.5.0 changed the default of `disable_unauthed_rekey_endpoints` to `true`; if you still rely on unauthenticated rekey flows, you must set `disable_unauthed_rekey_endpoints=false` explicitly. 2.5.0 also removed deprecated dbplugin `Statements` protobuf fields, removed the `jsonx` audit output format, and 2.5.1 notes that corrupt namespace identity groups may be deleted during unseal and need admin recreation. If you use Auto Unseal with AliCloud KMS, AWS KMS, Azure Key Vault, GCP Cloud KMS, or OCI KMS, do not stop at 2.5.0 because 2.5.1 fixed upgrade and downgrade failures there.
Stay on OpenBao 2.4.4 only as a short-term stabilization step
OpenBao 2.4.4 was released on 2025-11-24 and included a verified security fix for identity-group policy name lowercasing to prevent root policy assignment. Earlier 2.4.x late-2025 releases also fixed two audit-log redaction issues in 2.4.3. However, as of 2026-04-08, the official 2.4.x docs explicitly say this version is no longer actively maintained. This makes 2.4.4 acceptable only as a temporary landing zone if 2.5.x rollout is blocked and you need the late-2025 fixes immediately.
When to choose
Use this only when operational risk from the 2.5 upgrade is higher than the short-term risk of remaining on an inactive branch. It fits tightly controlled environments that need a brief pause for regression testing before moving to 2.5.x.
Tradeoffs
Lower immediate migration scope, but you give up the current supported branch and newer 2026 security fixes. You also take on a second upgrade later instead of standardizing once.
Cautions
Do not treat 2.4.4 as a supported steady state. The support policy routes fixes to the next release, and the 2.4.x documentation banner says the line is no longer actively maintained, so future fixes should be expected on newer releases rather than backported here.
Try with your AI agent
$ npm install -g pocketlantern $ pocketlantern init # Restart Claude Code, Cursor, or your MCP client, then ask: # "Should I upgrade to OpenBao 2.4 to 2.5 now?"