Self-hosted secrets manager: options and trade-offs

Self-host a secrets vault when you need to control where the data and its keys live, not because it sounds safer by default. The real cost of self-hosting is what you operate afterwards: the database, the keys that open it, unsealing after restarts, upgrades, backups and restores, and the people who have root on the server. The most important difference between the options is who can decrypt. A server-side vault such as HashiCorp Vault, OpenBao or Infisical decrypts on the server, so self-hosting moves that power from a vendor to whoever controls your server. A blind-server design, such as Bitwarden Secrets Manager, Crunu or Phase in its default mode, keeps keys on your devices, so a compromised server still holds only ciphertext, but it can't sync values to other platforms or generate credentials on demand. This guide compares six options by what you would actually run.

If you have already chosen Crunu and want to pick a platform for it, read Workers, Vercel or Cloud Run: where to host a vault instead. This page is about the choice before that one.

Do you need to self-host at all?

Good reasons usually come from outside the engineering team:

• Where data may live. A regulator, a customer contract or an internal policy requires secrets and their metadata to stay in your own infrastructure or region.
• No third party in the chain. You don't want a vendor's staff, subprocessors or cloud account anywhere in the path to your secrets.
• Isolated networks. Systems that can't reach the internet need a vault they can reach.
• Vendor risk. Hosted products end. HCP Vault Secrets stopped selling to new customers on June 30, 2025, and reached end of life on July 1, 2026 or at the end of a customer's contract, whichever came first, per IBM's end-of-life notice. EnvKey Cloud shut down on February 1, 2025, according to the EnvKey README.

Weaker reasons deserve a second look. "We don't trust the vendor with plaintext" can also be solved by a managed service that encrypts on your devices, which you don't have to run. "It will be cheaper" is true for licenses and can be false once on-call time is counted. And "it will be more secure" holds only if your operations are better than the vendor's, which for a small team is a real question.

Self-hosting also doesn't change what the vault's server can see by design. If the product decrypts on the server, it still does; you have only changed whose server it is.

The question that matters most: who holds the key

Every vault encrypts data at rest. The difference is where the key that decrypts it lives while the system runs.

Server-side decryption. The server holds a root key in memory, decrypts stored data and returns values over TLS. This is what lets it rotate database passwords for you, issue short-lived credentials, push values into other platforms and answer a plain HTTP request with a value. It also means that whoever controls the running server, its memory or its root key can read everything.

Client-side decryption. Values are encrypted on people's devices and on machines that use them, and the server stores ciphertext and wrapped keys it can't open. A stolen database or a compromised server yields no values. The price is that the server can't act on values: no syncs it performs itself, no credentials it generates, no rotation it runs on your behalf.

Neither is wrong. Pick based on which property you need more: a server that can work with values, or a server that can't read them. Who can decrypt your secrets applies the same question to 18 products, managed and self-hosted.

The options at a glance

And one option that isn't a server: SOPS or a similar tool, with encrypted files in Git and keys held by people and CI. There is nothing to host, and the trade-offs are those of files: key distribution and history. How to share .env files with your team covers that path.

What you actually operate

HashiCorp Vault and OpenBao

Vault has the broadest feature set of the options here, and the most to operate. OpenBao is a fork of Vault, described on its site as a community-driven secrets manager managed by the Linux Foundation's OpenSSF, so the operational picture below applies to both.

Sealing. A Vault server starts sealed: it can read its storage but can't decrypt anything, per the seal documentation. With the default Shamir seal, operators enter a threshold of key shares to reconstruct the unseal key, by hand, after every restart. With auto-unseal, Vault asks a KMS or HSM to decrypt its root key at startup and hands operators recovery keys instead. Either way you are designing a process: who holds shares, how they are reached at 3 a.m., and what the KMS dependency means for an outage in your cloud.

Storage. With integrated storage, every node in the cluster keeps a replicated copy of the data, kept in step by the Raft consensus algorithm, per the integrated storage documentation. That removes a separate database but makes the Vault nodes themselves the stateful system you back up and size.

Auditing. Auditing is disabled when a cluster is initialized. Once you enable audit devices, Vault refuses to serve a request it can't log to at least one of them, so if every audit device is unavailable, Vault is effectively unavailable too, per the audit documentation. That is a sound design for evidence, and a new failure mode for your on-call rotation. By default, Vault writes an HMAC-SHA256 hash of most string values to audit logs rather than the values.

