Secret Manager cost vs self-hosted OpenBao

Google Cloud Secret Manager cost versus self-hosted OpenBao: the short answer

If your renewal, GCP cost review or data residency requirement has put Secret Manager spending in front of you, the short answer is that Secret Manager's bill grows with the number of active secret versions per replica location, the access operations your workloads perform, and any rotation notifications you have configured. OpenBao carries no license fee, but you take on the servers, storage, setup and ongoing operations that Google otherwise runs for you. The comparison is therefore about whether your own infrastructure and staff time cost less than Google's metered charges at your actual volumes, not about a sticker price on either side. Google's current rates must come from its published Secret Manager pricing page, because no figures for those rates are part of this analysis. Pull the latest per-version, per-operation and notification charges, then multiply them by your real counts: how many secrets you hold, how many versions each keeps, how many replica locations you have configured, and how many reads your fleet makes each month. Replication settings matter here, because each additional replica location can multiply the active versions you pay for, so confirm your current replication policy before you model anything.

On the self-hosted side, ask what it would take to run OpenBao in your environment: compute for a highly available cluster, storage for the chosen backend, backup and upgrade procedures, monitoring, and the people who own them. Your own staff time, cloud resources and any external implementation or support fees are real costs even though the software itself is free under MPL 2.0. In practice, self-hosting tends to favor organizations with a large secret footprint, a standing platform team, or hard residency rules that already require infrastructure they control. Smaller estates with few secrets and limited operations capacity often find the managed service cheaper once staff time is counted. Run both models against your own numbers before deciding.

Which cost components sit on each side and which recur

This table lists each cost component on the Secret Manager bill and on the self-hosted OpenBao side, with who is paid and whether the cost is one-time or recurring. Read the Secret Manager rows first, since replica location and access volume drive that bill, then compare them with the infrastructure and staffing rows on the OpenBao side. Exact Google Cloud rates are not included here, so confirm them on Google's published pricing for your regions.

Cost component	Google Cloud Secret Manager	Self-hosted OpenBao
Secret versions stored	Billed per active secret version in each replica location, so extra regions multiply the charge. Paid to Google. Recurring.	No per-version fee. Storage cost is the backend volume you provision. Recurring infrastructure cost only.
Access operations	Billed per access operation, so polling and frequent reads raise the bill. Paid to Google. Recurring.	No per-request fee. Load depends on your servers and network. Recurring infrastructure cost.
Rotation notifications	Billed per rotation notification, and Secret Manager sends Pub/Sub events only. Rotation code and its hosting are your cost. Recurring.	No notification fee. Dynamic secrets and rotation run inside OpenBao, so you pay for compute and the engineering to configure them. Recurring operating effort.
Replication and CMEK or networking charges	Confirm whether CMEK keys, egress or private connectivity apply to your setup and check Google's pricing for each. Paid to Google. Recurring.	Replaced by your own KMS, network and load balancer costs, which you already pay for or must buy. Recurring.
License	Included in the Google Cloud bill. No separate license line.	OpenBao is MPL 2.0 licensed with no license fee. Confirm any support or subscription terms with a provider you choose. Zero to recurring, depending on support.
Servers and storage	Not applicable. Google operates the infrastructure.	Paid to your cloud or data center provider for HA nodes, storage and backups. Recurring. Sized by node count and data volume.
Setup and migration	Export and IAM mapping effort is paid to your staff or a partner. One-time.	Paid to your staff or implementation partner for design, install (the Helm chart is the recommended Kubernetes path), auth configuration and migration. One-time, with quote-based fees.
Support, upgrades and internal skills	Included in the Google Cloud service and support plan. Recurring.	Paid to your staff for upgrades, backups, HA monitoring and on-call, or to a retainer provider. Recurring. Confirm skill coverage before cutover.

How replication settings change the Secret Manager bill

The replication policy on each Secret Manager secret is one of the settings that most directly shapes the bill, because active secret version charges are counted per replica location. A secret set to automatic replication is stored across Google-chosen locations, while a user-managed secret pins replicas to locations you name. Each additional replica location adds to the storage charge for every active version of that secret, so a fleet of many secrets with several versions each can grow faster than the secret count suggests. Before modeling anything, list every secret, its replication type, its replica locations and how many versions stay active, because those four values drive the line item more than the secret count does.

