When Google Cloud Secret Manager or OpenBao is the better fit
Keep Google Cloud Secret Manager if your workloads sit almost entirely in Google Cloud, your secrets can reside in Google-managed regions you already approve, and your team wants IAM to remain the single control plane for who reads what. Move toward self-hosted OpenBao if a renewal or pricing change is forcing a decision, if a residency or key-custody requirement needs secrets in a location or under keys you control, or if secrets are spread across GCP, AWS, Azure and Kubernetes and you want one access layer. Neither choice is wrong on its own; the question is which constraint is binding for your organization.
The decision turns on four questions. First, where must secret values reside, and who must hold the encryption keys? Confirm this with your compliance and data protection owners before comparing features, because it may settle the matter on its own. Second, does rotation need to be built or built in? Secret Manager sends rotation notifications and your own code performs the rotation, while OpenBao's database secrets engine can issue short-lived credentials or rotate static accounts itself. Third, how many clouds and clusters need access? Each additional platform adds another auth path to maintain. Fourth, who will run OpenBao day to day? Plan named owners for upgrades, unseal procedures, storage backups and on-call response before you commit.
A useful check is to list every workload that reads a secret today and tag it by cloud, cluster and identity type. If most of them authenticate with a GCP service account and never leave Google Cloud, Secret Manager is probably the lower-effort path. If a meaningful share authenticates from AWS, Azure or on-premises Kubernetes, or needs dynamic database credentials, OpenBao's auth methods and secrets engines start to justify their operating cost. Ask whoever will own the platform to confirm the current OpenBao release line and its support expectations against the OpenBao releases page before you plan an upgrade calendar.
Which option fits which scenario
This table maps common operating conditions to the platform that usually fits better, with the condition that drives the choice. Read each row against your own estate: the fit depends on where workloads run, who operates the platform and where secrets must reside. Google Cloud Secret Manager is often the simpler choice for GCP-only teams, while OpenBao suits estates that need one control plane and their own storage.
| Scenario | Better fit | Driving condition |
|---|---|---|
| GCP-only workloads with IAM-managed access | Google Cloud Secret Manager | Access is already governed by IAM bindings, and the team has no need for a separate policy language or auth layer. |
| Multi-cloud or hybrid estate | OpenBao | Workloads span GCP, AWS, Azure or on-premises, and one service with several auth methods replaces separate cloud stores. |
| Dynamic database credentials | OpenBao | Applications need short-lived database accounts issued on request, which OpenBao's database secrets engine provides and Secret Manager does not issue natively. |
| Strict control over secret location | OpenBao | Secrets must stay in infrastructure the organization controls, which requires confirming the storage backend and regions in the target environment. |
| Teams without platform operations capacity | Google Cloud Secret Manager | No one can own OpenBao upgrades, unseal procedures, backups and HA, so a managed service lowers operating load. |
| Existing OpenBao or Vault operators | OpenBao | The team already runs Vault-style policies and tooling, and the migration path from Vault Community is documented. |
| Rotation handled by application code | Either, depending on design | Secret Manager sends notifications that your own functions act on, while OpenBao can rotate or issue credentials itself; confirm which fits your rotation model. |
Why licensing and governance matter to this decision
Licensing and governance decide who controls the secrets platform over its lifetime, so they belong in the decision alongside technical fit. On August 10, 2023, HashiCorp announced that future releases of its products would move from the Mozilla Public License 2.0 to the Business Source License 1.1, while its APIs, SDKs and most libraries stayed under MPL 2.0. IBM completed its acquisition of HashiCorp on February 27, 2025. OpenBao is a community fork of Vault licensed under MPL 2.0, managed under the Linux Foundation's OpenSSF and classed as a Sandbox project. Those facts describe a change in terms and ownership, not a change in the software you run today, but they affect how much you can plan on future releases behaving as they do now.
The practical difference between the licenses sits in how you use the software. The Business Source License restricts offering a competing service built on the product, and the main restriction targets vendors in that position. Running Vault or OpenBao to protect your own applications, your own CI jobs and your own customers' data inside your own infrastructure is ordinary internal use. Your legal team should still read the license text for the exact version you deploy, and should check whether any internal platform you plan to sell or expose to other organizations would fall under the restriction. Under MPL 2.0, which OpenBao uses, the file-level copyleft obligations apply to modifications you distribute, so confirm how your patches and internal forks will be handled.
Secret Manager is a Google managed service, so its use is governed by Google Cloud's service terms and any agreements your organization holds with Google, not by an open-source license. Those terms can change, and the controls that matter to you, such as data location, encryption options and service commitments, should be confirmed in writing with Google for the products and regions you use. Ask your procurement and legal teams to record the current terms for each service in scope, and to set a review date so that the comparison reflects what you are actually buying today.
Where secrets live and who can reach them
Secret Manager is a managed service that Google operates, while OpenBao runs wherever you deploy it. The cards below cover where the secret data sits, who can reach it, who keeps the logs and what evidence an assessor will ask for, and they name the condition under which each difference matters for your organization.
Data location and regional control
Secret Manager stores secret replicas in locations you select, either automatic or user-managed, so residency is a configuration choice inside Google Cloud. With OpenBao, the data lands wherever you install the storage backend, whether that is a cloud account in a region you pick, a data center or an air-gapped network. This matters most when a regulator or contract names specific countries. Confirm the replica locations Secret Manager would use for your secrets and the storage location of every OpenBao node and backup.
Identity and access models
Secret Manager access is governed by Google Cloud IAM bindings on each secret or project, and workloads authenticate with their Google identities. OpenBao uses its own policies and auth methods, including GCP, Kubernetes, AppRole and JWT/OIDC, so a workload can be granted access without a Google identity at all. This matters if you run workloads outside GCP or want one policy model across clouds. Map every existing IAM binding to an OpenBao policy and test that no path becomes broader than before.
Audit and logging ownership
Google records Secret Manager administrative and data access events in Cloud Audit Logs, and the platform owner is Google. With OpenBao you own the audit device, the log destination, retention and the protection of those logs. This matters when an internal auditor asks you to prove who read a secret and when. Decide where OpenBao audit logs are written, who can read them, how long they are kept and how they are forwarded to your SIEM before cutover.
Compliance evidence and responsibilities
Under a shared model, Google supplies its own service controls and you supply the configuration, access reviews and key handling. With a self-hosted OpenBao, DeployOpen plans and documents the controls, configures them and prepares the evidence an assessor will sample. DeployOpen does not issue audit reports or certifications, and independent auditors assess the result. Ask your auditor which control evidence they expect for access, encryption, backup and change management before the design is frozen.
Air-gapped and sovereign hosting
Secret Manager is a Google Cloud service, so it cannot run in a network with no connection to Google. OpenBao can be deployed in your own data center or an isolated network, with integrated storage or PostgreSQL as the backend. This matters for defense, critical infrastructure and sovereign-cloud requirements. Confirm how seal and unseal material, offline backups and software updates will reach the isolated environment, since those steps are where most air-gapped operations stall.
How OpenBao can be run and what each model asks of your team
The OpenBao Helm chart is the recommended way to install OpenBao on Kubernetes, and it requires Helm 3.6 or later. This model suits teams that already run clusters, GitOps pipelines and cluster-level monitoring, because OpenBao becomes one more workload with its own storage, network policies and upgrade path. Your platform team owns the cluster, the persistent volumes and the ingress, while the security team owns policies, auth methods and unseal material.
- Helm version: Pin Helm to 3.6 or later in your build images and record the chart version in your change records.
- Storage class: Confirm the storage class and its replication, because the data volumes hold encrypted secrets and their backup depends on it.
- Unseal process: Decide how unseal keys are held and who can perform an unseal after a node restart or a cluster reschedule.
- Upgrades: Plan rolling upgrades and test them in a non-production cluster before each OpenBao release, since releases such as v2.7.1 include security fixes.
- Network exposure: Keep the API reachable only from the workloads and administrators that need it, with TLS between clients and the server.
Confirm with the platform team which storage backend the chart will configure, how node failures are handled, and who receives alerts when a pod cannot reach its storage.
A virtual machine deployment with integrated Raft storage keeps OpenBao on hosts you manage directly, with no Kubernetes dependency. Raft is one of the officially supported HA backends, and it stores data inside the OpenBao cluster, so you do not run a separate database. The trade-off is that your team must maintain the host operating system, time sync, certificates, service supervision and the cluster membership itself.
- Node count: Run an odd number of nodes so the Raft cluster keeps quorum when one node is lost, and place them in separate failure domains where your environment allows.
- Active and standby roles: One active node holds the lock and standby nodes forward or redirect requests, so clients need a load balancer or DNS that follows the active node.
- Read scaling: Since OpenBao 2.5.0, Raft standbys can serve read-only operations, which you should test against your client patterns before relying on them.
- Snapshots: Schedule Raft snapshots to a location outside the cluster and test a restore on a separate host.
- Unseal: Use Shamir unseal or your chosen method and document the procedure for restarts, since each node must be unsealed.
Confirm with the infrastructure team how node replacement works, who runs restores, and whether your VM platform meets the placement rules your security policy requires.
PostgreSQL is the other officially supported HA storage backend, and the OpenBao storage documentation describes it as easier to operate safely than Raft. This model fits organizations that already run managed or well-supported PostgreSQL with backup, replication and patching processes, because OpenBao then relies on those established database practices. The database team becomes a critical part of the secrets service, and the OpenBao team must coordinate with them on every change.
- Database ownership: Name the team that owns the PostgreSQL instance, its backups and its failover, and agree on recovery objectives in writing before go-live.
- Read scaling: OpenBao v2.7.0 extended standby read-only operations to PostgreSQL, which can help with horizontal read load if your access patterns need it.
- Lock behavior: The active node holds a lock in the data store, so test failover to confirm that a new active node takes over and that clients recover.
- Encryption: Secrets are encrypted before they are written to storage, so a database backup contains ciphertext, but you must still protect the unseal material and backup keys separately.
- Connection limits: Size database connections for the OpenBao nodes and monitor them alongside application traffic.
Confirm with the database team which PostgreSQL version and high availability setup they support, and ask for a documented restore test that includes OpenBao.
What a move off Secret Manager involves
A move from Google Cloud Secret Manager to OpenBao is a re-platforming project, not an upgrade. OpenBao's documented in-place migration path starts from Vault Community 1.14.1 on Raft storage with Shamir unseal, and that guide was tested only against that version. Secret Manager has no equivalent path, so plan for a new OpenBao cluster, a data export and a workload-by-workload cutover. Confirm the storage backend, unseal method and HA design you need before anything else, because those choices are hard to change later.
The first technical task is mapping the model. Secret Manager organizes data as secrets containing numbered versions, controlled by IAM bindings on each secret or project. OpenBao uses KV secrets engine paths, and access is granted through policies attached to auth roles. Decide how project and environment boundaries become path prefixes, which labels (if any) carry over as metadata, and how each IAM binding such as roles/secretmanager.secretAccessor translates into a least-privilege OpenBao policy. Review every service account that reads secrets, because a missed binding causes an outage, while an overly broad policy weakens the control you are trying to keep.
Workloads on Google Cloud can authenticate to OpenBao with the GCP auth method, so they can stop carrying static credentials to reach the store. Test that each workload identity maps to the right role, and that reads still succeed within the access and quota limits of your current setup. Pub/Sub rotation functions are the other dependency. Secret Manager only sends notifications, so your own function performs the rotation. In OpenBao, decide whether the database secrets engine can issue short-lived credentials for those systems, or whether your existing rotation code must be rebuilt and re-pointed. Keep the old store readable until every workload has cut over and rollback has been tested.
What drives the cost of each option
How is Google Cloud Secret Manager billed?
Secret Manager is billed by the components you use: active secret versions (counted per replica location), access operations and rotation notifications, all at Google's published prices. Your bill rises with the number of secrets, the number of versions you keep, how often workloads read them, and whether you replicate secrets across more locations. Check the current rate card on Google's pricing page for your region and replication setting, since those rates are set by Google and can change. The Secret Manager bill is recurring and usage-driven: it has no setup fee, but it keeps growing as versions and access volume grow. Ask your team to pull a month of billing data broken down by these three components before comparing it with any other option.
Does OpenBao have a software license cost?
OpenBao is licensed under MPL 2.0, so there is no license fee for the software itself. The cost sits in everything around the software: the servers or Kubernetes capacity it runs on, the storage backend, the time to design and deploy the cluster, upgrades, backups, monitoring and the staff who operate it. These costs are both one-time (architecture, initial deployment, integration with workloads, migration) and recurring (infrastructure, storage, patching, on-call coverage, periodic upgrades such as those tied to new releases). Your total cost depends mostly on how many environments you run, how highly available the cluster must be, and how much of the operating work your existing platform team already covers.
What infrastructure does a self-hosted OpenBao cluster need?
A production OpenBao deployment usually runs as a high availability cluster with an active node and standby nodes, backed by either integrated storage (Raft) or PostgreSQL, which OpenBao documents as supported HA backends. Infrastructure cost therefore covers the compute for each node, the disks or database service behind the storage backend, load balancing, network paths to workloads, and separate environments for staging and disaster recovery. Ask for the number of nodes, the storage backend choice, and whether you need a second region or a separate recovery cluster. Those decisions drive the monthly infrastructure spend more than the OpenBao software does.
What does it cost to run OpenBao day to day?
Day-to-day cost comes from operating work rather than from a license. Recurring tasks include unsealing and key handling procedures, monitoring node health and lease volume, rotating certificates and tokens, applying security patches and planning version upgrades, and testing restores. Each of these takes staff time, and the amount depends on how many clusters you run, how often you upgrade, how many auth methods and secret engines you enable, and whether you have an on-call rotation that covers the secrets service. Ask the vendor or partner to split the operating estimate into staff hours per month and to list which tasks are automated and which are manual.
What are the backup and monitoring costs for self-hosted secrets?
Backups and monitoring are separate costs that Secret Manager largely hides inside the service. With OpenBao you need to back up the storage backend and keep the unseal and recovery material safe, store those backups in a location you control, and test restores on a schedule. You also need metrics, logs and alerts for the cluster, plus audit log storage and retention that meets your own policy. Each item adds storage and tooling cost, and the restore testing adds staff time. Ask for the backup frequency, retention period, restore test plan and the monitoring stack that will be used, because those choices set the recurring cost.
How do setup and migration costs compare with the ongoing bill?
Setup and migration are mostly one-time costs. For OpenBao they include designing the cluster, configuring auth methods such as GCP, Kubernetes or AppRole, mapping IAM bindings to OpenBao policies, moving secrets, updating workloads and retiring the old Pub/Sub rotation functions. For Secret Manager, the one-time part is the inventory and export work needed to leave it. These efforts depend on the number of secrets, the number of workloads that read them, how many rotation functions exist and how many environments are in scope. Once the work is done, the ongoing cost shifts from a usage bill to infrastructure and staff time, so compare the one-time effort against the expected recurring savings over the period you plan to run the system.
What should I ask DeployOpen to include in a quote?
DeployOpen does not publish a price list. A quote follows from a written scope that is agreed before work starts, so ask for the scope to be defined in a way that lets you compare the one-time and recurring parts. Request a breakdown of planning and architecture, cluster deployment, auth method and policy configuration, workload migration, backup and restore setup, monitoring, documentation and handover. Ask which items are fixed-scope deliverables and which are ongoing support, upgrades or testing under a retainer, and confirm which environments, regions and number of secrets the quote assumes. Also ask what the client team must provide, such as cloud accounts, staff time and access, since those inputs affect the total effort.
Can our own team run OpenBao without an outside partner?
Many teams can run OpenBao in-house if they already operate Kubernetes or database clusters, have security engineers who understand secrets lifecycles and can staff an on-call rotation. The main cost driver is whether that skill and time already exist. If they do not, the cost of hiring or training staff, plus the time to reach a reliable operating state, usually outweighs the license savings. A partner can cover the one-time build and handover, or an ongoing retainer can cover upgrades and testing. Before deciding, ask your engineers to estimate the monthly operating hours and compare them with the scope you would need a partner to cover.
How a migration from Secret Manager to OpenBao typically proceeds
The sequence moves secrets, access rules and workloads from Secret Manager to OpenBao in controlled stages, so each step has a verifiable output before the next one starts.
Inventory secrets, versions and IAM bindings
List every secret, its versions, labels, replication settings and any customer-managed encryption keys, along with the IAM bindings that grant access to each secret. The team that owns each workload confirms which secrets it reads and how often. The output is a reviewed inventory that maps each secret to a consuming service and identity. The step is done when the platform team and application owners agree the inventory is complete.
Design OpenBao paths, policies and auth methods
Translate the inventory into a KV path layout, a set of OpenBao policies and the auth methods each workload will use. Workloads on Google Cloud can be matched with the GCP auth method, while other callers may use AppRole, JWT/OIDC or Kubernetes auth. Confirm the GCP auth method's configuration with OpenBao's current documentation before relying on it. The output is a written access design that a security reviewer can check against the original IAM bindings.
Stand up a non-production OpenBao cluster
Deploy OpenBao in a non-production environment in your own infrastructure, choosing integrated storage (Raft) or PostgreSQL for high availability according to your operating model, and configure unseal and backup procedures. Your team or DeployOpen's configures TLS, audit logging and monitoring. The step is complete when a test cluster passes failover and restore checks and the policies from the design step behave as written in tests.
Migrate secrets and dual-run with Secret Manager
Copy the in-scope secret values into OpenBao paths, keeping the mapping from each source name and version to its destination path. Workloads can be tested against OpenBao while Secret Manager remains the live source, and read traffic is watched against Google Cloud quotas. The output is a reconciliation report showing that every migrated value matches its source for the agreed set of secrets.
Switch workloads to OpenBao in stages
Change one service at a time to read from OpenBao using its new auth method, starting with lower-risk workloads. Each switch is monitored for authentication errors, latency and secret fetch failures, and a rollback path back to Secret Manager is kept until the workload is stable. The step is done when all in-scope workloads authenticate to OpenBao and no longer call Secret Manager.
Replace rotation functions and dynamic credentials
Where a Pub/Sub-triggered rotation function existed, decide whether OpenBao's database secrets engine or another mechanism will issue or rotate the credential, and test it against a non-production database. Document which secrets remain static and who owns their rotation. The output is a rotation register that states the owner and method for each credential.
Decommission Secret Manager and delete versions
After a defined observation period agreed with the owners, disable the workloads' access to Secret Manager, remove the IAM bindings, and delete secret versions and secrets that are no longer needed, following your retention and recovery policy. Retain the export records and audit evidence the organization requires. Confirm the deletion steps and their reversibility in writing before this step begins, since export and cutover depend on your environment.
Questions buyers ask before switching from Secret Manager
How much operating effort does a self-hosted OpenBao cluster take?
Expect ongoing work that Secret Manager currently hides from you. Your team owns the servers or Kubernetes workloads, the storage backend, TLS certificates, unseal and recovery key handling, upgrades, monitoring, and backups of the storage layer. OpenBao supports integrated storage (Raft) and PostgreSQL for high availability, and the storage documentation describes PostgreSQL as easier to operate safely than Raft, which is a factor to weigh against your existing database skills. Policies, auth method configuration, and audit log retention also become your responsibility. Ask your platform team to name who is on call for the cluster and how upgrades will be tested before you commit to a design.
Can our in-house team migrate from Secret Manager to OpenBao alone?
Many teams can, provided they have someone who has run a stateful service in production and a clear owner for security decisions. The hard parts are rarely the secret copy itself. They are mapping IAM bindings to OpenBao policies, moving workloads to the GCP auth method, replacing Pub/Sub rotation functions, and proving that access controls still hold. If your team lacks that experience or has no time for a parallel run, a fixed-scope engagement can cover planning, implementation, hardening, and documentation for the cluster. DeployOpen plans, implements, hardens, backs up, and documents self-hosted platforms in your own cloud account or data center. Scope, deliverables, and timelines are agreed in writing before work starts.
How long does a migration from Secret Manager take?
The duration depends on the inputs, not a standard number. The main drivers are how many secrets, versions, and projects you have, how many workloads read them and how they authenticate, whether any secrets use customer-managed encryption keys, and how many change windows your application owners can offer. Teams with many services often run old and new stores side by side until each workload has switched. No duration figure is given here because none was researched for this comparison. Ask any provider, including DeployOpen, for a timeline tied to a written inventory of secrets, workloads, and IAM bindings.
What do we need to provide for a migration to go smoothly?
Prepare four things before work starts. First, read access to the Secret Manager projects, IAM policies, and audit logs so the current state can be inventoried. Second, a named owner for each application or secret group who can confirm what the secret is used for and approve the cutover. Third, change windows agreed with those owners, including rollback steps. Fourth, a decision on who holds the OpenBao unseal material and how recovery is tested. Access to the target environment, such as the cloud account or Kubernetes cluster that will host OpenBao, is also required. Confirm these items with your security and platform leads at the start of scoping.
Do Secret Manager quotas or replication settings force us to change?
Not necessarily, but they are a common reason teams look at alternatives. Secret Manager bills per active secret version per replica location, per access operation, and per rotation notification, so replication settings and how often workloads read secrets both affect cost. Access operations are also subject to per-project quotas that your team should check against its peak read rates. Confirm current quota values and prices in Google's documentation and your billing data, since this comparison did not research those figures. Self-hosted OpenBao removes the per-operation billing, but it moves capacity planning, replication, and disaster recovery onto your own infrastructure.
How does OpenBao licensing differ from HashiCorp Vault?
OpenBao is a fork of Vault and is licensed under MPL 2.0, which is the license Vault used before August 10, 2023. HashiCorp announced that future releases of its products would move to the Business Source License 1.1, with the main restriction aimed at vendors that offer competing services built on HashiCorp products. IBM completed its acquisition of HashiCorp on February 27, 2025. OpenBao is a Sandbox project of the OpenSSF under Linux Foundation stewardship. Your legal team should still read the current license terms for every product in use, and confirm how any Vault Enterprise or HCP features you rely on would be replaced.
Does migrating require a vendor to certify the result for our audit?
No provider issues the audit result. Independent auditors and certification bodies assess your controls and issue any report or certification. DeployOpen prepares systems, controls, and evidence for compliance assessments, including configuration records, access policies, backup and recovery tests, and change logs. Before the migration, ask your auditor which evidence they expect for secret access, rotation, and key custody so the design captures it from the start.
How DeployOpen helps you decide and implement OpenBao
DeployOpen is a Chainscore Labs company that plans, implements, hardens, backs up, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For a move away from Google Cloud Secret Manager, that work usually starts with a decision rather than an install: which workloads keep using IAM-based access, which move to OpenBao policies with the GCP auth method, and which secrets should become dynamic credentials instead of rotated static values. We can help you map those choices against your current IAM bindings, replication settings and regional data requirements before anything is deployed, and we document the outcome so the reasons behind each choice are on record.
Engagements are fixed-scope. Before work starts, the scope, deliverables and timelines are agreed in writing, so you know what will be built, who checks it and what evidence you receive at the end. Typical deliverables for an OpenBao project include the deployment design (storage backend, high availability layout and unseal approach), the auth method and policy model, migration runbooks for the workloads you choose, backup and recovery procedures, and operator documentation. Ask any provider, including us, to name each deliverable and the acceptance check for it, and to state which items are excluded. Effort and cost follow from that written scope and are quoted from it, not estimated in advance.
After go-live, ongoing support, upgrades and continuous testing are available as retainers, which matters because OpenBao releases move quickly and the upgrade path from an earlier Vault deployment must be planned with care. We also run security testing against the resulting setup, covering the OpenBao API, its auth endpoints, the Kubernetes or VM hosts it runs on and the workload identities that reach it. Where your organization must demonstrate controls to an auditor, we prepare the systems, control descriptions and evidence for the assessment. DeployOpen does not issue audit reports, attestations or certifications; independent auditors and certification bodies do that. Confirm with your assessor which evidence they expect before the project starts.
