OpenBao cost of ownership and editions

What OpenBao costs to run and who pays for it

The OpenBao repository is licensed under MPL-2.0, and this topic has no paid edition. Nothing in the license requires a per-node, per-secret or per-user fee, so the cost of running OpenBao is what your organization spends on the infrastructure it runs on, the key custody needed to unseal it, the one-time implementation, and the staff who operate it afterward. A contract cannot remove a license cost here because no license cost exists to remove. Confirm the current license text in the repository before you rely on it in a procurement file.

The recurring costs are the ones to plan for. They include compute and storage for the active and standby nodes, the storage backend (integrated Raft storage or PostgreSQL, as documented), backups and monitoring, and the people who handle upgrades, certificate rotation, auth method changes and on-call response. The one-time costs are the design and build: storage backend choice, unseal approach, auth methods, secrets engines and application onboarding. Ask any partner to split its quote into these groups so you can see which items recur every year.

Some events reliably trigger a cost review: a renewal of an existing HashiCorp Vault agreement, the decision to add a new secrets platform, an audit finding about secrets handling or key custody, or a move of workloads to Kubernetes that changes how identities and certificates are issued. Each of these raises the question of who will own the platform after launch. Write that owner down before you compare options, because an unowned cluster usually costs more later than a funded one.

Many teams split the work. An internal platform team keeps day-to-day operation and owns policies and onboarding, while an outside partner handles the build, hardening and documentation under a written scope. The split should be explicit: who performs each upgrade, who holds unseal material, who answers when a node fails, and who reviews audit logs. Ask for a responsibility matrix as part of any quote, and confirm which tasks your team can perform without the partner after handover.

Recurring and one-time cost components

This table lists each cost component of running OpenBao, whether it is one-time or recurring, who usually pays, and the question to put to a vendor or partner before committing to a budget.

Cost component	One-time or recurring	Who pays	Question to ask
Compute and storage for nodes	Recurring	Client cloud bill or hardware budget	What node count, instance sizes and disk classes does the plan assume for each environment, and which of them run in production?
PostgreSQL or Raft storage layer	Recurring	Client cloud bill, or the client database team if PostgreSQL is shared	Which backend is recommended for our team, and who operates it after handover: our database team, our platform team or a partner retainer?
Load balancing and DNS	Recurring	Client network or cloud budget	Which health check and failover behavior does the load balancer need for active and standby nodes, and who owns the DNS records?
Backup storage and restore testing	Recurring storage, one-time test effort	Client cloud bill for storage, client team or partner for restore tests	How often will a full restore be tested, in which environment, and what evidence will be delivered after each test?
Unseal key custody (operator-held shares, cloud or on-premises key service, or HSM)	One-time setup, recurring service fees if a cloud key service is used	Client cloud or security budget, or existing HSM budget	Which custody model fits our policy, what does the key service cost per month in our account, and who holds the recovery material?
Monitoring and audit log retention	Recurring	Client observability budget or log platform licence	Which audit devices and metrics will be shipped to our platform, how long must they be retained, and who reviews alerts?
Upgrade and security patch effort	Recurring	Client team time or partner retainer	How are OpenBao minor releases and security patches tested before production, and what is included in the retainer versus a separately scoped upgrade?
On-call staff time	Recurring	Client team payroll	Who carries the pager for seal events and failed leader elections, and what runbook and escalation path does the partner provide?

What the cost analysis and build include

A cost-of-ownership engagement and the OpenBao build that follows it produce written artifacts your team keeps. Each deliverable below is scoped in writing before work starts, so you can see what you receive before you commit.

Secrets sprawl baseline

A written inventory of where secrets live today, such as configuration files, CI variables, password managers and static database credentials, plus the systems that read them. It lists the applications and teams that depend on each secret, so you can see which migrations carry the most coordination effort before any cost is estimated.

Storage backend options comparison

A side-by-side comparison of integrated storage with Raft, PostgreSQL and the other documented backends, covering HA behavior, operational burden and the skills each one needs. Check whether your organization already runs PostgreSQL with backup and failover practices, because the OpenBao storage documentation describes PostgreSQL as easier to operate safely than Raft.

Recurring cost model

A spreadsheet-style model of recurring costs: compute for the cluster, storage, backups, load balancing, monitoring, and the staff time needed to patch and respond. Every assumption, such as node count, region count and backup retention, is written down so you can change one input and see the effect on the total.

Unseal and key custody decisions

A record of how the cluster will be unsealed and where the unseal or recovery keys will be held, with the trade-offs of each option. Because OpenBao cannot serve secrets while sealed, this decision drives both your outage exposure and the on-call procedure, so it is documented separately from the infrastructure costs.