The same location choice also decides where secret material sits, which matters for data residency and for availability design. A user-managed policy confines replicas to the regions you select, which may satisfy a residency requirement that automatic replication does not address. Spreading replicas across more regions improves resilience but widens the set of jurisdictions holding copies and raises the per-version charge. Ask your compliance lead and cloud architect to agree on an acceptable location list first, then price that list. Under OpenBao, the equivalent decision is where you place the cluster and its storage backend, which your team controls directly and can document as part of the deployment design.

Model the bill with your own replication settings in the Google Cloud console and on Google's Secret Manager pricing page, not with a generic estimate copied from another account. Export the secret inventory, filter by replication type and location, and multiply the active versions in each location by the published rate for the current period. Add access operation counts from Cloud Monitoring for the same window, because reads often outnumber writes. Then compare the result with the fixed cost of OpenBao servers and storage in your environment. Record the assumptions, especially version retention and location list, so the comparison can be rerun when either changes.

What moves the Secret Manager and OpenBao totals most

Secret Manager is billed by what you store and how often workloads read it, while OpenBao is billed by the servers, storage and people you run. The drivers below show which side each factor pushes up and whether its effect is paid once or every month.

Secrets and retained versions

Google bills per active secret version, so the count of secrets multiplied by the versions you keep drives the recurring storage line. Teams that add a new version on every rotation without disabling old ones grow this number quietly. In OpenBao, the same secrets sit in a key/value engine where version count affects storage size and the max_versions setting, not a per-version fee. Check how many versions your rotation process actually creates and how long you keep them.

Access operation volume

Each read of a secret version is an access operation that Google bills, so high-frequency reads from pods, serverless functions and CI pipelines raise the recurring bill directly. Caching in the application and fewer, larger reads reduce it. OpenBao has no per-read fee; its cost is the compute and network capacity needed to serve those reads, which scales with request rate. Pull a month of access logs and count reads per workload before estimating either side.

Replica locations per secret

Secret Manager lets you choose automatic replication across Google regions or user-managed replication to specific locations, and each replica location is billed as its own active version. Adding locations for resilience or data residency multiplies the storage charge for every secret. OpenBao stores data in the clusters you deploy, so extra locations mean extra servers and storage in those regions, plus replication design. Confirm the replica settings in your current configuration with the Google Cloud pricing page.

Availability and HA topology

Secret Manager's availability is included in the per-use price, so you pay nothing extra for resilience. A self-hosted OpenBao cluster needs at least a set of nodes with a supported HA backend, either integrated Raft storage or PostgreSQL, plus load balancing and backups. This is a recurring infrastructure cost that grows with the availability target and the number of regions. Ask your team to size the node count, the storage backend and the failover test schedule as separate line items.

Environments and clusters

Each environment, such as development, staging and production, and each Kubernetes cluster adds secrets and access paths on the Google side and often a separate OpenBao namespace or cluster on the self-hosted side. Consolidating environments into one OpenBao deployment with namespaces lowers infrastructure cost but raises the blast radius of an outage. Treat the number of environments as a design decision and record it before comparing totals.

In-house skills and operating effort

Secret Manager needs little operating time, but teams still spend effort on IAM design, rotation functions and quota monitoring. Running OpenBao adds one-time setup for deployment, auth methods, policies and migration, then recurring work for upgrades, unseal procedures, backups and security patches. A team without Vault or OpenBao experience will pay more in time or in external support, so ask any partner for a fixed-scope written estimate that separates setup from ongoing support.

How OpenBao's storage and HA choices change the self-hosted cost

A single OpenBao server using integrated storage (Raft) is the smallest self-hosted footprint. There is one node to provision, patch and back up, and no standby to keep in sync. The cost is mostly the compute and disk for that node, plus the time your team spends on the snapshot and restore routine. The trade-off is availability: if the one node is down, applications that need secrets at startup or during token renewal cannot reach them until it returns. This shape suits development, test or low-criticality workloads where a short outage is acceptable.

