Infisical vs OpenBao

Infisical and OpenBao both keep application secrets such as database passwords, API keys and certificates out of .env files and git, and hand them to the services that need them. Both are self-hostable and both run in Docker. They are built for different users. Infisical is a secrets dashboard for developers: projects, environments, a web editor, a CLI that injects secrets into a process, and syncs out to GitHub, Vercel or AWS. OpenBao is the community fork of HashiCorp Vault: an API-first secrets engine with path policies, leases and credentials it generates on demand, run as a sealed service.

Two models of a secrets manager

Infisical organises secrets by project and environment, such as development, staging and production, and you edit them in a dashboard. Applications get them through the Infisical CLI ("injecting secrets into local development and CI/CD pipelines"), the Infisical Agent, SDKs for Node, Python, Go, Ruby, Java and .NET, or a Kubernetes Operator that can "automatically reload deployments". Secret Syncs push values out to platforms like GitHub, Vercel and AWS Secrets Manager. Around that core, the same app also includes certificate management (an internal CA and ACME enrolment), a key management service and privileged access management.

OpenBao is "an identity-based secrets and encryption management system". Every client authenticates through an auth method, such as AppRole, Kubernetes, JWT/OIDC, LDAP, userpass or TLS certificates, and gets a token tied to path-based policies. Secrets live in secrets engines mounted at paths: KV for static values, engines that manage credentials for databases, Kubernetes, LDAP and RabbitMQ, a PKI engine, SSH, TOTP, and transit, which encrypts and decrypts data for your apps "without storing it". Dynamic credentials carry a lease, and OpenBao "will automatically revoke that secret" when the lease ends.

In practice, Infisical is easier for a team that wants one place to edit DATABASE_URL for three environments and have CI pick it up. OpenBao suits a setup where machines authenticate on their own, get short-lived credentials, and every access is a policy decision.

Licences and what is free

OpenBao is MPL-2.0. Its site calls it a "fork of Vault managed by the Linux Foundation's OpenSSF". Vault itself is under the Business Source License from version 1.15.0 on. We found no paid tier or licence key in OpenBao's docs. The 2.7.0 docs include namespaces for "secure multi-tenancy … within a single OpenBao instance".

Infisical is MIT at its core, with the code in its ee/ directories under a separate enterprise licence. Its self-hosting docs say "most features in Infisical are free to use, others are paid and require purchasing an enterprise license", and name SSO and gateways as examples. A self-hosted instance unlocks them with a LICENSE_KEY. Infisical's pricing page does not separate cloud from self-hosted, but it lists these as paid: secret versioning and point-in-time recovery, secret rotation, dynamic secrets, SAML SSO, custom roles and approval workflows. Check which of those you need before you choose.

The operational difference: sealing

OpenBao starts sealed every time it starts. Its data is encrypted, and until an operator supplies the unseal key shares, "almost no operations are possible". The default is a Shamir seal: the key is split into shares, and a threshold of them must be entered after every restart. The docs say this "makes the process of automating an OpenBao install difficult" and recommend auto unseal for most users. Seal options in the 2.7.0 docs include AWS KMS, Azure Key Vault, Google Cloud KMS, OCI KMS, a transit seal backed by another OpenBao, PKCS#11, KMIP and a static key. Auto unseal ties OpenBao's availability to that service. The docs warn that recovery keys "are not sufficient to unseal OpenBao if the Auto Unseal mechanism isn't working". Our install snippet uses a single key share and plain HTTP to keep a first test simple. Use TLS and a real share scheme or an auto-unseal before you put anything that matters in it.

Infisical does not seal. Secrets are encrypted in PostgreSQL with the ENCRYPTION_KEY from .env. Its Docker guide says "Without this key, you cannot decrypt secrets even if you restore the database". Back up the key separately from the pg_data volume. The first account to sign up "becomes the instance administrator", so create it before anyone else can reach the URL.

Footprint and setup

Infisical is three containers from upstream's docker-compose.prod.yml: the app, PostgreSQL 14 and Redis. You fill in ENCRYPTION_KEY, AUTH_SECRET and SITE_URL, then start it. The Compose file uses the latest image with the comment "PIN THIS TO A SPECIFIC TAG", which is worth doing. The docs say "Never expose PostgreSQL (5432) or Redis (6379) ports to the public internet". Upstream sizing says an instance "typically doesn't need more than 2–4 CPU cores and 4–8 GB of memory", with PostgreSQL 14 or later (most tested on 16) and Redis 6.2 or later.

OpenBao is one Go binary. Our snippet runs the official image with integrated Raft storage on a volume and the web UI on port 8200. Raft replicates data across nodes when you grow to a cluster, and PostgreSQL is also supported as storage. OpenBao publishes no RAM figure. Our 256 MB is an estimate.

Both installs have been tested on this site on Ubuntu 26.04. Idle after first start on our GCP e2-standard-2 test box, Infisical used ~1.4 GB of RAM and OpenBao used ~20 MB. We rate Infisical 2 out of 5 to deploy and OpenBao 3 out of 5. The extra point is for unsealing, policies and TLS, which you have to understand before OpenBao is useful.

Coming from Vault

OpenBao's in-place migration guide says its API "should be compatible with Vault to the extent that existing clients should not even register a difference". That guide was tested only from Vault Community Edition 1.14.1 to OpenBao 2.2.0, on Raft storage with a Shamir seal. It adds that "OpenBao makes no guarantees about storage compatibility with Vault" for newer Vault versions. Mounts that use plugins OpenBao does not ship need checking first. If you already run Vault CE and want to stay on an open-source licence, OpenBao is the direct path. Infisical would be a migration to a different model.

Which to choose

Choose Infisical if developers are the main users: a web dashboard with environments, a CLI that injects secrets into local runs and CI, syncs to GitHub or Vercel, and a Kubernetes operator. The install is three containers with no unseal step. Check the paid list first if you need rotation, dynamic secrets, versioning or SAML.

Choose OpenBao if machines are the main users. It fits when you want short-lived database or Kubernetes credentials, encryption as a service, fine-grained policies, and namespaces, all under MPL-2.0 with nothing paid, or when you are leaving Vault. Plan for TLS and for how the server will be unsealed after a reboot.

Choosing between OpenBao and Infisical

Starting from OpenBao, the usual reason to move is people. Developers want to edit secrets per environment in a UI, not write policies. Starting from Infisical, the usual reason to move is a feature on Infisical's paid list, or the need for leased, auto-revoked credentials without a licence. For passwords that people use to log in, see Vaultwarden instead. Both tools here manage secrets for applications.