Staffing and skills list

A list of the roles and skills your team must have to run OpenBao after handover, including Linux operations, TLS, backup and restore testing, identity integration and on-call coverage. Each skill is tied to a task in the model, so you can compare it with the people you already employ or plan to hire.

Written model handover

A signed-off handover package containing the model, its assumptions, the decision records and the update procedure, so your finance and platform leads can recalculate costs as versions change. Ask for the handover to include how the model should be revised after OpenBao upgrades and when your storage or unseal choices change.

What drives cost and duration

Each row names one factor that moves OpenBao implementation and running cost, why it moves it, and what keeps it down, so you can compare your environment against the drivers before requesting a written scope.

Driver	Why it changes cost or effort	How to keep it down
Applications and secrets consumers	Each consuming application needs its own auth method, policy, secret paths and onboarding test, so effort grows with the number of teams and workloads.	Group consumers by platform and reuse one onboarding pattern. Confirm the count and owners before scoping.
Environments and clusters	Every environment (development, staging, production, disaster recovery) needs its own cluster, unseal material, backups and configuration, multiplying build and upkeep.	Use one reviewed configuration template with per-environment variables. Limit production clusters to what the risk model requires.
Storage backend choice	Integrated storage (Raft) keeps the cluster self-contained, while the OpenBao storage docs describe PostgreSQL as easier to operate safely, shifting effort between OpenBao and database operations.	Choose the backend your team already operates well. Ask the partner to document the recovery procedure for the chosen backend.
HA and cross-site needs	Active and standby nodes, leader failover tests, and cross-site replication add nodes, network paths and failover drills, each of which must be tested and monitored.	Start with the availability target your services actually need. Confirm whether standby read scaling is needed, since the HA docs describe it for Raft and PostgreSQL.
Unseal approach	Manual unseal means people must hold key shares and be available after restarts. Auto-unseal relies on an external key management service that you must provision, secure and monitor.	Decide who holds key custody before build starts. Confirm which key management service your organization already licenses or operates.
Auth method count	AppRole for servers, Userpass for developer machines, JWT/OIDC, Kubernetes, LDAP, Kerberos, TLS certificates and login MFA each need configuration, group mapping and testing.	Standardize on a short list of methods per user type. Map groups to policies once and reuse them across clusters.
Namespaces for multi-tenant isolation	Namespaces let several teams share one cluster, but each tenant needs its own policies, administrators and audit review, which adds design and governance work.	Confirm tenant boundaries early. Share a cluster only where the trust model allows it, and keep the namespace structure simple.
Dynamic secrets for databases and Kubernetes	Dynamic credentials require connection setup, role templates, lease tuning and application changes to request and renew credentials, so application work often dominates effort.	Start with one high-value database or cluster. Reuse role templates and confirm that application teams can handle lease renewal.
Compliance evidence needs	Assessors may expect documented access reviews, audit device logs, change records and key custody procedures. Producing and retaining that evidence is ongoing work.	Agree the evidence list with your assessor before build. Automate log export and keep procedures in version control. DeployOpen prepares evidence but auditors issue the opinion.
Existing Vault cluster as the source	Migrating from Vault adds version checks, possible rekey work for older clusters, removal of disable_mlock, and cutover planning. The migration guide was tested only against Vault 1.14.1 community edition.	Inventory the Vault version, edition and configuration first. Confirm whether your edition and version are covered by the documented path before you commit to a migration scope.

Phases and the output of each

The sequence moves from understanding current secrets use to a written cost model, an agreed scope, a working build and a first operating cycle that your team can run.

Discover current secrets use
DeployOpen interviews platform, security and application owners and inventories where secrets live today, including config files, CI variables, databases and certificates. The output is a written inventory of secret types, consumers, rotation practices and the people who would run OpenBao, which you confirm before any options are priced.
Design storage, unseal and auth options
DeployOpen compares storage backends (integrated storage on Raft or PostgreSQL), unseal approaches and the auth methods your workloads and people need. The output is two or three candidate architectures, each with the infrastructure, key custody and operational responsibilities it implies, so you can see where cost moves between options.
Write the cost model and assumptions
DeployOpen builds a cost model listing each component: infrastructure, storage, key management for unsealing, implementation effort, migration if applicable, and the internal staff time needed to operate it. Every assumption is stated, such as node count, backup retention and expected secret volume, and the output is a document you can challenge line by line.
Agree the decision and written scope
You choose an architecture and approve the cost model, and DeployOpen turns the chosen option into a written scope with deliverables, exclusions, acceptance criteria and a timeline that follows the agreed scope. The output is a signed scope document that governs the build and any change requests.
Build and test the platform
DeployOpen deploys the chosen architecture in your environment, configures auth methods and initial policies, and tests unseal, failover and backup restore against the acceptance criteria. The output is a running cluster with test results and configuration recorded in your own repositories.
Hand over and run the first operating cycle
DeployOpen delivers runbooks, access records and training for the staff who will operate OpenBao, then supports one full operating cycle, including a planned upgrade or restore exercise if included in scope. The output is a handover record showing that your team has performed the routine tasks and knows where each recurring cost sits.

