Support Policy
Use this page when you need the exact maintenance contract behind a release line or channel.
Validation and support are related, but they are not the same thing. This page defines which release lines receive best-effort maintenance attention, how channels differ, and what the project expects from operators before they ask for issue triage.
Current support window
The project provides best-effort support for the latest stable release line.
Reference table
Release channels
| Channel | What it is for | Support stance |
|---|---|---|
Stable (X.Y.Z) | Real deployments and the main production line. | Best-effort support on the latest stable line. |
Prerelease (-rc, -beta, -alpha) | Evaluation before the next stable release. | No expanded support window; use for testing and early adoption only. |
Edge (main snapshots) | Continuous validation and integration signal. | Not a production support channel. |
| Nightly | Scheduled validation snapshots. | Not a production support channel. |
Pre-GA release contract
OpenBao Operator is still pre-GA:
- the served CRD API is
openbao.org/v1alpha1 - minor releases may introduce breaking API or behavior changes
- support is best-effort and focused on the latest stable release line
Validation versus support
- Compatibility Matrix defines what is explicitly validated in CI.
- This page defines what receives best-effort maintenance attention.
Recommended for productionmeans the documented hardened operating path, not a promise of long-lived pre-GA API stability.
Security fixes
Security fixes follow SECURITY.md:
- security fixes are provided for the latest released version
- vulnerabilities should be reported through GitHub Security Advisories
Reference table
Operator expectations for production use
| Expectation | Why it matters |
|---|---|
| Pin explicit operator and chart versions | Floating channels make support and rollback reasoning weaker. |
| Stay close to the latest stable release | The project focuses its maintenance effort on that line. |
Use the Hardened profile with admission enforcement enabled | This is the documented production posture behind most guidance. |
| Validate upgrades in staging | Best-effort support does not remove the need for environment-specific rehearsal. |
| Avoid prerelease, edge, and nightly for production | These channels are designed for evaluation and validation, not supported production drift. |
Related support references
Compatibility matrixOpen the validation matrix when the next question is whether a platform or version is exercised by CI.Known limitationsCheck current caveats and non-goals when an unsupported behavior might actually be a deliberate constraint.Release managementUse the maintainer release workflow when you need the operational process behind these support promises.
Prerelease documentation
This version tracks a prerelease build. Features and behavior may change before the next stable release.
Was this page helpful?
Use Needs work to open a structured GitHub issue for this page. The Yes button only acknowledges the signal locally.