License. Vault 1.15 and later is under the Business Source License 1.1. Running it for internal purposes within an organization is not considered a competitive offering, and each version converts to MPL 2.0 four years after release.

What you get for that work is real. The database secrets engine, for example, generates database credentials on demand from configured roles, so every service connects with its own credentials, and they become invalid within a reasonable time after their lease expires. If you need credentials generated on demand without a paid plan, Vault Community and OpenBao are the options here; Infisical offers dynamic secrets on its Advanced plan, and Phase offers them for AWS IAM on Enterprise. Running Vault Community for a small team looks at what that takes in practice.

Infisical

Infisical runs as an application with PostgreSQL and Redis. Its self-hosting overview lists a standalone container, Docker Compose with PostgreSQL and Redis bundled, a Helm chart for Kubernetes, a Linux package, and reference setups for AWS and Google Cloud.

Encryption happens on the server. Per Infisical's security documentation, the root encryption key is a 256-bit AES key provided by the operator as an environment variable, or sourced from an HSM, and it never leaves the server's memory while running. Each organization and project has its own data key, and before responding to a request the server retrieves and decrypts the requested data. The same page notes that compromising the database alone isn't enough to decrypt data.

For an operator, that root key is the crown jewel. It sits in the server's environment, in your deployment tooling and in your backups of configuration. Plan who can read it, and keep it separate from database backups. In return you get a web app with integrations, secret syncs to other platforms, and dynamic secrets on its paid plans.

Bitwarden Secrets Manager

Bitwarden decrypts on the client: per its decryption documentation, a machine account's access token carries a key that decrypts the organization key locally, and the secrets are then decrypted with it on the client. For self-hosting, the Bitwarden documentation says Enterprise organizations can self-host Secrets Manager using Docker on Linux and Windows machines, and that it is not supported on the unified self-hosted deployment. A self-hosted instance also needs a license file from a cloud-hosted organization with a Secrets Manager subscription.

Operationally you run the Bitwarden server stack, the same one a self-hosted Bitwarden password manager uses. The key point for this comparison: even on your own hardware, the server stores ciphertext, so a compromise of the host doesn't give away values.

Phase

Phase encrypts end to end by default. Its security page says that in the default mode its servers store only ciphertext and can't decrypt secrets, and that each environment has its own key wrapped to each account's public key. Server-side encryption is a per-app opt-in for third-party syncs or the REST API, and then the environment key is stored encrypted on the server.

Phase's self-hosting guide lists Docker, Docker Compose, Nomad or Kubernetes, requires HTTPS, and gives a minimum of 2 CPU cores, 2 GB of RAM and a 1 GB database volume. It is explicit about responsibilities: self-hosters take sole responsibility for security, availability and reliability, including backups, replication, upgrades and protections such as rate limiting.

Crunu

Crunu's server is blind by design. Values are encrypted in the browser and in the crunu agent, and the server stores ciphertext, public keys and signed documents, plus metadata such as names, email addresses and the audit log. The same holds for the cloud service at app.crunu.com and for a server you run.

Running your own Crunu server is available on the Enterprise plan, under a signed agreement, and the server software is provided as part of that agreement. What you operate is one server with one database schema on any of these:

AWS App Runner is also supported by the deploy scripts, but AWS has closed it to new customers, so for a new AWS account choose one of the platforms above. Of the options in this guide, only Crunu documents running on Cloudflare Workers and Vercel; Infisical documents AWS ECS with Fargate, and Phase documents Railway, among its container platforms.

The day-to-day work is small but not zero:

• Settings. node scripts/server-init.mjs --origin https://vault.company.example creates a .env file with mode 0600 and three new secrets: SERVER_KEY, BOOTSTRAP_TOKEN and CRON_SECRET. Losing SERVER_KEY signs everyone out and breaks share links, but loses no environment data; it can be rotated without losses.
• One address, chosen once. Sign-in signatures, share links, passkeys and enrolled agents are tied to the server address. Moving platforms keeps the address and changes DNS.
• Migrations. The server applies them at startup, and they only add, so rolling back the code never needs a database rollback.
• Health. node scripts/doctor.mjs https://vault.company.example checks TLS, security headers, the server clock, migrations, cleanup and the client address behind your proxy.
• Moving. crunu-server export writes the whole database to one archive without plaintext values, and import loads it on another platform.

