What secrets management costs when you build, partner or buy SaaS
The answer depends on how many secrets you hold, how many times applications read them, how you design high availability and storage, how many systems you must integrate, whether any keys must sit in hardware, and how much staff time you can give the platform. A team moving secrets, keys and certificates out of code and config will find that the license line is often the smallest part of the comparison. The public reference point for a cloud service is AWS Secrets Manager, which costs $0.40 per secret per month and $0.05 per 10,000 API calls, with no upfront costs or long-term contracts, according to the AWS pricing page. Multiply your secret count and read volume by those rates to see the cloud service's recurring bill, then add the cloud KMS and egress charges your own design may trigger. HashiCorp does not publish Vault Enterprise prices. Its pricing pages direct self-managed Enterprise buyers to sales, so a comparison against Vault Enterprise needs a written quote.
Self-hosted OpenBao or Infisical shifts the bill to infrastructure and people. Recurring costs include compute and storage for at least three nodes in a high availability design, backups, monitoring, certificate work, upgrades and on-call time. OpenBao's supported HA backends are integrated storage (Raft) and PostgreSQL, so confirm whether your database team already runs a managed PostgreSQL service you can use. One-time costs include the design, the migration of secrets already in code and pipelines, and the integration work for each application, pipeline and database, which often grows faster than the platform itself. If keys must sit in hardware, add HSM hardware and its support contract, and confirm with the vendor whether the HSM capability you need is in the edition you plan to run. Ask any partner for a quote that separates one-time work from annual support, names each integration, and states who carries the on-call and upgrade work after handover.
Which cost components apply in each model
This table compares the cost components of building in-house, buying implementation help, and using a cloud secrets service such as AWS Secrets Manager. Read each cell for whether the cost is one-time, recurring or usage-based and who pays for it. The main takeaway is that self-hosting shifts spend from per-secret fees to people, infrastructure and integration work, so the quote should separate those lines.
| Cost component | In-house build | Implementation partner | Cloud SaaS (for example AWS Secrets Manager) |
|---|---|---|---|
| Software licensing | OpenBao is MPL-2.0 with no license fee. Infisical core is MIT, but ee directories need a separate enterprise license. Confirm which features you need. | Same as in-house, plus any enterprise license the client buys directly. Ask whether the quote includes license resale or only pass-through. | Usage-based. AWS lists $0.40 per secret per month and $0.05 per 10,000 API calls, with no upfront costs or long-term contracts. |
| Infrastructure for server nodes | Recurring, paid by the client. Compute, load balancers and monitoring for an HA cluster of OpenBao or Infisical nodes. | Recurring, paid by the client on its own cloud or data center accounts. Ask the partner to size node count and separate environments. | Included in the service fee. Client pays nothing for servers but may pay for network egress and related services. |
| HA storage (integrated storage or PostgreSQL) | Recurring infrastructure plus setup time. Confirm which backend fits your operating model, since OpenBao documents PostgreSQL as easier to operate safely than Raft. | Setup is one-time. Ongoing database hosting is recurring and paid by the client. Ask who owns backup and restore testing. | Included in the service. Not visible to the client. |
| HSM or cloud KMS for key custody | One-time hardware or onboarding plus recurring HSM support or cloud KMS usage. Confirm whether the HSM is required by policy before pricing it. | One-time integration work plus recurring HSM or KMS fees paid by the client. Ask for the HSM model and support terms in writing. | Usage-based key fees and any dedicated key service. Confirm which key types and regions are covered. |
| Integration work per application or pipeline | One-time per application, paid by internal staff time. Number of auth methods and workloads drives the effort. | One-time per application or pipeline, billed on the written scope. Ask for a fixed price per integration type and the list of systems covered. | Mostly one-time configuration effort by the client, plus usage-based API call charges as more systems read secrets. |
| Security testing and audit evidence | One-time and recurring testing, paid by the client. Assessors will expect evidence of configuration, access and audit logs. | One-time scoped testing and evidence preparation, plus optional retainers. Independent auditors still issue any assessment report. | Shared responsibility. Client pays for its own testing, evidence collection and any third-party assessment of the service. |
| Upgrades, backups and patching | Recurring internal staff time. Includes version tracking, offline or staged upgrades and restore tests. | One-time upgrade plan and recurring retainer if the client buys ongoing support. Ask what is included in each upgrade cycle. | Included in the service fee. Client still tests its own dependent applications after provider changes. |
| Ongoing operations time | Recurring internal staff time for on-call, rotation policies, access reviews and incident response. This is usually the largest unknown, so request a staffing estimate. | Recurring only if a support retainer is bought. Ask for response targets in writing, since no SLAs are assumed here. | Lower internal operations time for the platform, but the client still runs access reviews, rotation policy and incident handling. |
What is one-time and what recurs every month
The most useful split for a budget is between work you pay for once and costs that repeat for as long as the secrets platform runs. Build effort, the first migration of secrets out of code and configuration files, auth method design and policy writing are mostly one-time. Each application you onboard adds its own integration work, and that also lands early in the project, but it stops being a fixed cost once the pattern is established. Node hosting, storage, backup restore tests, version upgrades, on-call time for a security-critical service, rotation work and any license renewal for enterprise features recur every month or year. Ask a partner to show these as separate lines in the quote so you can see which part of the cost survives the first year.
SaaS pricing reverses the shape of the cost. AWS Secrets Manager charges $0.40 per secret per month and $0.05 per 10,000 API calls, with no upfront costs or long-term contracts, according to the AWS Secrets Manager pricing page. Those fees scale with the number of secrets, environments and reads. As an illustrative calculation, take 500 secrets across 4 environments (2,000 secrets), with 2 million reads a month. The secret charge is 2,000 times $0.40, or $800 a month. The call charge is 200 units of 10,000 calls at $0.05, or $10 a month, for a total of about $810. Replace the numbers with your own counts of secrets, environments and daily reads, and note that every new environment or per-tenant secret increases the bill in a straight line.
OpenBao runs as an active node that holds a lock in the data store, with standby nodes that forward or redirect requests. Integrated storage (Raft) and PostgreSQL are the officially supported HA backends, so the number of nodes and the storage design you choose drive your recurring infrastructure cost. Since OpenBao 2.5.0, Raft standbys can serve read-only operations, and v2.7.0 extended that to PostgreSQL, which can affect how many nodes you need for read-heavy workloads. Confirm with your partner how many nodes, which storage backend and which backup schedule the quote assumes, and ask who pays for the database service if PostgreSQL is the chosen backend.
What moves the cost up or down
Self-hosted secrets management costs follow the shape of the deployment more than the software license, which is free for OpenBao and Infisical's MIT-licensed core. The drivers below connect the scope you pick to the cost direction it creates and the question to put to a partner before you accept a quote.
Number and type of secrets
Static secrets, dynamic database credentials, certificates and encryption keys have very different operating costs. Static secrets need rotation work and owners, while dynamic secrets shift effort into integration and lease tuning. Each certificate and key type adds issuance, renewal and revocation paths. If you use a per-secret cloud model, the count of secrets, not the count of users, sets the bill. Ask the partner to inventory each class and state which ones will be automated and which will stay manual.
Application and pipeline integrations
Every application, CI job and Kubernetes workload that reads a secret is an integration with its own auth method, policy and failure mode. Integration work usually costs more than the platform install, and it recurs whenever a team adds a service. Per-call cloud pricing also rises with read frequency, so chatty workloads cost more to run. Ask the partner for the expected integration count, the auth method for each (for example AppRole for servers and JWT/OIDC for pipelines), and whether they will migrate existing hard-coded credentials.
HA and disaster recovery topology
A production cluster needs several nodes, a supported storage backend and tested backups, and each extra site or replica adds hosts, licenses and operator hours. OpenBao supports integrated storage (Raft) and PostgreSQL for high availability, and newer releases allow standbys to serve reads, which can shift load but not the core topology cost. Multi-site disaster recovery usually doubles infrastructure and test effort. Ask the partner which backend they recommend, how many nodes they propose per site, and how often they restore backups in a test.
HSM and hardware key custody
If keys must sit in hardware, the hardware, support contracts and integration effort become the largest one-time items in the design. HSM costs depend on vendor, model, quantity and whether you run them in two sites, and none of these figures are supplied here. Vault Enterprise lists HSM support and a PKCS#11 provider as licensed features, and OpenBao's HSM support should be confirmed for the exact release you plan to run. Ask the partner which custody model they propose, what hardware is in the quote, and who holds spare units.
Enterprise features and license terms
Replication, FIPS compliance, namespaces, seal wrapping and automated upgrades are Enterprise features in HashiCorp Vault and need a license applied to the cluster. HashiCorp's pricing pages direct self-managed Enterprise buyers to sales rather than publishing Vault Enterprise prices, so the cost must come from a written quote. Vault's Business Source License 1.1 applies from version 1.15.0 and later, and OpenBao is MPL-2.0. Ask the partner which features the design needs, whether each is in OpenBao or requires a commercial Vault license, and what the license term covers.
Staffing and operations model
Operations time is the recurring cost that most build estimates leave out. Someone must patch, upgrade, rotate unseal material, monitor leases, respond to outages and review audit logs, whether in-house, through a retainer or through a SaaS vendor. An in-house team carries salary and on-call costs, a retainer converts part of that into a fixed monthly line, and SaaS shifts the work to the vendor but keeps per-secret and per-call fees. Ask the partner for the support hours included, the upgrade cadence, the escalation path and what the handover requires from your staff.
How license choice changes the total
The license you choose sets which costs you carry and which you can avoid. OpenBao is licensed under MPL-2.0, so the core secrets manager carries no license fee, and its repository is hosted under the OpenSSF with open governance. Infisical is MIT licensed outside the ee directories, which carry a separate enterprise license. That means the license cost depends on which features you need: a team that only uses the core may pay nothing in license fees, while a team that needs enterprise-only controls should get those terms in writing before it compares totals with a cloud service.
HashiCorp changed the picture for Vault. It announced on August 10, 2023 that future releases would move from MPL-2.0 to the Business Source License 1.1, and the Vault LICENSE file names IBM as licensor for Vault 1.15.0 and later. IBM completed its acquisition of HashiCorp on February 27, 2025. Vault Enterprise features such as performance replication, HSM support, namespaces and FIPS compliance require a license applied to the cluster, and HashiCorp's pricing pages direct self-managed Enterprise buyers to sales rather than publishing prices. Any license-related line item in your model is therefore a quote, not a list price.
Before you compare totals, list the features your design needs, such as HSM integration, replication, namespaces, or audit and compliance features, and confirm for each one whether it is in the open-source edition or requires a commercial license. Ask the vendor or partner to state in writing the license term, the scope of use (including hosted or managed use), the metric the fee is based on, whether renewals change the price, and what happens to your deployment if you stop paying. Only then set those figures against the infrastructure, staffing and cloud pricing lines in your model.
How to build your own secrets management estimate
This sequence turns a vague sense of cost into a counted inventory of secrets, integrations, reads and topology, so you can price a self-hosted deployment and a SaaS alternative on the same basis. Each step ends with an artifact you can hand to a partner or finance team.
Inventory secrets by type and environment
Your security or platform lead lists every secret the organization holds and groups it by type: static credentials, dynamic database credentials, TLS certificates, and encryption keys. Split each group by environment, such as production, staging, development and disaster recovery sites. Include secrets that sit in code, configuration files and CI variables, because they will need migration effort even if they are not yet managed centrally. The step is done when you have a table of counts per type and environment that an engineer and an auditor would both accept as complete.
Count applications and pipelines to integrate
Platform engineering lists each application, service, Kubernetes workload, CI/CD pipeline and script that will read from the secrets store. For each one, note the authentication method it will use, such as AppRole for servers, Kubernetes auth for pods, or JWT/OIDC for pipeline jobs. Integration effort tends to scale with this list more than with the number of secrets, so record the owner and the language or framework of each item. The step is done when every consumer has a row with an owner, an auth method and a note on how it currently gets its credentials.
Measure daily and monthly read volume
Using logs from existing systems or sampling over a representative period, the platform team estimates how many read operations each application makes per day and per month. This matters for SaaS pricing, because AWS Secrets Manager, for example, charges per secret per month and per 10,000 API calls, so read volume drives the recurring line. It also informs sizing of a self-hosted cluster. The step is done when you have a read count per consumer and a total, with the measurement method noted so a vendor can check it.
Define high availability and disaster recovery topology
The infrastructure lead decides how many OpenBao nodes you need for high availability, which storage backend will hold the data (integrated Raft storage or PostgreSQL are the officially supported HA options), where nodes sit across failure domains, and how backups and a secondary site are handled. Choose the number of environments that need their own clusters. The step is done when you have a written topology diagram listing node counts, storage type, regions or data centers and backup location, which becomes the basis for infrastructure pricing.
Decide hardware security module and custody needs
Security, compliance and legal stakeholders determine which keys must be held in hardware, which can be protected by software, and who holds unseal and recovery material. Any requirement for an HSM adds hardware or service cost and must be confirmed against the rules that apply to your sector and the auditor's expectations. Record the decision per key class. The step is done when each key class has a documented custody method and an owner, and any HSM requirement is listed as a separate cost line.
List required enterprise features
Using the requirements from earlier steps, the platform lead lists any capability you need that sits in a commercial tier rather than the community release, such as replication across sites, namespaces for team isolation, or FIPS-related functions. For HashiCorp Vault Enterprise, these features need a license applied to the cluster, and HashiCorp does not publish Vault Enterprise prices, so ask the vendor for a quote. Confirm for OpenBao and Infisical which features are available in their open-source editions and which sit in enterprise directories or paid tiers. The step is done when you have a feature list marked as included, licensed or unconfirmed.
Estimate monthly operations hours
The operations owner estimates the recurring hours needed for patching, backups and restore tests, certificate and secret rotation, access reviews, monitoring, and upgrades. Count these per month for each environment and note who performs them, whether internal staff or a support retainer. Include on-call coverage if the secrets store is critical to production availability. The step is done when you have an hours-per-month figure by task and role, reviewed by someone who runs similar systems today.
Price SaaS and self-hosted options on the same basis
Finance and the platform lead price a cloud or SaaS option using the vendor's published unit rates applied to your counted secrets and read volume, then price the self-hosted option by component: compute, storage, backup, HSM if required, licenses, integration work from the written scope, and operations hours at your internal rates. Request a quote from any implementation partner against a written scope, and ask for it to separate one-time items (design, migration, integration, hardening) from recurring items (infrastructure, licenses, support, upgrades). The step is done when both options sit in one spreadsheet with the same assumptions and a list of open questions for each vendor or partner.
Secrets management cost questions buyers ask
How much does self-hosted secrets management cost compared with AWS Secrets Manager?
The software license is not the main difference: OpenBao is MPL-2.0 licensed, so the cost of a self-hosted deployment is the infrastructure, the people and the integration work. AWS Secrets Manager is priced at $0.40 per secret per month plus $0.05 per 10,000 API calls, with no upfront costs or long-term contracts, according to the AWS Secrets Manager pricing page. That model is simple to forecast for a small number of secrets but grows with secret count and call volume. A self-hosted cluster has recurring costs for compute, storage, backups and at least three nodes for high availability, plus one-time costs for design, migration and integration. Compare both sides over the same secret count, call volume and years. Ask any partner to show the infrastructure, labor and support lines separately in the quote.
Can our team build a secrets manager without outside help?
Yes, a capable platform team can deploy OpenBao without a partner, but the work needs skills across several areas. The team needs experience with TLS, Linux hardening, storage and backups, identity protocols and policy design, plus enough on-call capacity to handle unseal, upgrades and incidents. Integration is often the largest share of effort, because each application, pipeline and database must be moved from static credentials to a supported auth method. OpenBao documents AppRole, JWT/OIDC, Kubernetes, LDAP, TLS certificates and other methods, and the right choice depends on each workload. Teams that lack one of these skills usually buy help for design and migration, then run the platform themselves. Map your current skills against this list before deciding.
How long does a secrets management migration take?
The duration depends on the number of applications and secrets, how many are hard-coded in code, configuration or CI variables, and how many auth paths must be built. No duration figure is supplied for this topic, so ask each partner for a timeline based on a written scope rather than a generic estimate. Typical drivers include the inventory of secrets, the number of environments, the need for dynamic database credentials, whether certificates are included, change windows, and testing of backup and recovery. If you are moving from an existing Vault deployment, the OpenBao migration guide was tested only against Vault 1.14.1 community edition, so ask how the partner will validate any Enterprise features you depend on.
How much of our staff time will the engagement need?
Client staff time is usually concentrated in discovery, approvals and testing rather than in building the platform. Expect requests for an inventory of applications, owners, secret types and environments, and access to the systems that need new auth methods. Security and compliance staff should review key custody, unseal design, policies and audit log routing. Application owners must test their workloads against the new paths, and operations staff need to take part in backup restore tests and failover drills. Ask the partner to list each role, the expected number of meetings and test windows, and the decisions that must be signed off in the written scope.
Is an HSM always required for secrets management costs?
No. An HSM is needed only when a rule, contract or internal policy requires that keys be held in hardware. OpenBao's storage and HA design can run without one, and the cost of an HSM, its support contract and its integration work is an additional line item when it is required. Hardware costs and the work to integrate them are not included in any supplied figure, so request them as a separate line in the quote. Some sectors, such as those with explicit key custody rules, will need hardware-backed storage. Confirm the requirement with your compliance team before you specify hardware, because the answer changes the design and the budget.
How do license terms change the total cost of ownership?
License terms affect whether you can use a product in the way you plan, and whether future changes can alter your costs. OpenBao is licensed under MPL-2.0 and managed under open governance. HashiCorp Vault version 1.15.0 and later is licensed under the Business Source License 1.1 with IBM named as licensor, which is not an OSI-approved open source license, and it bars competitive hosted or embedded offerings. HashiCorp's pricing pages direct self-managed Enterprise buyers to sales rather than publishing Vault Enterprise prices, so that cost cannot be compared directly. Ask any partner to confirm the license of every component, any features that need a commercial license, and how the license could change during your planned lifetime.
What does ongoing support for a self-hosted secrets manager cost?
Ongoing support is a recurring cost, separate from the initial project. It covers upgrades, patching, monitoring, backup verification, rotation policy changes, new application onboarding and incident response. DeployOpen offers ongoing support, upgrades and continuous testing as retainers, and most engagements are fixed-scope with scope, deliverables and timelines agreed in writing before work starts. DeployOpen does not publish a price list, so ask for a retainer quote based on the number of environments, the services covered, and the response expectations you need. Compare that recurring line with your internal on-call and upgrade effort, and with any recurring cloud charges that would otherwise apply.
What a fixed-scope partner quote should include
A partner quote for self-hosted secrets management is only comparable to a cloud bill if it is written against a defined scope. Ask for the inventory of secret types in scope (static credentials, dynamic database credentials, certificates, and encryption keys), the list of applications, pipelines and clusters that will authenticate, and the auth methods planned for each, such as AppRole for servers and Kubernetes or JWT/OIDC for workloads. Each integration is separate work, so the quote should state how many integrations are included and what happens when a new one is added. DeployOpen plans, implements and hardens self-hosted platforms inside the client's own cloud accounts, data centers or isolated networks, and most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
Resilience and key custody are where quotes most often diverge. Ask the partner to specify the storage backend for high availability (integrated storage with Raft or PostgreSQL, both officially supported for OpenBao HA), the node count and placement, the backup design, and the disaster recovery target. For keys that must sit in hardware, ask whether the quote covers an HSM or a cloud KMS seal, who holds unseal and recovery material, and who pays for the hardware. Migration is a separate line item: ask how existing secrets in code, configuration and CI variables will be inventoried, rotated and moved, and whether the migration guide's tested Vault version matches the source you run.
Require acceptance evidence in the quote itself. Look for a documented failover test, a restore test from backup on a separate environment, and a runbook for unseal and rotation, plus audit logs routed to your SIEM. Then confirm the handover: documentation delivered, staff trained, and a clear split between the fixed-scope build and any retainer for upgrades, patching and support. Upgrade cadence and security patch response should be written down, not implied. Ask the partner to list what they will not do, such as issuing audit reports, since independent auditors perform those assessments, and what you must provide, such as network access, cloud accounts and named approvers.
How DeployOpen scopes, delivers and supports the work
The sequence below takes a secrets management decision from an inventory of what needs protecting to a documented, tested platform that your own team can run, with ongoing support available as a separate retainer. Each step ends with a written output you can check before the next one starts.
Inventory secrets, keys and integrations
DeployOpen works with your platform, security and application owners to list where secrets, certificates and encryption keys live today: configuration files, CI/CD variables, Kubernetes secrets, database credentials, service accounts and hardware-backed keys. Each application is recorded with its owner, its authentication method and the systems it calls. The output is a secrets inventory and an integration register that show what must move, what can be retired and what needs a decision from your team before scoping can close.
Agree written scope and deliverables
Based on the inventory, DeployOpen drafts a written scope that names the platform (OpenBao or Infisical, or a confirmed alternative), the storage and high availability design, the number of integrations in scope, the unseal and recovery key approach, the audit log destination and the handover items. Your procurement, security and architecture leads review and sign the scope. The output is a signed fixed-scope statement of work, with exclusions and change requests described in writing before any build starts.
Prepare the client infrastructure
DeployOpen confirms with your infrastructure team which cloud accounts, data center segments or isolated networks will host the cluster, along with network paths, DNS, certificate authority, identity provider and logging targets. Hardware security module needs are confirmed at this stage if keys must remain in hardware. The output is an environment readiness checklist signed by your infrastructure owner, so the build runs in a space you control and you know exactly which components are yours to operate.
Build the cluster and migrate integrations
DeployOpen installs the chosen platform, configures high availability with the storage backend agreed in scope, sets up authentication methods for people, servers and pipelines, and writes access policies per team or application. Integrations are moved in batches, starting with lower-risk workloads, and each application's old hard-coded or shared credentials are rotated and removed after its new path is confirmed. The output is a running cluster with a migration log that lists every moved secret and the policy that governs it.
Harden and test the platform
DeployOpen applies the hardening baseline agreed in scope, including network restrictions, TLS settings, audit device configuration and log forwarding to your monitoring system. It then tests failover of the active node, restore from backup, unseal procedures, rotation of a sample of dynamic and static secrets, and revocation of a lease. The output is a test report with each result recorded as passed, failed or accepted by you, so you can see the platform's behavior under failure before it holds production secrets.
Document and hand over to your team
DeployOpen delivers architecture diagrams, runbooks for unseal, backup, restore, upgrade and certificate rotation, access policy definitions, the integration register and a list of control evidence your auditors may request. Your operators are trained on those runbooks in a session agreed in scope, and the handover is recorded with named owners for each operational task. The output is a documentation package and a handover record. DeployOpen prepares this evidence for assessment, but it does not issue audit reports or certifications, which remain the role of independent auditors.
Support upgrades and continuous testing
After handover, your team can keep operating the platform alone or engage DeployOpen under a retainer for upgrades, patch testing, periodic restore and failover tests, and continuous security testing of the platform and its integrations. Retainer scope, response expectations and fees are set in a separate written agreement, and no service levels are assumed until they are written into it. The output is a recurring maintenance and test record that shows each upgrade was tested before rollout and each recovery test was repeated on a defined cycle.
