Infisical vs HashiCorp Vault: ops, license, encryption

Infisical and HashiCorp Vault solve the same core problem in the same basic way: a server you can run yourself stores encrypted secrets, decrypts them when an authorized client asks, and controls access with policies and machine identities. The differences are in focus, license and how much there is to operate. Infisical is an MIT-licensed application built around projects, environments and syncs for application teams, with separate products for certificates and key management. Vault is a security platform under the Business Source License, built around secrets engines and auth methods, with a seal that someone has to manage.

If your secrets are mostly app configuration and API keys, Infisical has less to set up. If you depend on Vault's secrets engines and policies, the extra operations are the price.

Who each one fits

Infisical fits product and platform teams that want projects, environments, secret versioning and syncs into GitHub, Vercel, AWS and other services, with a web app built around them. It runs as Infisical Cloud or self-hosted, from a single packaged container to a high availability cluster. Pricing counts identities: in Infisical's words, "an identity is any human or machine that authenticates to Infisical".

HashiCorp Vault fits organizations that want one platform for secrets, certificates, encryption and identity across many clouds and data centers, and have people to run it. HashiCorp is an IBM company. Vault Community edition is self-managed and free to run under its license; Vault Enterprise adds namespaces, replication and secrets sync, self-managed or as HCP Vault Dedicated.

What you operate

Infisical's self-hosting guide starts with "a single packaged container", and a Docker Compose template that runs Infisical with PostgreSQL and Redis. The root encryption key is an environment variable you provide, and it "never leaves the server's memory". Reading data takes both that key and the storage backend, so the variable needs the same care as the database.

Vault takes more care. A Vault server starts sealed and cannot decrypt anything until it is unsealed. In the default configuration, operators enter a threshold of key shares, and each node in a cluster must be unsealed separately after a restart. HashiCorp's documentation calls that "a manual process" and recommends auto unseal through a cloud KMS for most users; Community edition supports cloud KMS auto unseal, and HSM auto unseal is an Enterprise feature. Community edition also lacks namespaces, performance and disaster recovery replication, and secrets sync.

Who can decrypt

Neither product keeps the server from reading values, and both say so. Infisical: "Before responding to a client request, the server securely retrieves and decrypts requested data from the storage backend." Its layered keys mean that "compromising the database alone is insufficient to decrypt sensitive data", but the running server holds the root key.

Vault: "Once Vault retrieves the encryption key, it decrypts the data in the storage backend, and enters the unsealed state." From then on, the server returns plaintext to any client whose policy allows it.

For both, your server's operators and anyone who controls the running process are inside the trust boundary of every secret. Self-hosting changes who those people are, not the model.

Licensing

Infisical's repository is MIT outside its ee/ directories, and the code there has its own license, so some features need a paid plan even when you self-host. Vault moved to the Business Source License 1.1 with version 1.15: production use is allowed except for competing hosted offerings, and each version converts to the Mozilla Public License 2.0 four years after release. Teams that need an open-source Vault can look at OpenBao, which describes itself as "an open source, community-driven secrets manager and fork of Vault managed by the Linux Foundation's OpenSSF".

Where Infisical is stronger

• Less to run. One container to start, no seal to manage, and a web app organized by project and environment.
• Built for app environments. Projects, environments and syncs to GitHub, Vercel, AWS and other services come first, rather than paths and secrets engines.
• MIT core. Most of the code is under a permissive open-source license.
• Syncs on every plan. Secret Syncs start at 10 on the Free plan and are unlimited on Enterprise, rather than reserved for an Enterprise license.

Where Vault is stronger

• Secrets engines in one server. Database and cloud credentials, PKI, transit encryption and response wrapping, with JWT/OIDC among many auth methods.
• Dynamic secrets in Community. Database and cloud credentials created on demand, without a paid plan.
• Kubernetes options. A Helm chart, the Vault Secrets Operator, a CSI provider and the Agent Injector.
• Enterprise depth. Namespaces, performance and disaster recovery replication, and SCIM in Vault Enterprise 2.x.

A third option: Crunu

Crunu, which wrote this page, removes the decrypting server from the picture. Values are encrypted in the browser and the crunu agent, and the server stores only ciphertext, public keys and signed documents; there is no root key to protect and no seal to manage. Each environment has its own key, sealed to each person, machine and pipeline, and removing someone rotates the keys of every environment they could read. You can use the Crunu cloud or, on the Enterprise plan, host the server yourself on Docker, Cloudflare Workers, Vercel or Google Cloud Run, and move it between them with one archive. It is free during early access. The server still sees metadata such as names, email addresses and timestamps, as the limitations page explains.

Crunu is not a fit if you need dynamic secrets, PKI, encryption as a service, syncs to other platforms, a Kubernetes operator or SSO; it has none of these, and its source code is not published. The full comparisons are Crunu vs Infisical and Crunu vs HashiCorp Vault. The guide to self-hosting a secrets vault covers what each option asks you to run.