What you don't get is also clear: no dynamic secrets, no built-in sync to other platforms, and no rotation of values at providers, because each would need a key on the server. Self-hosting is also limited to the Enterprise plan. See Self-hosting Crunu for how it works and the self-hosting documentation for every setting.

Backups: the data and what opens it

Every vault backup has two halves, and the rule for all of them is the same: never store the two halves together.

For server-side vaults, the second column is the whole security of the backup. A database dump stored next to the root key is a plaintext copy of every secret.

For blind-server designs, the backup itself is less sensitive. A Crunu archive contains ciphertext, public keys, token HMACs, signed documents and metadata, but no values, so it can be stored anywhere reliable. The server's .env is the part to lock away: without SERVER_KEY, a restored server recognizes no session or share link, and together with a database copy it would weaken authenticator-app second factors. Restoring any backup rolls back every change made after it, and in Crunu, agents and browsers then need to reset what they remember of the server's state.

Whatever you run, test a restore before you need one. Backing up a vault without backing up the secrets goes into schedules and restore drills.

What a compromised server can do

It is worth writing down, for your choice, what someone who controls the vault server could do. This is where the two designs differ most.

The last row applies to every vault with a web interface: a page served by a compromised server can capture what you type into it. Crunu's answer is a signed release, a reproducible web build and a local crunu.html file that loads its code from disk and checks the site against the signature. The limitations page lists this and the other risks Crunu doesn't remove.

High availability, without wishful thinking

A secrets vault sits in the startup path of everything that uses it, so its downtime becomes everyone's downtime. Before you commit to an option, find out what its documentation says about running more than one instance, and what happens to clients when the server is unreachable.

• Vault and OpenBao are built to run as clusters: integrated storage keeps a replicated copy of the data on every node. Every node still has to be unsealed after a restart, which is where auto-unseal earns its keep.
• Infisical's documented deployments pair the application with PostgreSQL and Redis, so its availability depends on theirs as well. The Helm chart and the AWS and Google Cloud reference setups are the documented paths.
• Crunu can run several instances against one Postgres database: audit log writes are serialized by a database lock. There is no guide for a failover cluster, so plan it as your own setup. Clients soften outages: a machine's agent keeps serving the last verified state of its environments until its lease ends, 24 hours by default, so a short server outage doesn't stop running services.

Whatever the product, test the failure you fear most: stop the server during a deploy and watch what your applications do.

Leaving later

Plan the exit before you enter. Hosted products end, licenses change, and teams outgrow tools.

With a server-side vault, moving out usually means reading every value in plaintext through the API and writing it somewhere else. That export is the most sensitive file your team will ever produce, so script it, run it on a locked-down machine, and delete it after the import.

With client-side encryption, a move between servers of the same product doesn't need plaintext at all. Crunu's export archive carries ciphertext and signed documents, so you can move from your own Docker host to Cloudflare Workers without decrypting anything on the way. Moving to a different product is another matter: values have to be decrypted on a client and re-entered, because no other product can open the ciphertext.

Day-two checklist for any self-hosted vault

• TLS with automatic renewal, and an alert before certificates expire
• A health check watched from outside your network
• Alerts for failed sign-ins, new devices and configuration changes, routed to someone who reads them
• An upgrade routine, including how schema migrations are applied and rolled back
• Daily backups stored away from the keys that open them, and a restore drill at least once a quarter
• A short list of people with root on the host and access to its settings, reviewed when someone leaves
• A plan for rotating the server's own secrets, such as its root key or session signing key
• Logs that record who did what without recording values

Choosing

Two last questions help when the table leaves a tie. Who in your team will be paged when the vault is down, and do they want to? And when someone leaves, does the product tell you what they could read? The second one is covered in the developer offboarding guide.

Trying Crunu on your own server

Self-hosting Crunu requires the Enterprise plan, and the server files come with the signed agreement. Once you have them, a single Docker host is the shortest path to see what operating a blind-server vault involves:

The Docker guide has the full setup, including Cloudflare Tunnel for a host without open ports, and Move between platforms shows how to leave for Workers, Vercel or Cloud Run later with one archive.