What the HCP Vault Secrets end of life means for your secrets
A managed secrets service with a fixed end date means every secret, machine login and sync that depends on it has to move before the service stops. HCP Vault Secrets is no longer sold and reaches end of life by July 1, 2026 at the latest. Confirm the current service status and the notice date for your account directly with HashiCorp, because the open-source releases cited on this page are dated after that deadline and cannot anchor your cutover plan. HashiCorp's suggested paths are HCP Vault Dedicated or Vault Community. The open-source routes are self-hosted OpenBao, a community fork of Vault, or self-hosted Infisical, which bundles secrets, syncs and machine identity in one platform. Either way, the work is the same: inventory what the service holds, choose a target for each item and re-point the workloads that read it.
The inventory should separate three kinds of items, because each moves differently. Static key/value secrets can be read out and written to the new store, but only after you confirm the vendor's export options in writing. Machine authentication, such as service tokens and client credentials, usually cannot be copied across and must be replaced with new identities, for example Kubernetes or OIDC authentication in OpenBao or Infisical. Syncs that push values into GitHub, Vercel or a cloud secret store stop when the source service stops, so each sync needs a named replacement and an owner. Illustrative example: a team with one database password, one CI token and one Vercel sync would track three separate cutovers, not one.
Start the plan with a dated inventory and a parallel run, not a single switch-over. Ask HashiCorp which export paths and support options apply to your account before you commit to a target. Cost follows the path you choose. HCP Vault Dedicated and Vault Enterprise are priced by quote on HashiCorp's Vault pricing page, so request a written quote that covers the managed tier and any migration help. For self-hosted OpenBao or Infisical, the recurring cost is the infrastructure, storage, backups and staff time to operate it, and the one-time cost is the migration project. Ask every option for its scope in writing, then compare it against the deadline you have confirmed.
What the shutdown requires from your secrets inventory
The HCP Vault Secrets end-of-life date turns a routine inventory into a deadline task. The cards below cover what has to be known before any secret moves, from the secrets themselves to the systems that read them and the place they land.
Inventory every secret and its owner
Start with a complete list of secrets held in HCP Vault Secrets, grouped by project and environment, with an owner recorded for each. Many teams discover secrets that no current service uses, and others that several services share. Record which secrets are static values and which were created by a rotation or sync, because those need different handling at cutover. Ask your team to confirm the list against what applications actually read.
Map dynamic and machine identities
Identify every workload, pipeline and service account that authenticates to HCP Vault Secrets, and note how each one proves its identity. Moving a secret without the identity that reads it leaves an application without access. Plan the replacement auth method for each identity, such as Kubernetes, OIDC or AppRole in OpenBao, or Kubernetes, AWS or Universal Auth in Infisical, and confirm each one works before the old path is closed.
List every sync target
Secrets pushed from HCP Vault Secrets into other platforms need their own migration plan. Check each destination, including cloud secret stores, CI variables and deployment platforms, and record which secret feeds which target. Once HCP Vault Secrets stops, those syncs stop too, so each target keeps its last value until someone replaces it. Confirm who owns each destination and how its value will be refreshed.
Set a dated cutover window
Agree on a written cutover schedule that covers freezing changes, copying secrets, switching consumers and retiring the old store. The end-of-life date is the hard limit, so work back from it and leave time for rollback. Decide in advance which applications cut over first and which ones can wait. Ask your vendor or partner to confirm the final shutdown date in writing, since the date is the constraint that drives the plan.
Choose where secrets stay under your control
Decide where the migrated secrets will live and who holds the unseal keys, encryption keys and administrative access. For self-hosted OpenBao, that means your own storage backend, your own key management for unseal and your own backups. For self-hosted Infisical, it means your database, your encryption keys and your SSO configuration. Confirm that the target environment meets your data residency and access requirements before the first secret is copied.
Confirm the export path
Plan how secret values leave HCP Vault Secrets. Each secret must be read out through the service's interfaces and written into the new store, and that step needs a credential with enough access to read every value. Keep a record of what was exported, when, and by whom, and verify a sample of values in the new system before consumers switch. Ask for written confirmation of which export methods your HCP tenant supports.
Which replacement meets the constraint, and at what trade-off
This table compares four routes for teams leaving HCP Vault Secrets: HCP Vault Dedicated, Vault Community, self-hosted OpenBao and self-hosted Infisical. Read each row against where your secrets must run, which license terms you accept and which features your workflows depend on. The main takeaway is that the managed and self-hosted paths differ most in who operates the platform, so confirm feature gaps with each vendor before you commit.
| Option | Where data runs and license | How it fits the constraint | Trade-offs |
|---|---|---|---|
| HCP Vault Dedicated | HashiCorp-managed cloud. Commercial license, pricing by quote | Closest managed path for teams that want the Vault API and operations handled by the vendor | Secrets sit in vendor-operated infrastructure. Recurring subscription. Confirm regions and feature set in writing |
| Vault Community | Your infrastructure. Free to use, with newer releases under the Business Source License | Keeps the Vault API and clients familiar, so application changes stay small | You run storage, high availability, unsealing and upgrades. Enterprise-only features are not included. Confirm which ones you use |
| Self-hosted OpenBao | Your infrastructure. MPL 2.0, community-led under OpenSSF Sandbox | Vault API lineage with Raft or PostgreSQL storage. Documented in-place path from Vault Community 1.14.1 on Raft | You operate storage, high availability, unsealing and upgrades. Check later Vault versions and plugins with the migration guide |
| Self-hosted Infisical | Your infrastructure via Docker, Compose or Helm. MIT outside ee directories | Adds a project dashboard, secret syncs and a Kubernetes operator. Vault KV import is available | Clients need re-pointing and the API differs from Vault. SSO and some gateways need an Infisical enterprise license |
| Feature gaps | Vendor documentation and written quotes | Map each secrets engine, auth method, sync and policy you use against each option | Gaps can change the answer. Get written confirmation before the HCP Vault Secrets end-of-life date |
Where HashiCorp's suggested paths leave the constraint open
The two paths HashiCorp typically suggests for HCP Vault Secrets users, HCP Vault Dedicated and Vault Community, solve different problems, and neither settles the question of where your secrets live and who runs the cluster. HCP Vault Dedicated is HashiCorp's managed service and runs the Vault Enterprise binary, so the operating burden moves to the vendor, but your secrets sit in a managed HashiCorp environment and the subscription is priced by quote. Vault Community is free to use and gives you the software, but you operate it yourselves: storage, unsealing, upgrades, backups and high availability all fall to your team, and it does not come with the managed service.
Before comparing costs, confirm two things with your architecture and compliance owners. First, is data location a fixed requirement, meaning secrets must remain in your own cloud accounts, data centers or air-gapped networks? Second, is operating the cluster a fixed requirement, meaning your own staff must hold the unseal, patch and recovery responsibility? If both answers are yes, HCP Vault Dedicated is unlikely to fit, and the open question becomes which self-managed platform you run. If either answer is no, the managed path may remain on the shortlist, and you should ask HashiCorp for written scope and quoted terms covering data residency and support.
Choosing Vault Community does not remove licensing questions. HashiCorp announced on August 10, 2023 that future releases of its products would move to the Business Source License 1.1, and Vault Community releases fall under that change. Your legal team should read the license terms for your intended use, especially if you offer a competing service built on Vault. Teams that want a self-hosted Vault-compatible option under an open-source license can evaluate OpenBao, which is licensed under MPL 2.0, alongside Infisical, which is MIT licensed outside its ee directories.
How to move secrets and syncs before the service stops
This sequence moves each secret, the application that reads it and every sync target from HCP Vault Secrets to a platform you run yourself, and ends with a verified cutover and a retired HCP service. Each step closes with a check you can record for your change file.
Confirm the shutdown date with HashiCorp
Your account owner or HashiCorp support confirms the end-of-life date for your organization in writing, and asks whether any exports or data retrieval options apply to your account. The platform owner records the answer, along with the named contact, in the migration plan. The step is done when the date and the contact are in the plan and someone outside the project team has reviewed them. Ask the vendor to confirm the date as it applies to your contract, because the page only states the latest date that applies to the service in general.
Inventory secrets, consumers and syncs
Export a list of every HCP Vault Secrets app, secret name, environment and consumer, including CI jobs, serverless functions, Kubernetes workloads and any cloud or code platform that receives a synced copy. Mark which consumers read the secret directly and which depend on a sync to a downstream store. Assign an owner to each item. The step is done when every secret has a known owner, a known consumer and a known sync destination, and the list has been checked against the apps your teams confirm are still in use.
Choose the target platform
Decide between self-hosted OpenBao and self-hosted Infisical based on what your consumers need. OpenBao suits teams that want dynamic secrets, lease management and identity-based access under an MPL 2.0 license. Infisical suits teams that want a project dashboard, secret syncs and a Kubernetes operator. Write down the choice, the reasons and the features your inventory requires. The step is done when the decision is signed off by the platform owner and the security lead, and each sync target is confirmed to be supported or to need a separate process.
Deploy the target in your infrastructure
Install the chosen platform in your own cloud account, data center or private network. For OpenBao on Kubernetes, use the OpenBao Helm chart, which requires Helm 3.6 or later. For Infisical, choose among a single Docker container, Docker Compose, the official Helm chart with bundled PostgreSQL and Redis, or the reference deployments, and confirm which enterprise features you need, since SSO and gateways require an enterprise license. The step is done when the platform answers health checks, backups run and access is limited to the named administrators.
Import or re-create secrets
Copy each secret from HCP Vault Secrets into the new platform's structure by project, path or environment. HCP Vault Secrets does not provide a direct bulk export to a new platform in the facts available here, so confirm with HashiCorp what read access your account has before you start. Re-create dynamic credentials and auth roles in the new platform rather than copying static values. Record which items were imported, which were re-created and which were retired. The step is done when a sample of secrets matches the source values and each re-created role works in a test environment.
Cut over consumers
Move applications, CI jobs and workloads to read from the new platform one group at a time, starting with non-production environments. Update endpoints, authentication methods and client libraries, and remove HCP Vault Secrets credentials once a consumer no longer needs them. Keep the old values available for rollback until the owner of each consumer signs off. The step is done when every consumer in the inventory reads from the new platform, the rollback path has been tested in non-production and the old credentials are revoked.
Verify sync targets
For each cloud secret store, code platform or hosting service that previously received a synced copy, either configure the new platform's sync or set up a separate, owned sync process. Compare the destination values with the source after the first run, and confirm that rotation events reach the destination. Confirm the sync capability for each target with the vendor, because the supplied facts do not cover every target. The step is done when every destination shows matching values in a test run and the owner of each sync has accepted the monitoring and alerts.
Retire HCP Vault Secrets
After every consumer and sync is confirmed on the new platform, disable HCP Vault Secrets access tokens, remove remaining apps and record the decommissioning in the change log. Keep an archived copy of the inventory and the cutover evidence for audit and incident review. Ask your compliance lead which retention rules apply to the archive. The step is done when HCP Vault Secrets no longer holds production secrets, no consumer authenticates to it, and the decommissioning record is filed with the platform owner's sign-off.
Choosing OpenBao or Infisical for your team
Platform teams that already run Vault-style policies, auth mounts and dynamic secrets will usually find OpenBao the closer fit. OpenBao is a fork of Vault, so policy design, auth methods and secrets engines will look familiar to operators who know Vault. Its documented auth methods include AppRole for servers, Userpass for developer machines, JWT/OIDC, Kubernetes, LDAP, TLS certificates and login MFA. For high availability, the storage backend matters. Integrated storage (Raft) and PostgreSQL are the officially supported HA backends, and the storage documentation describes PostgreSQL as easier to operate safely than Raft. Since version 2.5.0, Raft standbys can serve read-only operations, and version 2.7.0 extended this to PostgreSQL.
- Auth method mapping: List every auth method your clusters and pipelines use today, then confirm each one in the OpenBao auth methods documentation before you plan cutover.
- Storage backend choice: Pick integrated storage or PostgreSQL based on your team's operating skills, backup tooling and recovery drills.
- Dynamic secrets: Confirm that the database and Kubernetes engines produce the roles and credential lifetimes your applications need.
- Lease and revocation: Test bulk and individual revocation during an exercise, because emergency revocation is a routine task for this team.
- Plugins and engines: Check each plugin you depend on. The migration guide skips mounts that use plugins OpenBao does not ship.
Confirm each item against the OpenBao release you will deploy, and review the release notes before you fix the design.
Application and DevOps teams usually care most about how developers and pipelines get secrets day to day. Infisical organizes secrets in a dashboard per project and environment, so developers can manage values without writing policy. Its documented secret syncs cover GitHub, Vercel and AWS, and its Kubernetes operator delivers secrets to workloads and reloads deployments when values change. An agent can inject secrets into processes without code changes. Infisical also supports secret versioning with point-in-time recovery, rotation and dynamic secrets for PostgreSQL and MySQL. For self-hosting, the documented options are a single Docker container, Docker Compose, an official Helm chart with bundled PostgreSQL and Redis, Linux packages, and AWS or GCP reference deployments.
- Project dashboard: Map each application and environment to a project, then decide who may read production values and who may only read staging.
- Secret syncs: Confirm the sync targets and sync direction you need, and test failure handling for each one.
- Kubernetes operator: Test how deployments reload after a secret changes, and set rollout expectations with application owners.
- Machine identities: Confirm that your clusters, CI runners and cloud accounts can authenticate with Kubernetes, AWS, GCP, Azure, OIDC or Universal Auth.
- Database choice: Decide whether to use the bundled PostgreSQL and Redis from the Helm chart or external services that your database team already operates.
Check the sync targets, the self-hosting topology and whether you need SSO or gateways. Infisical's self-hosting documentation says those features require an enterprise license, so get that scope in writing before you design around them.
Regulated teams often decide on license and governance before they compare features. OpenBao is licensed under MPL-2.0, is run by a community under open-governance principles, and is a Sandbox project of the Open Source Security Foundation under Linux Foundation stewardship. Infisical's repository is MIT licensed except for content in any ee directory, which falls under the separate license in ee/LICENSE. Vault itself moved future releases to the Business Source License 1.1 in August 2023, so many teams are now asking how license terms may change. Your counsel should review which files and features your deployment uses, because the license split determines what you can run and modify.
- License scope: Ask counsel to map each feature you plan to use to its license, including anything inside an ee directory for Infisical.
- Enterprise features: Get written confirmation of any enterprise license needed for SSO, gateways or other controls before design sign-off.
- Project maturity: Review OpenBao's Sandbox status and the support options available to you, and record the result in your risk register.
- Access evidence: Infisical documents RBAC, temporary access, access requests and approval workflows. Confirm that the features you rely on are included in your licensed tier.
- Assessment roles: Auditors and certification bodies decide whether controls meet a framework. DeployOpen prepares the systems, controls and evidence for that assessment.
Confirm the license files, the enterprise feature list and the support commitments with each vendor and your legal team before you select a platform.
Evidence to keep during the cutover
A reviewer will ask whether every secret moved, who approved the move, and whether access on both sides can be traced and reversed. The cards below cover the records that answer those questions, and they tie together because each one depends on the inventory being complete.
Signed inventory of secrets and syncs
List every HCP Vault Secrets app, secret, integration and sync target, with its owner, consuming workload and destination. Ask the owner of each item to sign off that the list is complete, since a secret missing from the inventory is the one most likely to break after shutdown. Record which items are moved, rebuilt as dynamic credentials, or retired. Treat an unlisted sync as an open risk until someone confirms its destination.
Cutover plan and approvals
Write the order of moves, the rollback step for each application, and the named approvers for production changes. Keep the change tickets, the approval timestamps and the decision to pause if a consumer fails. A reviewer will compare the plan with what actually happened, so note any deviation and who accepted it.
Access logs from both platforms
Export the HCP audit history before the service stops and keep the equivalent audit device logs from the new store, such as OpenBao audit devices or Infisical audit logs. Retain them under your own retention policy, not the vendor's. Confirm with the vendor what HCP logs are available at shutdown and in what format, because a gap here is hard to reconstruct later.
Proof that HCP access was revoked
Capture evidence that every HCP service principal, user, token and CI credential that could read secrets has been deleted or disabled, with the date and the operator. Record a test showing a revoked credential is refused. Include integrations with GitHub, cloud accounts and Vercel, since those hold copies of tokens that also need rotating.
Backup and restore tests for the new store
Keep the results of a restore test for the new store, run on a copy and not on production. Record which backup was restored, how long it took, and whether applications could read the secrets afterward. For OpenBao, document the unseal and recovery key custody. For Infisical, document the database and encryption key backups. Without a passed restore test, the migration is not yet complete.
What do teams ask before moving off HCP Vault Secrets?
What does moving off HCP Vault Secrets cost, and which parts drive it?
The cost has three layers: what you pay the platform vendor today, what you pay for infrastructure and operations after the move, and what you pay for the migration itself. Self-hosted costs include compute and storage for the secrets platform, high availability nodes, load balancing and backups, and a key source for auto-unseal if you use one. Staff time recurs for upgrades, monitoring, access reviews and incident response. The one-time part is the migration project: inventory, integrations, re-pointing workloads and documentation. Costs rise with the number of secret stores, sync targets, environments and regions. HashiCorp prices its managed and Enterprise products by quote (see HashiCorp Vault pricing), so compare your current invoice with a self-hosted estimate built from your own infrastructure rates. Ask any implementation partner for a quote based on a written scope, and ask them to separate one-time and recurring items.
How long does a migration off HCP Vault Secrets take?
The timeline depends on how much your organization has connected to the service, not on the platform alone. The main drivers are the number of secrets and projects, the number of applications, pipelines and cloud syncs that read them, the auth methods in use, and how many teams must approve changes. Each consumer needs a test window and a rollback plan. HCP Vault Secrets is no longer sold and reaches end of life by July 1, 2026 at the latest, so the deadline is fixed even if the project is not. Check your account notices for the exact shutdown date that applies to you and confirm it with HashiCorp. Build your plan backward from that date, and leave time for change freezes and holidays. A fixed-scope agreement sets the timeline in writing before work starts.
What does the migration need from our own team?
The work needs named people from several groups, and it needs them early. Platform or infrastructure engineers operate the new cluster or service. Application owners confirm which secrets their services read and how they are loaded. Security staff define access policies, approval paths and audit requirements. Cloud and CI/CD owners handle the places where secrets are synced or injected. Start with an inventory: every secret, its owner, its consumers, its rotation method and its sync targets. Expect the team to schedule change windows and to test each consumer after it is re-pointed. After the move, someone must own upgrades, backups, unseal procedures and access reviews, or the platform will drift. Decide that owner before the project begins.
Can our own engineers do the move without an implementation partner?
Yes, if your engineers already run secrets infrastructure in production and have time for a staged project. The work is well documented for the open-source options. OpenBao publishes installation guidance for Kubernetes through its Helm chart, which requires Helm 3.6 or later, and it documents high availability, storage backends and auth methods. The harder parts are design decisions and testing: choosing storage and high availability, setting up unseal and key custody, mapping access policies, moving dynamic secret configurations and proving backup restores work. Ask whether your team has done a restore test, a rotation drill and a failover test before. If the answer is no for any of them, the gap is the reason to bring in outside help, either for a fixed-scope project or for a retainer covering ongoing support and upgrades.
Is OpenBao or Infisical the better fit after HCP Vault Secrets?
The better fit depends on what your teams use the secrets for. OpenBao is a community fork of Vault under MPL 2.0, managed under the Linux Foundation's OpenSSF. It provides encrypted key/value storage, dynamic secrets for systems such as Kubernetes and SQL databases, encryption as a service, leasing with revocation, and many auth methods, including AppRole, JWT/OIDC, Kubernetes and LDAP. It suits teams that want Vault-style policies and engines. Infisical's repository is MIT licensed outside its ee directories, and it offers a project and environment dashboard, secret syncs to platforms such as GitHub, Vercel and AWS, a Kubernetes operator, and PKI and key management. Its self-hosting documentation notes that SSO and gateways require an enterprise license. Map your current use cases against both before choosing, and test the one that matches most of them.
Is HCP Vault Secrets still running, and what should we do now?
HCP Vault Secrets is no longer sold, and it reaches end of life by July 1, 2026 at the latest. Treat that date as the outer limit, not the target. Start by confirming your account's shutdown date with HashiCorp and recording every secret, sync and integration that depends on the service. Export or inventory the secrets through the service's own interfaces, and store them under your existing controls while you plan the destination. Do not let applications keep reading from the service while the new platform is being built without a rollback path. HashiCorp suggests two paths, HCP Vault Dedicated or Vault Community. Those keep you within HashiCorp's ecosystem, so compare them with OpenBao or Infisical on license, hosting location and operating model before you commit.
What does a fixed-scope engagement cover?
A fixed-scope engagement covers the work listed in a written scope, with agreed deliverables and a timeline set before work starts. For a secrets migration, typical items include the design of the self-hosted platform, installation in your own cloud account, data center or air-gapped network, integration with identity providers and workloads, hardening, backup and restore setup, migration of agreed secrets and policies, and documentation. DeployOpen also prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports or certifications. Ongoing support, upgrades and continuous testing are available as retainers after the project. DeployOpen does not publish a price list. Request a quote built from your written scope, and check that it names the systems in scope, the exclusions and the handover.
How DeployOpen plans and deploys this migration
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For HCP Vault Secrets end of life, we start with an inventory of the secrets, syncs and workloads that depend on the service, then agree the scope in writing before any work begins.
How we scope
- We inventory every HCP Vault Secrets project, app, environment and sync target before choosing OpenBao or Infisical.
- We map each secret type to a target design, noting where dynamic secrets or syncs need extra work.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
- We state which items are out of scope, such as applications you own and rewrite yourselves.
How we build
- We deploy the chosen platform in your infrastructure, with storage, high availability and unseal design documented for your environment.
- We migrate secrets in controlled batches, verifying each one against its source before retiring it.
- We re-point applications, CI jobs and Kubernetes workloads to the new endpoints, using staged cutovers and rollback steps.
- We test access policies, authentication methods and audit logging against the requirements agreed in scope.
How we hand over
- You receive runbooks covering deployment, backup and restore, unseal procedures, upgrades and access reviews.
- We document the mapping from HCP Vault Secrets projects and policies to the new access model, with open items listed.
- We run a handover session with your platform and security teams and confirm which deliverables you accept.
- We provide evidence on configuration and controls that your auditors can review, while they make their own assessments.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- We can plan version upgrades of OpenBao or Infisical against the release notes and migration guidance for each release.
- We can schedule periodic security testing of the deployed platform and its integrations, scoped in writing.
- Quotes follow from the written scope, so you can compare options with a clear list of deliverables.