What usually goes wrong with OpenBao costs

The MPL-2.0 license removes license fees, but the recurring costs sit in custody, staffing, storage and migration. These are the surprises that most often appear after go-live, with the step that prevents each one.

Treating the license as the whole cost

OpenBao's MPL-2.0 license carries no fee, but the budget still needs infrastructure, unseal key custody, implementation and staff time. Before approval, ask for a cost model that lists each of these as a separate line, with who pays for each and whether it recurs every year.

Underestimating on-call for a secrets service

Applications that fetch secrets cannot run when OpenBao is unavailable, so the service needs an on-call rota, alert routing and a tested runbook for seal and failover events. Confirm who covers nights and weekends, and whether that duty is funded by your team or a retained partner.

Choosing storage without an operating model

Integrated storage (Raft) and PostgreSQL are both officially supported HA backends, but each needs its own backup, upgrade and recovery procedure. Decide who operates the chosen backend before selecting it, because the operating effort follows that choice for the life of the cluster.

Holding unseal keys with too few people

If unseal keys or recovery material sit with one or two individuals, a single absence can block recovery during an incident. Plan a key-holder roster with a defined threshold, documented custody and a regular drill, and record who holds each share.

Unplanned work for older Vault clusters

Migrating from Vault is documented as in-place replacement, but clusters bootstrapped before Vault 1.3 may need a rekey first, and disable_mlock must be removed from configuration once you move to OpenBao 2.0.0 or later. Inventory your Vault version, bootstrap history and configuration before quoting a migration.

Assuming Enterprise features exist in OpenBao

The migration guide was tested against Vault 1.14.1 community edition, not Vault Enterprise, and OpenBao is a community project with no paid edition. Before budgeting, list every feature your current setup relies on, confirm it is documented in OpenBao, and price any gap as custom engineering or a redesign.

How the cost picture changes by starting point

Your license cost is already zero, so the cost change comes from the work around the replacement itself. OpenBao's documented in-place path covers this starting point, but the guide was tested only against Vault 1.14.1 community edition, so your exact patch level needs confirmation.

Change window labor: staff time for the maintenance window, rollback rehearsal and post-change checks on every node.
Rekey work: clusters bootstrapped before Vault 1.3 may need a rekey, which adds key custody and ceremony time.
Configuration review: removing the disable_mlock setting and checking other configuration items before the change.
Reused infrastructure: existing nodes, storage and key management services carry over, so hardware spend is usually limited.
Ask in the quote: whether the scope includes rehearsal in a non-production copy and who owns the rollback decision.

What the client needs to provide

An OpenBao cost model is only as accurate as the inputs behind it. Before a written scope can be agreed, the client should gather an inventory of every application and secrets consumer that will read from OpenBao, including people using the CLI or UI, CI pipelines, Kubernetes workloads and database-backed services. Each consumer adds auth method configuration, policies and onboarding work, so a count of 40 consumers with clear owners is very different from a list of "about a dozen, we think."

Name the current secrets tooling and its exact version. If the estimate covers a move from HashiCorp Vault, confirm whether the cluster is community or Enterprise edition, which Vault version it runs and whether it was bootstrapped before Vault 1.3, since the migration guide flags a rekey in that case. Also list every configuration setting that would need to change, including any disable_mlock entry. Where the current tool is a cloud key service, a shell script or a spreadsheet, say so, because the migration path differs.

Decide where OpenBao will run and who controls the accounts or data centers hosting it. Confirm the storage backend preference (integrated storage with Raft or PostgreSQL) and who will operate that database if PostgreSQL is chosen. Decide key custody for unsealing: who holds unseal key shares, how many are required to unseal, where they are stored, and whether an external key service will automate unsealing. Each choice changes build effort and the operating duties that recur after handover.

Name the people who will hold unseal key shares and who is on call for secrets outages, and confirm that the rotation can be staffed for the hours the business needs. Also identify the compliance frameworks and audit requirements that apply, including how long audit logs and evidence must be kept and where they must be stored. Finally, arrange access to a non-production environment with network paths matching production. Unclear answers on any of these points widen the estimate, and the written scope follows from the answers.

Frequently asked questions about OpenBao costs

Does OpenBao have a license fee or a paid edition?