Servers: one virtual machine or pod, with the storage it needs for the Raft data directory.
Database operations: none beyond Raft snapshots, which you schedule and test yourself.
Patching: each upgrade restarts the only node, so secrets are unavailable for that window.
On-call effort: low volume of alerts, but any node failure is a full service outage.
Recovery: restoring from a snapshot is a manual step you must rehearse.

Before choosing this shape, confirm with your application owners how long their workloads can run without fetching secrets.

How to build the comparison with your own numbers

This sequence turns the cost question into a like-for-like model built from your own secret, version and access counts, so both sides are priced against the same workload. The result is a three-year view you can check line by line before you request any quotes.

Export your current secret inventory
The platform or cloud team lists every secret in each Google Cloud project, along with the number of enabled versions per secret, the replication policy (automatic or user-managed locations) and the projects that hold them. Include secrets used by Cloud Run, GKE, Compute Engine and CI pipelines, since each one counts toward the bill. Export the inventory as a spreadsheet and record the replica locations in use. You know this step is done when the total of active versions and replica locations matches what the Google Cloud console and your billing export show for the same projects.
Count access operations and rotation events
Pull access counts from Cloud Logging and billing data for a representative period, separating application reads, CI and deployment reads, and any rotation-triggered reads. Note how many rotation notifications your rotation functions receive, because those notifications are billed separately. Ask the team whether reads cluster around deployments or run steadily, since that affects both peak load and the cost trend. You know this step is done when you have a monthly read count and a rotation count you can defend, with the source of each figure written beside it.
Price the Secret Manager bill from published rates
Apply Google's current published prices for active secret versions, access operations and rotation notifications to the inventory and counts from the previous steps. Multiply active versions by the number of replica locations, because replication settings change the per-version charge. Keep the calculation in a sheet with one row per cost driver so each assumption can be changed later. Check the rates on the day you run the model, since they can change. You know this step is done when the sheet produces a monthly figure and a projected annual figure, and a second scenario shows how the total changes if you reduce replica locations.
Size an OpenBao topology for the same workloads
Design the OpenBao layout your architecture team would run: the number of nodes for high availability, the storage backend (integrated Raft storage or PostgreSQL), the regions or data centers involved, and whether backups and disaster recovery need separate infrastructure. Map each workload to an auth method, such as Kubernetes, JWT/OIDC, AppRole or the GCP method, so you know which identities need access. Confirm the sizing against OpenBao's HA and storage documentation and against your own load tests. You know this step is done when a diagram and a node list exist, and each workload has a named auth method and a named secrets path.
Add one-time and recurring self-hosted costs
List the infrastructure for the OpenBao nodes, storage, load balancing, backups, monitoring and network links, and price each item at your cloud or data center rates. Add one-time costs such as migration work, integration with CI and workloads, policy design, testing and documentation. Add recurring costs for staff time on patching and upgrades, on-call coverage, certificate and key management, and any support retainer you choose. Note who is paid for each item: your own staff, your cloud provider, or an implementation partner. You know this step is done when every line is tagged one-time or recurring and has a named owner.
Run a three-year view with the same growth
Apply the same growth assumptions to both models: the same rise in secret count, versions, access operations and workloads each year. Compare totals for year one, year two and year three, with one-time costs placed in the year they occur. Run a sensitivity check that doubles access operations and one that adds a second region, since these show how each model scales. Record which costs drive the difference, so a reviewer can see whether the result depends on read volume, replication or staff effort. You know this step is done when both models report the same three-year workload and the gap is explained by named drivers.
Request fixed-scope quotes before deciding
If you plan to use an implementation partner, send the same written scope to each candidate. The scope should list the secrets, environments, auth methods, integrations, HA design, backup and migration tasks, documentation and support period you need. Ask each partner to state deliverables, assumptions, exclusions and what triggers a change order. DeployOpen, for example, agrees scope, deliverables and timelines in writing before work starts, and provides a quote from that scope rather than from a price list. You know this step is done when every quote covers the same written scope, and you have compared the totals against your three-year model.

Costs teams forget on each side

Both options carry costs that do not appear on a line item at first glance. On the OpenBao side, the work sits with your staff: key custody, backups, upgrades and monitoring. On the Secret Manager side, the costs sit around the service: rotation code, IAM administration and traffic leaving Google Cloud. Count these in staff time before comparing totals.

Unseal and recovery key custody

