# HCP Vault Secrets is gone: choosing where to move > HCP Vault Secrets reached end of life on July 1, 2026. HashiCorp's suggested paths, what Vault Community lacks, and how the alternatives differ on who decrypts. URL: https://crunu.com/blog/hcp-vault-secrets-shutdown-where-next Language: en Updated: 2026-10-30 HCP Vault Secrets is no longer available. IBM's support notice set its end of sale on June 30, 2025 and its end of life at the earlier of the Flex contract expiry or July 1, 2026, when "HCP Vault Secrets applications will be deleted." HashiCorp's suggested replacements are HCP Vault Dedicated, a hosted Vault Enterprise, and self-managed Vault Community. Beyond those, the options include a cloud provider's secret manager, a hosted secrets platform such as Doppler or Infisical, the Vault fork OpenBao, or a vault that decrypts only on clients, such as Bitwarden Secrets Manager, Phase in its default mode, or Crunu. The most useful way to choose between them is to ask two questions: who can decrypt your values, and what will you have to run. This post covers the timeline, HashiCorp's own paths, a comparison of the alternatives on those two questions, and where a product like Crunu doesn't fit. If you are still reading about options in general, the guide on [choosing a secrets manager for a small team](https://crunu.com/guides/best-secrets-managers-small-teams) is broader. ## What happened and when IBM's support page, last modified March 16, 2026, says that "HashiCorp will be decommissioning HCP Vault Secrets" and encourages current users to migrate to HCP Vault Dedicated ([IBM: HCP Vault Secrets end of life](https://www.ibm.com/support/pages/hcp-vault-secrets-end-life)). The notice gives: - **End of sale: June 30, 2025.** New customers could no longer sign up; existing customers could keep adding secrets until end of life. - **End of life: the earlier of the Flex contract expiry or July 1, 2026.** At that point applications are deleted and support ends. - **Suggested alternatives:** HCP Vault Dedicated or Vault Community edition. The surrounding tools followed. HashiCorp's product documentation for Vault Secrets now redirects to the HCP Vault Dedicated pages. If you are reading this after the deadline with some workloads still pointing at the old service, those workloads stopped receiving values when the applications were deleted. ## HashiCorp's two paths **HCP Vault Dedicated** is, in HashiCorp's words, "a hosted version of Vault Enterprise operated by Hashicorp on your behalf," using "the same binary as self-hosted Vault Enterprise" ([HashiCorp: HCP Vault Dedicated](https://developer.hashicorp.com/vault/cloud)). You get the full Vault feature set without running clusters. You also take on Vault's model: secrets engines, policies, auth methods and namespaces, which is more to learn than a simple key-value service. **Vault Community** is the free, self-managed edition. You run it, unseal it, upgrade it and back it up. Two features you may have relied on in a hosted product are not part of it: - **Secrets sync**, which pushes values to destinations such as AWS Secrets Manager, GitHub Actions and Vercel, needs an "appropriate Vault Enterprise license or HCP Vault Dedicated cluster" ([Vault: secrets sync](https://developer.hashicorp.com/vault/docs/sync)). - **Namespaces**, Vault's way of isolating teams or tenants, carry the same requirement ([Vault: namespaces](https://developer.hashicorp.com/vault/docs/enterprise/namespaces)). Both paths keep the same encryption model: the Vault server decrypts values to answer requests. *Figure: Diagram of who can decrypt HashiCorp Vault values, split into your side and the provider side. On your side, your team’s devices, your machines, and CI runners can decrypt. On the provider side, the HashiCorp Vault server holds the key and can decrypt values too.* ## Two questions that sort the alternatives Feature lists for secrets managers are long and similar. Two questions separate them more clearly. **Who can decrypt your values?** Some services decrypt on their own servers before responding. AWS Secrets Manager, for example, "decrypts the secret value before returning it to the caller" ([AWS: secret encryption and decryption](https://docs.aws.amazon.com/secretsmanager/latest/userguide/security-encryption.html)). Doppler's web servers pass secrets to an internal tokenization service that "encrypts all secrets with AES-GCM using a random IV and the workplace's unique 256-bit key" ([Doppler security fact sheet](https://docs.doppler.com/docs/security-fact-sheet)). Infisical's server "retrieves and decrypts requested data from the storage backend" before responding ([Infisical: security](https://infisical.com/docs/internals/security)). Others decrypt only on the clients that hold keys. **What do you operate?** A hosted service means nothing to run but a vendor to trust. A self-managed server means you own uptime, upgrades, unsealing and backups. | Option | Who can decrypt | What you run | | ----------------------------------------- | ------------------------------------------- | ------------------------------------------------------------------- | | HCP Vault Dedicated | The Vault service, operated by HashiCorp | Nothing; HashiCorp runs the cluster | | Vault Community or OpenBao | Your own Vault or OpenBao server | Servers, unsealing, upgrades, backups | | AWS, Google Cloud or Azure secret manager | The cloud service, under your IAM policies | Nothing beyond IAM setup | | Doppler | Doppler's service | Nothing | | Infisical Cloud or self-hosted | The Infisical server | Nothing, or your own instance | | Crunu | Only your browsers, machines and CI runners | Nothing on app.crunu.com, or your own server on the Enterprise plan | OpenBao describes itself as "an open source, community-driven secrets manager and fork of Vault managed by the Linux Foundation's OpenSSF" ([OpenBao](https://openbao.org/)). It keeps Vault's model under an open-source license, with the same operational load as Vault Community. The [who can decrypt your secrets](https://crunu.com/guides/who-can-decrypt-your-secrets) guide goes through each vendor in more depth, and the [HashiCorp Vault vs AWS Secrets Manager](https://crunu.com/compare/hashicorp-vault-vs-aws-secrets-manager) comparison covers the two most common landing spots. ## A third question: how would you leave? This migration exists because a hosted product was retired. Whatever you pick next, check the exit before you commit: how you would get every value and its history out, in what format, and how long that would take with the vendor's tools alone. A service with a documented export, or an open format you can read without the service, turns the next shutdown notice into a project instead of an emergency. For comparison, Crunu offers two exits. Any member can download an offline copy of the environments they can read, except ones restricted to certain networks, and open it with their password and Secret Key without a server. And a self-hosted server, available on the Enterprise plan, moves between Docker, Cloudflare Workers, Vercel and Google Cloud Run with one archive that contains no plaintext values. ## Matching the option to what you used it for How you used HCP Vault Secrets narrows the choice quickly. - **You synced values into platforms** such as Vercel, GitHub Actions or a cloud secret store. Look at HCP Vault Dedicated, Doppler or Infisical, which have built-in syncs. Vault Community and Crunu don't. - **You fetched values at runtime from inside one cloud.** That cloud's own secret manager is the least new infrastructure, with access through the IAM you already manage. - **You mostly kept `.env`-style values for a team and a handful of servers.** A team vault without servers to run, hosted or self-hosted, fits; the choice is whether you accept a service that can decrypt. - **You want dynamic database or cloud credentials.** That is Vault's strength: HCP Vault Dedicated, Vault Community or OpenBao. ## Where Crunu fits, and where it doesn't Crunu is a team vault for environment variables and secrets where encryption happens only in the browser and in the `crunu` agent. The server, whether the cloud service at app.crunu.com or one you host on Docker, Cloudflare Workers, Vercel or Google Cloud Run on the Enterprise plan, stores ciphertext and metadata such as names and email addresses, and can't decrypt a single value. Each environment, such as `payments-api / production`, has its own key, sealed to each person and machine with access. *Figure: Priya Natarajan dragged the .aws folder from her computer onto the payments-api production environment. Crunu recognized two files and proposes where each one goes: \~/.aws/config, marked as able to run commands, and \~/.aws/credentials. Only field names such as aws_access_key_id are listed; values are not shown. The cursor rests on Add (2).* Moving in is a matter of files. Crunu has no importer for Vault or other vendors, so you export values to `.env`, INI or YAML files and drag them, or whole folders, onto an environment; Crunu shows the variable names it found and where each file belongs. Servers then get values through the agent, for example `crunu run --env payments-api/production -- /opt/payments/bin/server`, and CI through a service token bound to the repository and branch with OIDC. The same design rules some things out, and you should know them before you choose: - **No dynamic secrets.** Generating credentials on demand needs a key on the server, which Crunu doesn't have by design. If you rely on Vault's database or cloud engines, stay with a Vault-based option. - **No built-in sync to other platforms.** Pushing values into Vercel or Cloudflare is a recipe you run in CI with `crunu run`, not a managed integration. - **No SSO, SCIM or Kubernetes operator.** People sign in with a password, a Secret Key and an optional second factor. If those are deal-breakers, the table above has better fits. If your use of HCP Vault Secrets was mostly "a safe place for the team's environment variables", the [Crunu vs HashiCorp Vault](https://crunu.com/alternatives/hashicorp-vault) page compares the two models in detail. ## A migration checklist - [ ] List every application, its secrets and every consumer: services, CI jobs, platforms they synced to - [ ] Decide per consumer: runtime fetch, CI injection or platform sync - [ ] Pick the target by who decrypts and what you'll operate - [ ] Move values and switch consumers one service at a time - [ ] Reissue any value that was copied into chat, tickets or laptops during the move - [ ] Remove old credentials and tokens that pointed at the retired service ## Sources - [HCP Vault Secrets end of life, IBM Support](https://www.ibm.com/support/pages/hcp-vault-secrets-end-life), checked October 30, 2026. - [HCP Vault Dedicated, HashiCorp Developer](https://developer.hashicorp.com/vault/cloud), checked October 30, 2026. - [Secrets sync, Vault documentation](https://developer.hashicorp.com/vault/docs/sync), checked October 30, 2026. - [Namespaces, Vault documentation](https://developer.hashicorp.com/vault/docs/enterprise/namespaces), checked October 30, 2026. - [Secret encryption and decryption in AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/security-encryption.html), checked October 30, 2026. - [Security fact sheet, Doppler documentation](https://docs.doppler.com/docs/security-fact-sheet), checked October 30, 2026. - [Security, Infisical documentation](https://infisical.com/docs/internals/security), checked October 30, 2026. - [OpenBao](https://openbao.org/), checked October 30, 2026.