HashiCorp Vault & OpenBao
Last reviewed by Tyler Eastridge
AceMQ plans and runs HashiCorp Vault upgrades and Vault to OpenBao migrations, and supports and operates OpenBao around the clock with a 15-minute emergency response. OpenBao is the Linux Foundation fork of Vault under the MPL 2.0 licence, and its own migration guide covers only community Vault 1.14.1, so most estates need a rehearsal on a restored copy before anything moves. AceMQ engineers lead each engagement with partner secrets-management specialists, supply no builds and give no licensing or legal advice.
A senior engineer, not an SDR. No sales sequence attached.
Without a dedicated secrets platform teamFor production incident cover, see AceMQ OpenBao 24/7 support.
Customers
Partners
The Problem
Eight problems that platform and security teams bring to AceMQ, from a Vault several versions behind to a Raft cluster that has never been through a leader failure. Most of them surface during an upgrade or a migration rehearsal, so the inventory looks for them first.
Vault sits several versions behind and nobody has read the upgrade notes against the mounts and policies in use
The licence change of August 2023 and IBM's acquisition put "stay on Vault or move to OpenBao" on the agenda, and nobody has the technical answer
Secrets engines, auth methods and plugins have never been inventoried, and an unsupported plugin would be silently skipped after a move
Unseal depends on a few people holding key shards, or on a cloud key service whose outage nobody has tested
The Raft cluster has never lost its leader on purpose, and no snapshot has been restored into a spare cluster
An audit device fills its disk and Vault stops serving requests
Applications read secrets on the start-up path with no cache and no retry, so a short Vault outage becomes an application outage
Enterprise features such as replication or namespaces are in use with no plan for what replaces them if the platform changes
A good fit if you run Vault or OpenBao in production for several teams, are weighing a move between them, or want a rehearsed upgrade plan and a written view of Raft, seal and recovery before the next window.
Not a fit for small teams with non-critical workloads. AceMQ is not a budget consultancy: we work with enterprises running business-critical and compliance-heavy OpenBao.
How it breaks, and the fix
A Vault or OpenBao node that restarts is sealed until it gets its root key, through key shards or an auto-unseal service. In a three-node Raft cluster, two sealed nodes mean the leader has no quorum, and every application that reads a secret fails.
Three Raft nodes, two restarted sealed
Applications, one cluster, three nodes
Three nodes are unsealed and voting, one is leader, and applications read secrets without noticing the cluster exists.
An upgrade restarts nodes 1 and 2 at once. They come back sealed, the shard holders are not reachable or the key service is down, the leader has no quorum, and every application that reads a secret on start-up fails.
Nodes are upgraded one by one. Each is unsealed and confirmed as a voter before the next is touched, the unseal path was tested beforehand, and the leader is stepped down last.
A Raft cluster needs a majority of its voters, so a three-node cluster survives losing one node and not two. HashiCorp's upgrade page tells you to make sure enough unseal-shard holders are available after the restart and to unseal Vault after the upgrade. OpenBao's guide describes the safe order: followers one at a time, each joined, unsealed and confirmed as a voter before the next, then a leader step-down. Auto-unseal removes the shard holders and adds a dependency on a key service, which is why the Raft, seal and recovery review tests the path you actually have.
Our Services
AceMQ runs five service lines around Vault and OpenBao: Vault upgrade planning, Vault to OpenBao migration, a Raft, seal and recovery review, a policy and secrets engine review, and OpenBao support and managed operation. Support and managed operation cover OpenBao only.
Version-to-version upgrade plans for Vault Community and Enterprise, rehearsed on a restored snapshot. Your team runs Vault with HashiCorp's own releases.
An assessment of whether and how your Vault moves to OpenBao, then a rehearsed migration if the answer is yes.
Whether your cluster survives the failures that actually happen: a lost leader, a restart while sealed, an unreachable key service.
A written view of who can read what, how long tokens and leases live, and which applications would fail if Vault paused.
24/7 support for OpenBao, or AceMQ operating it for you in your account or on AceMQ's infrastructure, quoted per estate.
Senior engineers on your account, a 15-minute emergency response, no ticket routing and no junior triage.
24/7 Support
AceMQ OpenBao support gives you an AceMQ engineer and a 15-minute first response when OpenBao is sealed, has lost its leader or is failing requests in production, 24/7. Lower severities get 1-hour, 4-hour and next-day responses. Fixes come from OpenBao's own releases: AceMQ produces no builds. AceMQ does not sell a Vault support contract.
P1 escalation path
A replay of one P1, from the first page to the written root-cause analysis
15-minute P1 response, 24/7.
A response time, not a resolution time.
P1 opened, on-call engineer paged
Phone, email or Slack reaches the on-call senior engineer directly, whether the incident is in RabbitMQ, Kafka, Redis, PostgreSQL or Kubernetes. No web form, no tier-1 queue.
Senior engineer on your bridge
A senior engineer who already knows your environment joins a live bridge, so nobody has to re-explain your topology.
Specialists across the stack join
When an incident crosses components, the engineers who know each one join. For RabbitMQ, the path runs to the core team.
Written root-cause analysis
Root cause, the fix applied and the prevention steps, delivered after every P1.
Beyond SLAs — the model behind senior-only, zero-cold-start expert access.
Tickets go to senior engineers briefed on your environment, not an anonymous queue. The proposal states who does the work.
Any ticket can be escalated to a live session with an engineer through calendar booking. No gatekeeping and no approval step.
Scheduled health checks on your deployment and alerts on risks in the versions you run, so problems surface before they reach production.
Release notes and lifecycle dates read against your environment, with an upgrade plan that fits your change windows.
How It Works
An AceMQ engagement runs in four stages: a scoping call with a quote within 1 hour, a written inventory and compatibility review, a rehearsal on a restored snapshot, then cut-over and review. Each stage ends in writing.
Quote within 1 hour
Version, storage and seal decide whether OpenBao's documented path applies at all. An AceMQ engineer asks for Vault or OpenBao, edition and version, storage backend, seal type, auth methods, secrets engines, plugins and who is on call. A quote request is answered within 1 hour.
Scoped per estate
A fixed-scope, read-only review: every mount and auth method, external plugins, policies, audit devices, token use and the HA topology. Findings are written and ranked by risk, with each item marked move, rebuild or retire.
Scoped per estate
A Raft snapshot restored into an isolated cluster, then upgraded or migrated there while real application calls are replayed against it. The plan, the order of nodes and the rollback are written from what the rehearsal showed.
Scoped per estate
Windows run with your team, one node at a time with the leader last, followed by a written review. For OpenBao you can then keep AceMQ on call, or hand AceMQ the operation at a managed tier.
A senior engineer, not an SDR. No sales sequence attached.
Vault to OpenBao
OpenBao's own guide describes an in-place path for community Vault 1.14.1 on Raft storage with Shamir unseal. Anything else, including today's Vault releases, Enterprise and auto-unseal, is outside what the guide tested, so AceMQ's version of the path adds an inventory first and a rehearsal on a restored copy.
Step 1
List secrets engines and auth methods, and note every external plugin. The guide warns that mounts whose plugin is missing are silently skipped and return "No value found" after the move, so the list decides what can move at all.
Step 2
Take a Raft snapshot, restore it into an isolated cluster, and use that copy for every test. The guide says to back up first and to give OpenBao a separate storage path, which also makes rollback easier.
Step 3
Point a test copy of your applications at the restored cluster. Check policies, dynamic credentials, audit logging and clients that assume Vault's token format, because new tokens use a different prefix while existing ones stay valid until their TTLs expire.
Step 4
Stop each follower in turn, start OpenBao, join the cluster, unseal it and wait until it is a voter before touching the next, as the guide describes. Remove disable_mlock from the configuration, since OpenBao no longer uses it.
Step 5
Step the leader down, confirm a new leader was elected, then upgrade the former leader the same way. Keep the old storage and Vault binaries through the rollback window before retiring them.
Typical engagements
How an AceMQ Vault to OpenBao assessment typically runs: the environment, what AceMQ inventories and rehearses, and what the engagement delivers.
Security Platform Team
A typical engagement for a security platform team that runs HashiCorp Vault and wants to know whether OpenBao is a safe move: every mount, auth method and plugin inventoried, a snapshot restored and migrated in isolation, and a written verdict with a cut-over plan.
Kubernetes
Mid-Sized Distribution Company
A typical engagement for a company that wants to leave an Oracle Java SE subscription or avoid one: inventory every Java runtime, compare OpenJDK distributions against the estate, and write the migration plan.
JavaOpenJDK
DockerKubernetesSaaS Platform Team
A typical engagement for Java services that restart with exit code 137 after a base image brings a newer JDK: the heap is not full, no OutOfMemoryError appears, and the memory that matters lives outside the heap.
JavaKubernetesDocker
PrometheusSolutions
How an engagement can start and what it grows into, from a written assessment to AceMQ operating OpenBao for you.
Projects
Fixed-scope work led by a senior engineer: architecture and new builds, a health check of what you run today, or a migration with a reversible cutover.
Support and managed services
Four tiers of ongoing cover once you are live. Each tier hands more of the day-to-day work to AceMQ, from a 15-minute emergency SLA to AceMQ hosting and running OpenBao for you.
Compare the four OpenBao support tiersSide by side
All three keep secrets out of code and config files, and they differ in licence, who ships fixes and what a move costs. AceMQ does the Vault upgrade and migration work, and supports and operates OpenBao. It sells none of the three products and gives no licensing advice. Each row below answers one question.
| Question | Stay on HashiCorp Vault | Move to OpenBao | Cloud secrets manager |
|---|---|---|---|
| Who owns it, under what licence? | HashiCorp, owned by IBM since 27 February 2025. New releases have used the Business Source License 1.1 since the change announced on 10 August 2023. Read the use grant with your counsel. | The OpenBao project, in the Linux Foundation's OpenSSF, under MPL 2.0. It describes itself as a sandbox project. | The cloud provider, under its service terms and pricing. |
| Where do fixes come from? | HashiCorp releases (Vault 2.2.1 on 22 October 2026). Vault Enterprise follows IBM's support cycle; read IBM's addendum for the dates. | OpenBao releases (v2.7.2 on 26 October 2026). | The provider, with no cluster for you to upgrade. |
| What is the path from today's Vault? | A version upgrade, planned against the release notes and rehearsed on a restored snapshot. | OpenBao's guide covers community Vault 1.14.1 on Raft with Shamir unseal. Anything else is rehearsed on a restored snapshot first. | Applications change, not only the server: SDK calls, IAM policy and rotation all move. |
| What needs checking? | External plugins, Enterprise features in use, the auto-unseal dependency and the audit device. | OpenBao ships few built-in plugins, mounts with a missing plugin are silently skipped, Enterprise features are outside the guide, and new tokens use a different prefix. | Dynamic credentials for databases and brokers, and use across several clouds or on premises. |
| When does it fit? | You use Enterprise features, or you value a vendor contract and are content with its terms. | An open-source licence matters to you, and you use only what OpenBao provides. | One cloud, mostly static secrets, and no wish to run a cluster. |
| What does AceMQ do? | Upgrade planning, reviews and migration work. No Vault support contract. | Migration, 24/7 support and managed operation. | Comparison and migration planning only. AceMQ does not run cloud secrets managers. |
To see how an assessment runs, read a typical Vault to OpenBao assessment. For the support windows of the other open-source tools in your stack, see open-source support windows compared.
One partner, not five
OpenBao rarely fails in isolation. AceMQ covers the full surrounding infrastructure — so one team owns the whole path instead of pointing at each other.
Guides, articles and comparisons
The AceMQ services around a secrets platform: Kubernetes, PostgreSQL, RabbitMQ and Kafka, all of which read credentials from it, and the compliance work it supports.
FAQs
Five answers from AceMQ: what OpenBao is, whether an in-place migration is possible, how to upgrade Vault safely, what AceMQ does and does not sell, and how to choose between Vault, OpenBao and a cloud secrets manager.
Still have questions about OpenBao? Email an Expert
OpenBao is a fork of Vault that lives in the Linux Foundation's OpenSSF and is licensed under MPL 2.0. HashiCorp announced on 10 August 2023 that future Vault releases would move from MPL 2.0 to the Business Source License 1.1, and IBM completed its acquisition of HashiCorp on 27 February 2025. OpenBao describes itself as a sandbox project. AceMQ gives no licensing or legal advice: read the licence terms with your counsel.
Only in the case the guide tested. OpenBao's migration guide says it was tested with community Vault 1.14.1 on Raft storage and Shamir unseal, that newer Vault versions are unsupported, that Enterprise was not tested, that external plugins are not assumed, and that auto-unseal is not covered. For anything else AceMQ rehearses the move on a restored snapshot and writes the plan from the result.
HashiCorp's upgrade page warns that Vault makes no backward-compatibility guarantees for its data store, so the sequence is: back up with a snapshot, read the release and upgrade notes for every version in between, restore the snapshot into an isolated instance, upgrade that first, verify, and make sure enough unseal-shard holders are available after the restart. AceMQ plans and rehearses that sequence and sits with your team through the window.
No. AceMQ offers upgrade planning, assessments and migration work for Vault, and 24/7 support and managed operation for OpenBao. It does not sell a Vault support contract. What the Vault licence allows for your use is a question for your counsel, and AceMQ gives no licensing advice.
It depends on the features you use, your licence position and how many clouds you run in. A cloud secrets manager suits one cloud and mostly static secrets. Vault suits teams that use Enterprise features or value a vendor contract. OpenBao suits teams that want an open-source licence and use only what it provides. The comparison table on this page sets out the differences, and the assessment tells you which fits your estate.
Yes. AceMQ works on OpenBao in two ways: ad hoc engagements for a defined piece of work, such as a health check, an upgrade or an incident, or an annual contract that covers 24/7 support and proactive reviews. Many teams start ad hoc and move to an annual contract once the first engagement is done.
Every AceMQ proposal is tailored to your requirements: your OpenBao environment, the SLA you need, the hours of cover and the scope of work. Most contracts run $24,000–72,000 a year, depending on the SLA, the scope and how OpenBao is deployed, with aggressive discounts when several technologies share one contract. Request a quote and AceMQ replies within 1 hour.
Let's talk
A senior AceMQ engineer reviews your Vault or OpenBao estate, tells you what to do first, and quotes it. Quote requests are answered within 1 hour.
Production incident right now?Email an OpenBao Architect
Send us a message and we'll follow up within 1 hour — or book a free 30-min consultation directly.
305-204-2607info@acemq.comPrefer to talk now? Call us directly or use the consultation tab to find a time that works.