OpenBao starts sealed and needs unseal material before it serves secrets. The Shamir-based setup used in the migration path depends on keys held by named people, distributed and rotated through a documented ceremony. Staff time goes into planning who holds each share, rehearsing the unseal procedure and keeping the process current as people change roles. Ask your team who can unseal the cluster at 2 a.m. without the person who set it up.

Backup and restore testing

Storage backups only protect you if a restore has been rehearsed. For integrated storage, PostgreSQL or another supported backend, the recurring cost is the time spent scheduling snapshots, verifying them and running restores into a separate environment. Secret Manager handles durability for you, so this effort is new work on the OpenBao side. Plan a restore drill on a schedule and record how long it takes your team.

Patch and release tracking

Upstream releases arrive on their own schedule. OpenBao v2.7.1 was released on October 1, 2026 with security fixes, alongside v2.6.4 for the previous minor line. Someone must watch the release feed, assess which fixes apply to your deployment, test them in staging and schedule a rolling upgrade. With Secret Manager, Google applies platform patches, so this is effort you take on yourself.

Helm chart version upkeep

If you run OpenBao on Kubernetes, the recommended install path is the OpenBao Helm chart, which requires Helm 3.6 or later. Chart versions, values files and Helm itself need to stay compatible with your cluster version. Each upgrade means reviewing the chart changelog, diffing rendered manifests and confirming that the server image and chart match. Budget this as recurring platform engineering time.

Monitoring and alerting for the service

A secrets service that is sealed, unavailable or failing leases stops every workload that depends on it. You need alerts on seal status, leader changes, storage latency, lease and token growth, and certificate expiry for the listeners. Secret Manager surfaces availability to you through Google's own operations, while OpenBao requires dashboards, paging rules and on-call coverage that your team owns. Ask who receives the page and who acts on it.

Pub/Sub rotation, IAM and egress on the Secret Manager side

The cost of staying on Secret Manager is not only the per-version and per-access charge. Rotation runs through Pub/Sub notifications that trigger code you write and operate. IAM bindings across projects need periodic review and cleanup. Workloads on AWS or Azure that read secrets from Google Cloud also pay for network egress, and that charge grows with read volume. Model these as recurring engineering and cloud networking costs, and confirm current rates on Google's pricing pages.

What the one-time migration costs and when it pays back

The one-time cost of leaving Secret Manager is mostly engineering time, and it is the figure that decides payback, so get it quoted before you model savings. The work has five parts: reading every secret version out of Secret Manager within the per-project access quotas (which you should confirm in the Google Cloud console for your projects), mapping secret names, labels and IAM bindings to OpenBao paths and policies, moving each workload to the GCP auth method, replacing the Pub/Sub-triggered rotation functions you wrote, and running both stores in parallel during cutover. Each part scales with the number of secrets, consumers and rotation jobs, not with the size of the platform itself. The OpenBao migration guide covers in-place upgrades from Vault Community 1.14.1 on Raft with Shamir unseal, and it does not cover exporting from Secret Manager, so budget that export and re-mapping work as a separate project.

Ask for each part as its own line item in the written scope: export tooling and validation, policy and path design, workload changes per team, rotation rebuild, cutover rehearsal, and a rollback plan. Ask who carries each item (your team, a partner, or both) and what is one-time versus recurring. Dual running has a cost of its own. Secrets exist in two stores until consumers move, so the parallel period adds read activity against Secret Manager and extra operator attention on both sides. Also plan for CMEK-protected secrets, which need key access in the new environment before any value can be read. Decide on payback only after the one-time effort is quoted. Compare that figure with the monthly Secret Manager bill, which you can pull from your billing export, and with the recurring OpenBao costs described above. If the one-time quote is large relative to your current spend, the case for migration usually rests on a non-cost driver such as data location, lock-in or a licensing change, and you should state that case explicitly. Recheck the quote if your secret count or rotation scope changes during the project.

Questions buyers ask before comparing Secret Manager with OpenBao

Is self-hosted OpenBao cheaper than Google Cloud Secret Manager?