No. OpenBao is licensed under the Mozilla Public License 2.0 (MPL-2.0), and no paid edition is offered, so the software itself carries no license fee. Your costs are the infrastructure it runs on, the key management used to unseal it, storage, backups, monitoring, and the people who plan, build and operate it. Those costs recur and are what you should model. Confirm the license terms and the licenses of any third-party components in your build with your legal and procurement teams before you rely on this.

What does it cost to run OpenBao each year?

The running cost is the sum of components you already pay for or will add: compute for every node in your high availability cluster, storage and backups, network and load balancing, monitoring, and the unseal and key custody approach you choose. Staff time for upgrades, credential rotation, incident response and application onboarding also recurs. Costs rise with cluster count, number of environments, audit log volume and the number of applications onboarded. Ask your cloud or data center team for a bill of materials and model it at your own rates. No annual figure is given here because it depends on your environment.

Can an internal team run OpenBao without an outside partner?

Often yes, if the team has experience running stateful, security-critical services and can staff on-call coverage. Running OpenBao well means owning the unseal and key custody design, the storage backend (integrated storage with Raft or PostgreSQL), failover testing, backup and restore, upgrades across minor release lines, policy design and auth method integration. Assess the skills gap honestly: name who holds each task, how many people can cover it, and who responds to an incident at night. An outside partner can take a defined part of that work under a written scope.

How long does an OpenBao cost review and build take?

The duration depends on scope: the number of clusters, the storage backend, the auth methods and secrets engines, whether you migrate from an existing Vault deployment, and how many applications need onboarding. DeployOpen works from a fixed scope agreed in writing before work starts, so the schedule follows from the deliverables in that scope. No fixed duration is given here. Ask for a written timeline with milestones, and ask which dependencies, such as change windows and access approvals, sit on the critical path.

What does an OpenBao engagement need from our staff?

Expect to name owners for identity, networking, cloud or data center access and security, and to give the project team access to the environments where OpenBao will run. You will also need decisions on unseal and key custody, the storage backend, audit log retention and which applications onboard first. Time from subject-matter experts for reviews and sign-off recurs throughout the schedule and affects the timeline. Ask the partner to list these inputs in the written scope so each one has an owner and a date.

Is a vendor support subscription required to run OpenBao?

No vendor subscription is documented for OpenBao, so none is required to run it. Support is a separate decision: your team can operate it from the project's published documentation, or contract outside help for upgrades, incident response and patching. The upgrades and support page describes what that support looks like in practice. Ask any provider to state in writing which upgrade, patch and incident tasks are included and how they are priced, so you can compare them fairly.

How does the OpenBao cost compare with our Vault contract?

Compare the modeled internal cost with the terms of your current contract. Ask your HashiCorp Vault vendor for the contract terms in writing, including license scope, support level, term, renewal and any price-change clauses, then set those against your modeled OpenBao costs for infrastructure, staff and external help. Include migration effort if you plan to move from Vault. The migration guide documents an in-place path tested only against Vault 1.14.1 community edition, so newer or Enterprise clusters need separate planning.

How DeployOpen scopes and delivers OpenBao cost work

DeployOpen plans, implements, hardens, documents and supports OpenBao inside your own infrastructure, so the cost model is written against your storage, unseal approach, identity and on-call arrangements rather than a generic estimate. Engagements are fixed-scope, with ongoing support available as a retainer.

How we scope

The written scope lists the nodes, storage backend, unseal method and environments the cost estimate is built on.
It separates one-time implementation effort from recurring infrastructure, key management and operations items.
It names the auth methods, secrets engines and application onboarding volume that drive most of the effort.
It records who on your side owns key custody, on-call rotation and approval of upgrade windows.

How we build

We deploy OpenBao in the cloud accounts, data centers or air-gapped networks you control, sized to the agreed scope.
We configure the chosen storage backend and unseal approach, then test failover and restore before onboarding applications.
We validate the auth methods and policies agreed in scope, using the documented methods for people and workloads.
We document the cost drivers we measured during build so you can compare them against the original quote.

How we hand over

You receive architecture notes, configuration records and runbooks covering sizing, unseal, backup and upgrade steps.
Handover includes a summary of recurring costs your team will carry, including infrastructure and staff time for on-call.
We walk your operators through restore testing and the procedure for planned upgrades between OpenBao release lines.
Acceptance is tied to the deliverables listed in the written scope, so open items are visible before the engagement closes.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer, priced from the written scope.
A retainer can cover patch tracking, upgrade planning and periodic restore tests, which otherwise fall to your team.
Support boundaries, response expectations and any SLA terms are confirmed in writing before the retainer starts.
We recommend confirming current OpenBao release and support status with the project before setting your upgrade budget.