What upgrades and support cover for OpenBao
Once OpenBao is running, the ongoing work is keeping it on a supported minor release line, applying security patches promptly, and upgrading the cluster without interrupting the applications that depend on it. OpenBao publishes releases on its GitHub releases page, and the documented pattern is a current line (for example v2.7.x, with v2.7.0 released on September 23, 2026 and v2.7.1 on October 1, 2026) alongside the previous line (v2.6.4 was released the same day as v2.7.1). Confirm the current support window for each line with the OpenBao project before you plan an upgrade calendar, because it determines how long you can stay on a given line.
Four triggers usually start an upgrade: a minor line reaching the end of support for your team, a security advisory that affects your version, a feature you need that exists only in a newer line, and a cluster that was built on an older Vault base and still carries migration leftovers. The last one deserves a check of its own. Confirm that disable_mlock has been removed from every node configuration and that the cluster was not bootstrapped before Vault 1.3 without a rekey.
For a multi-node cluster, the upgrade is a rolling operation on Raft or PostgreSQL-backed HA. Standbys are replaced first, leadership is handed off, and the old leader is upgraded last. Check which storage backend you run, because the failover behavior and the read-only standby behavior differ between them. Rehearse the sequence on a staging cluster built from a recent backup, and record how long leader election took and whether clients reconnected cleanly.
A team with HA experience and a tested staging cluster can often patch in-house. Teams that hold production secrets for many applications, run multi-node clusters, or have not performed a rolling upgrade recently usually bring in a partner for the upgrade and a support agreement. Ask any partner for a written scope covering the rehearsal, the cutover window, rollback steps, and who is on call during the change. Support agreements are a separate, recurring line item from the one-time upgrade work.
What the work includes
Each package has its own deliverables and acceptance checks. The scope, versions and cluster details are agreed in writing before work starts, so you know what is covered and what stays with your team.
Release tracking and upgrade plan
We track OpenBao minor release lines and patch releases, including v2.7.0 (September 23, 2026), v2.7.1 (October 1, 2026) and v2.6.4 for the previous minor line, and map each one to your running version. The deliverable is a written upgrade plan with the target version, node sequence, rollback point and the release notes that affect your configuration.
Pre-upgrade checks
Before any node changes, we review the configuration, including removing disable_mlock for OpenBao 2.0.0 and later, confirm storage compatibility, verify that backups restore, and run a rekey check for clusters bootstrapped before Vault 1.3. Deliverables are a findings list, backup verification results and an approved change record.
Rolling upgrades for Raft and PostgreSQL clusters
Raft clusters are upgraded one node at a time while quorum and the leader are checked after each step. PostgreSQL-backed clusters are upgraded with the same node-by-node approach, with the database kept under its own backup and maintenance schedule. Deliverables are staging test results, a step log per production run and rollback notes.
Security patch rollout
We assess each OpenBao security patch against your running version and configuration, then test it in staging before production. Patches that cannot be applied immediately are listed with the reason and the compensating control in place. Deliverables are a patch assessment, a dated change record for each environment and a deferred-fix register.
Post-upgrade verification
After each upgrade we test a login for every auth method in use, confirm each secrets engine responds, check that audit devices still write entries, and verify that dynamic credential leases issue, renew and revoke as expected. Deliverables are a verification report with a pass or fail result for each item and the evidence behind it.
Runbook, handover and support retainers
The runbook is updated with the new version, node layout, upgrade and rollback steps, then handed to your operators in a walkthrough. Support retainers, set out in the written scope, can cover release monitoring, scheduled patching and on-call response, with the service levels and response terms confirmed before you sign. Deliverables are the updated runbook, a handover record and the retainer terms.
What drives upgrade effort and cost
This table lists the factors that change how much work an OpenBao upgrade takes, with the reason each one matters and how to reduce it, so you can read the written scope against your own cluster.
| Driver | Why it matters | How to keep it down |
|---|---|---|
| Node count and topology | More nodes mean more rolling restarts, more health checks and more unseal steps, and multi-region or DR pairs add a second cutover to plan. | Keep the cluster to the node count your availability target needs, document the upgrade order for active and standby nodes, and rehearse it in a non-production copy. |
| Storage backend (Raft or PostgreSQL) | Raft is tied to the cluster's own consensus state and needs careful snapshot and membership handling, while the OpenBao storage docs describe PostgreSQL as easier to operate safely. | Confirm your backend choice early, take and test snapshots before each step, and factor backend-specific runbooks into the scope. |
| Size of the version gap | Moving across several minor lines means more changed behavior, deprecations and configuration keys to review than a single-line move. | Upgrade in planned steps along supported lines, read each release note, and avoid carrying a long gap into a security patch window. |
| Number of auth methods | Each method (AppRole, JWT/OIDC, Kerberos, LDAP, Kubernetes, TLS certificates and others) needs its configuration and login path re-verified after the change. | Inventory every enabled method, remove unused ones before the upgrade, and write a short login test for each one that must pass. |
| Number of secrets engines, namespaces and custom plugins | Each mount, namespace and plugin adds configuration to check, and custom plugins must be rebuilt or confirmed against the target version. | Reduce unused mounts, keep namespace layout documented, and confirm plugin compatibility with the target release before scheduling. |
| Consuming systems that depend on leases and dynamic credentials | Applications holding leases or dynamic database credentials can fail or re-authenticate during node restarts if renewal logic is weak. | Map which workloads use dynamic secrets, check their renewal and retry behavior, and plan a test that restarts nodes while those workloads run. |
| Number of environments and change windows | Each environment needs its own run, and limited change windows force smaller batches and more coordination with application owners. | Standardize one runbook across environments, promote changes from lower environments first, and agree change windows before dates are set. |
| Compliance evidence requirements | Change records, pre and post checks, backup proof and approvals must be captured for auditors, which adds documentation work to every upgrade. | Agree the evidence list in advance, generate it from the runbook steps, and keep it in your change system. Auditors and certification bodies make the assessment, not DeployOpen. |
| Origin: Vault Community or Enterprise | The migration guide documents in-place replacement only for Vault 1.14.1 community edition. Enterprise-origin or other Vault versions need a separate assessment before any upgrade plan is fixed. | Record your exact Vault or OpenBao version and edition now, and confirm with the vendor and the migration guide which path applies to your cluster. |
How an upgrade project runs
The sequence moves an OpenBao cluster to a newer release with a tested rollback point, one node at a time, and leaves your team with a runbook and a support schedule.
Assess the current version and configuration
DeployOpen reviews the running OpenBao or Vault version, storage backend, HA layout, auth methods, secrets engines, namespaces, audit devices and configuration files, including any settings the migration guide says must be removed. The output is a written assessment listing each change required, each risk found and the target release, which you approve before planning starts.
Plan and rehearse in a staging cluster
The upgrade is rehearsed in a staging cluster that mirrors production in release, storage backend, node count, TLS and client endpoints. DeployOpen writes the node order, configuration changes, health checks and rollback steps, then runs the full sequence in staging. The output is a rehearsal record with any deviations and the corrected procedure your team signs off on.
Take and verify backups
Before production changes begin, a snapshot of the storage backend is taken and restored into an isolated environment to confirm it is readable and complete. For Raft clusters this means a snapshot test, and for PostgreSQL it means a verified database backup. The output is a restore test result and a recorded backup identifier that the rollback plan references.
Perform the rolling upgrade with health checks
Standby nodes are upgraded first, one at a time, and the cluster is checked for healthy leadership, replication, unsealed status and client connectivity before the next node is touched. The active node is upgraded last after a leader change is confirmed. The output is a per-node log of version, health result and timestamp, with the cluster reporting a single healthy leader on the target release.
Verify functionality and consumers
Test authentication through each enabled auth method, secret reads and writes, dynamic credential issuance and revocation, encryption as a service, PKI issuance where used, and audit log output. Confirm that applications, Kubernetes integrations and automation pipelines work against the upgraded endpoints. The output is a signed test report listing each consumer tested and any open defects with owners.
Hand over the runbook and set the support schedule
DeployOpen delivers the updated runbook covering the new configuration, the rollback procedure, backup and restore steps and monitoring checks, then walks your operators through it. The support schedule for future minor releases and security patches is agreed in writing. The output is the accepted runbook and a documented schedule, with ongoing support available through a retainer if you choose one.
What usually goes wrong
Most OpenBao upgrade problems trace back to a short list of decisions made before the change window. Each card names the check that prevents it.
Stale settings and bootstrap state
Two items carried over from Vault can block or stall the move. The disable_mlock setting must be removed from configuration when you move to OpenBao 2.0.0 or later, because OpenBao stopped using mlock in that release. Clusters bootstrapped before Vault 1.3 may also need a rekey first. Prevention: diff each node's configuration against the migration guide and confirm rekey status before any binary is replaced.
Quorum loss during Raft upgrades
Raft clusters lose quorum when nodes are stopped in the wrong order, and each leader change interrupts clients still connected to the old active node. Upgrade standbys first and the leader last, one node at a time, confirming a healthy leader and peer list before moving on. Prevention: script the sequence and rehearse a leader failover in staging before the production window.
Backups that were never restored
A backup that has never been restored is an assumption about recovery. Snapshots can complete while the restored cluster fails to unseal, reconnect to its auto-unseal key, or accept existing tokens. Prevention: restore a recent snapshot into an isolated cluster on a schedule, then verify secrets, auth methods and audit devices work before counting the backup as usable.
Assuming Enterprise matches the tested path
The migration guide was tested only against Vault 1.14.1 community edition, not Vault Enterprise. Enterprise features, newer Vault lines and clusters with different replication or licensing setups may behave differently during the in-place replacement. Prevention: confirm your exact edition and version, then run the full procedure in a staging copy with production-shaped data before scheduling a change.
Custom plugins and templates breaking
Custom secrets engines, auth plugins and policy templates depend on the API surface of a specific release, so a new minor line can break them. Teams often discover this only after cutover. Prevention: keep an inventory of each plugin with its version and owner, rebuild each one against the target release, and run its tests in staging before promotion.
Patch backlog with no release owner
Security fixes are published on the OpenBao releases feed, and without a named owner they sit unread while the cluster runs an older line. Prevention: assign one person to watch the feed, set a fixed review cadence, and agree in advance how a security patch moves from staging to production. Record each decision, including the decision to defer, so the backlog stays visible.
Recurring costs after go-live
This table lists the recurring cost items after an OpenBao rollout, who usually pays for each one, and what changes the amount, so you can ask for each as a separate line in a quote.
| Cost item | Who pays | What changes the amount |
|---|---|---|
| OpenBao licensing | Nobody, for the software itself | OpenBao is licensed under MPL-2.0, so there is no license fee. Confirm with your legal team how the license applies to any modifications you distribute. |
| Staging capacity for upgrade rehearsals | Your organization, through its cloud or data center account | Size of the production cluster, number of storage nodes, and how often you rehearse each minor release and security patch before production. |
| Standby nodes, storage and backups | Your organization, through its infrastructure budget | Raft or PostgreSQL topology, node count for HA and read scaling, snapshot retention, backup copies kept off-site, and the storage class used. |
| Internal time for release monitoring and patching | Your platform or security team, as staff time | How many release lines you follow, how quickly you apply security patches, change approval steps, and how much of the upgrade work you do in house. |
| Support retainer or on-call coverage | Your organization, to a support provider or from internal rota | Which support you buy, response expectations, hours covered, and whether upgrades, patch testing and restore tests are included. Ask for this as its own line item. |
| Internal skills for rolling upgrades and restore tests | Your organization, through hiring, training or contractor time | Staff turnover, the number of people trained on Raft or PostgreSQL recovery, and how often restore tests and failover drills are run and documented. |
How upgrades differ by starting point
Raft clusters upgrade one node at a time, and the order of work and the checks between steps decide whether quorum holds throughout. Confirm the current leader and voter health before any node is touched.
- Node order: Upgrade standby nodes first and the active node last, so each restart is observed before leadership moves.
- Snapshot: Take a Raft snapshot and verify that it can be read before the first change, and store it outside the cluster.
- Quorum check: After each node returns, confirm that all voters report healthy before the next node restarts.
- Inputs you provide: A node inventory with roles, the snapshot storage location and the prior release binary for rollback.
PostgreSQL-backed clusters add a database to the change plan. Maintenance windows, backups and failover behavior must be agreed with the database owner before the OpenBao sequence is fixed.
- Maintenance coordination: Schedule any PostgreSQL minor or major maintenance so the database is not changing while OpenBao nodes restart.
- Read standbys: Since v2.7.0 extended read-only operations from standbys to PostgreSQL, confirm how load balancer routing treats standbys during the rolling upgrade.
- Read validation: Test that reads served by standbys return expected results at each step, not only at the end of the change.
- Inputs you provide: A database administrator contact, the maintenance calendar, recent backup and restore evidence for the database and the load balancer configuration.
Clusters that began as HashiCorp Vault follow the in-place replacement path in the migration guide. The starting version and configuration decide what to check first.
- Version and edition: The guide was tested only against Vault 1.14.1 community edition. Enterprise editions and other versions need separate validation before you rely on the path.
- Bootstrap history: Clusters bootstrapped before Vault 1.3 may need a rekey before the move.
- Configuration: Remove disable_mlock, since OpenBao stopped using mlock in 2.0.0.
- Replacement: Replace the server process on all nodes. Configuration, endpoints and URLs stay the same, so verify client connectivity afterward.
- Inputs you provide: The Vault version and edition, the bootstrap record and the configuration file for each node.
Offline environments change how a release reaches the cluster. Each artifact is validated and staged inside your network before any node is changed.
- Acquisition: Download release artifacts and checksums from the official releases page on a connected system, then move them through your approved transfer process.
- Verification: Check signatures and checksums using the verification steps in the release notes, and record the results in the change record.
- Internal staging: Mirror binaries and any container images to an internal artifact store or registry that the cluster can reach.
- Advisory review: Review release notes and security advisories on a connected system before the transfer starts, because the offline site cannot check them live.
- Inputs you provide: A transfer approval, the internal artifact repository, a named owner for verification records and a staging environment.
Kubernetes upgrades run through image references and pod lifecycle settings, so the plan centers on what the manifests pin and how probes gate each pod.
- Image pinning: Pin image tags or digests in the manifests. Floating tags such as latest make it unclear which release is running.
- Rolling restarts: Set the update strategy so pods replace one at a time, and confirm the workload type fits your storage backend.
- Probes: Configure readiness and liveness probes against endpoints documented for the target version, so a pod only receives traffic when it is ready for its role.
- Disruption limits: Use pod disruption budgets so node drains cannot remove more pods than the cluster can lose.
- Inputs you provide: The Kubernetes version, the chosen install method, storage class details and the internal image registry.
What you need to provide
Before any upgrade work starts, the client provides access to the current OpenBao cluster and its configuration files. Secrets inside those files, such as storage credentials, auto-unseal references and TLS private keys, are handled under the client's own rules, so the team should agree in advance on how DeployOpen engineers view configuration: read-only exports with secrets redacted, or supervised sessions on hosts the client controls. Unseal keys and root credentials stay with the client's custody process. DeployOpen does not take custody of them, and the upgrade plan assumes the client can supply unseal material on demand during the change window.
The client also supplies a current inventory that the upgrade plan depends on. It should record the running OpenBao version, the storage backend (integrated storage on Raft or PostgreSQL) and its topology, enabled auth methods, secrets engines and their mount paths, namespaces, any custom plugins, and the consuming applications and automation that call the API. Each consumer should be tagged with its owner. Without this list, compatibility checks against the target release cannot be completed, and the team will be guessing which integrations break when the server process is replaced.
The client provides a staging environment that mirrors production topology closely enough to rehearse the upgrade, or agrees in writing to fund one as part of the scope. The client also provides recent backups and a record of a successful restore test, because a rollback plan is only as good as the last backup that was proven readable. Change windows, approval authority and a rollback decision owner must be named. Finally, the client names an owner for the platform, one for security and one for each major application team, and makes a clear choice on the support model: a fixed-scope upgrade only, or a retainer covering ongoing patching and release tracking.
Questions buyers ask before hiring help
Can our own team run OpenBao upgrades, and what skills does it need?
Yes, a team with Linux administration, TLS and certificate handling, and Vault or secrets-platform operations experience can run OpenBao upgrades itself, provided it follows a tested runbook. Skills to check: service management on each node, administration of the storage backend (integrated Raft or PostgreSQL), configuration changes, and the unseal and recovery process. Confirm the target version on the OpenBao releases page on GitHub before planning, because patch releases carry security fixes. If the cluster still runs HashiCorp Vault, the migration path comes first. See the OpenBao migration topic on this site.
What drives the cost of an OpenBao upgrade, and what should a quote include?
Cost follows the written scope. The main drivers are the number of clusters and environments, the storage backend, how many applications and integrations depend on the cluster, the number of version steps, and the test and rollback evidence you require. One-time work covers assessment, runbook, rehearsal and the production change. Recurring costs appear only if you buy ongoing support or a retainer. Ask for a quote that lists each environment, each step, the rollback plan, what your team provides, and what is excluded.
How long does an OpenBao upgrade take, and what does our team provide?
Duration depends on the written scope, so it varies by environment count, version gap, and the change windows you allow. Delays most often come from slow access approvals, missing test environments and unavailable owners. Your team typically provides administrator access to nodes, current configuration and policy exports, recent backup evidence, a non-production environment, named approvers, and staff available during the cutover window. Ask for a schedule tied to milestones, with each client dependency listed and its owner named.
Does upgrading a clustered OpenBao deployment require downtime?
A healthy clustered deployment can often be upgraded one node at a time, so clients keep service during the process. This depends on the cluster being healthy and the procedure fitting the version you move to. With integrated storage (Raft), the cluster must keep quorum throughout, so standby nodes are normally upgraded first and the active node is handled later. With PostgreSQL, the database must remain available for the lock and data. Confirm the exact sequence in the release notes and the OpenBao high availability documentation, and rehearse it. Single-node or unhealthy clusters usually need a planned maintenance window.
How does OpenBao support work without a vendor subscription?
Without a vendor subscription, support comes from the open-source project and your own team. The project's documentation, release notes and GitHub repository publish version information, security patches and the history of known issues, so check them before every upgrade. Your team owns on-call response, triage and the decision to apply each patch. If you want outside help, DeployOpen offers ongoing support, upgrades and continuous testing as retainers, and the scope and response expectations are agreed in writing.
Is DeployOpen affiliated with the OpenBao project?
No. DeployOpen is a Chainscore Labs company that plans, implements, hardens, upgrades and supports self-hosted open-source platforms in infrastructure you control. It is not an official partner, reseller or certified provider of the OpenBao project, the Open Source Security Foundation or the Linux Foundation. OpenBao is an MPL-2.0 community project and a Sandbox project of OpenSSF. Use the project's own documentation and releases as the authority on version facts, and ask any provider to show the basis for claims about project status.
How DeployOpen delivers upgrades and support
DeployOpen plans, implements, tests, documents and supports self-hosted open-source platforms inside your own infrastructure, including OpenBao upgrades and ongoing support. Engagements are fixed-scope, with the scope, deliverables and timelines agreed in writing before work starts.
How we scope
- Confirm your current OpenBao version, minor release line and the storage backend each cluster uses.
- Record whether clusters are Raft or PostgreSQL, and whether any were migrated from Vault.
- Agree in writing which releases, security patches and environments the upgrade work covers.
How we build
- Plan the rolling upgrade order across nodes so the active node and standbys are handled in a defined sequence.
- Check configuration before each change, including removal of disable_mlock where it still appears.
- Test upgrades in a non-production environment that mirrors your cluster before any production work.
How we hand over
- Deliver runbooks for upgrades, rollback steps and post-upgrade verification checks for your team.
- Document the versions, configuration changes and backup state recorded at each upgrade.
- Walk your operators through the procedures so your team can repeat them on later releases.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer, scoped in writing.
- Agree which minor release lines and security patch windows the retainer covers.
- Review each new OpenBao release against your configuration and schedule upgrades with your team.