It depends on your secret volume, replication settings and how much operating time you must pay for. Secret Manager bills per active secret version, per access operation and per rotation notification, so its cost rises with the number of versions you keep and how often workloads read them. OpenBao has no license fee under MPL 2.0, but you pay for the compute and storage that run it, for the setup work, and for the people who operate it. Build a side-by-side model with your own counts of secrets, versions, reads and replica locations, then check Google's current published prices for each component before you compare totals.

How much effort does running OpenBao take, and what skills does it need?

Running OpenBao is ongoing work, not a one-time install. Your team needs to handle unsealing, high availability, storage backup and restore, TLS, auth method configuration, policy management and upgrades. OpenBao is a fork of Vault, so people familiar with Vault will find the concepts familiar. The Helm chart is the recommended Kubernetes install path and requires Helm 3.6 or later. Storage choice affects operating effort: the OpenBao docs describe PostgreSQL as easier to operate safely than Raft. Confirm the staffing you need against your own availability targets and on-call model before comparing costs.

How long does a migration from Secret Manager take, and what drives that time?

The duration depends mainly on how many secrets, versions and workloads you must move, and how many of those workloads read secrets directly through code, CI pipelines or Pub/Sub-driven rotation functions. Other drivers include how much version history you keep, whether secrets are protected with customer-managed encryption keys, how IAM bindings map to OpenBao policies, and how many teams must test their own cutover. No fixed duration applies to every environment, so ask for a timeline built from an inventory of your secrets and consumers.

Can our team run this migration without an outside implementation partner?

Many teams can do it in-house if they have engineers who already operate Vault-style systems, time for testing, and a clear rollback plan. The work that usually needs the most care is the inventory, workload cutover and the rotation logic you currently run outside Secret Manager. A partner can help with architecture, hardening, backup design and cutover support, but the decision should rest on your staff's experience and capacity. Ask any partner for a written scope that lists what they will and will not do.

What actually drives the Secret Manager bill up?

Four components drive the bill: active secret versions, counted per replica location, access operations and rotation notifications. Keeping many old versions multiplies the version charge, and each additional replica location adds to it, so replication settings are a direct cost lever. Frequent reads from autoscaling services, short polling intervals and per-request secret fetches add access operation charges. Rotation notifications add charges when you rely on scheduled rotation events. Review your current invoice line by line against these components and confirm the exact unit prices with Google.

Do you offer a fixed-scope implementation of OpenBao?

Yes. Most DeployOpen engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. DeployOpen plans, implements, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. Ongoing support, upgrades and continuous testing are available as retainers. DeployOpen does not publish a price list, so the written scope is the basis for a quote.

What should a quote for an OpenBao implementation include?

A useful quote lists each component in scope and the work attached to it. Ask for the architecture and sizing assumptions, including server count, storage backend and high availability design, plus the Kubernetes or VM target and the Helm chart version. It should cover the secret inventory method, migration approach, workload and auth method changes, rotation replacement, backup and restore testing, documentation, handover and any post-implementation support or upgrade retainer. Also ask which items are one-time and which recur, what your own team must provide, and what is excluded. Confirm with the partner how they will handle dependencies on your infrastructure teams.

How DeployOpen scopes a fixed-price OpenBao implementation

DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For a Google Cloud Secret Manager cost review, we start from a written scope that separates the Secret Manager bill you have today from the OpenBao servers, storage and operations you would run instead.

How we scope

We inventory secret counts, versions, replica locations, access volume and rotation notifications before any OpenBao sizing begins.
Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
The written scope states which workloads, auth paths and storage backend are included, so the quote follows from it.

How we build

We deploy OpenBao in your environment, choosing integrated storage or PostgreSQL based on your operating skills and HA needs.
We map existing access patterns to OpenBao auth methods and policies, and test read paths against your real workload profile.
We document the cost model, including server, storage and operations components, so you can check each line against your own usage.

How we hand over

You receive architecture, configuration, runbooks and a record of what was tested and what remains open.
We walk your platform and security teams through unseal procedures, backup and restore, and upgrade steps.
Migration cutover and the decommissioning of Secret Manager versions are agreed in the written scope, with your sign-off at each step.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover.
A retainer can cover OpenBao version upgrades, such as tracking the OpenBao release notes and applying security fixes in your environment.
Ask any provider to confirm the support hours, response targets and escalation path in writing before you sign.

Google Cloud Secret Manager cost vs self-hosted OpenBao