Infisical vs OpenBao vs Vault: Self-Hosted Secrets Management on a VPS (2026)

Every server I run leans on a pile of credentials: database passwords, FTP logins, API keys for Pexels and OpenAI, IndexNow tokens, deploy hooks. Across the seven aggregator sites I keep running on Hostinger shared hosting and VPS boxes — plus 50+ client projects over 11 years — the question of where those secrets live stopped being optional a long time ago. For years I did the lazy thing: .env files, a .secrets/ folder, the occasional credential pasted straight into a cron script. It works until it doesn't, and the day a teammate accidentally commits a production database password to a public repo is the day you start taking secrets management seriously.

In 2026 the self-hosted secrets market has three names that come up in nearly every conversation: Infisical, OpenBao, and HashiCorp Vault. They are not interchangeable. One is a developer-first app you can stand up in an afternoon, one is a community fork carrying the weight of an enterprise-grade engine, and one is the original that triggered a licensing exodus. I have deployed two of the three on real VPS hardware and evaluated the third for a client who needed enterprise compliance, so this is a comparison grounded in what actually happens when you run them, not a feature-grid copied from marketing pages.

The licensing backdrop you cannot ignore

You cannot talk about these three tools without the license story, because it is the reason two of them exist. In August 2023, HashiCorp moved Vault (and Terraform, Consul, and the rest) from the permissive MPL 2.0 to the Business Source License 1.1. The source stays viewable, but commercial use is restricted: you cannot offer a competing managed service, and enterprise features sit behind a paid license. Then in February 2025, IBM closed its $6.4 billion acquisition of HashiCorp, and shortly after, the SaaS-only HCP Vault Secrets product was sunsetted in mid-2025. If you are picking a secrets platform to run for the next five years, those moves matter — they tell you where the roadmap incentives point.

OpenBao is the direct community response. It is a Linux Foundation–hosted fork of the last MPL 2.0 release of Vault, built to keep the Vault security model and API surface available under a genuinely open license. Infisical took the other road entirely: a clean-room, MIT-licensed product that never inherited Vault's architecture at all. So the decision is not just "which is best" — it is "do I want the Vault engine under an open license (OpenBao), a friendlier purpose-built app (Infisical), or the commercial original with vendor backing (Vault)?"

Quick comparison table

Infisical: the developer-experience play

Infisical is what I reach for first when the goal is "stop storing API keys in plaintext" rather than "build a zero-trust secrets architecture for a regulated bank." It is purpose-built for application developers, and it shows. The self-hosted stack is refreshingly boring: PostgreSQL 16 for persistence and Redis for sessions and background jobs. That's it. If you have ever run a Laravel or Node app — which describes most of my client work — you already know how to operate both of those.

On VPS sizing, Infisical's own docs land on a sensible floor: 2 vCPU, 4 GB RAM, and a 30 GB SSD is enough for a small deployment, with 4 GB RAM per node as the documented minimum and 8 GB plus a 50 GB SSD recommended once you have many users or secrets. The Kubernetes Helm defaults give you a useful sense of the real footprint, too: the Infisical pod requests 350m CPU with a 1000Mi memory limit, PostgreSQL sits at 250m CPU / 512Mi, and Redis is tiny at 100m CPU / 256Mi. On a $12–$20/month VPS, that is comfortable.

What Infisical gives you in return is the part that actually drives adoption: a clean web UI, a genuinely good CLI, native secret referencing across environments, point-in-time secret recovery, and integrations that push secrets straight into GitHub Actions, Vercel, and your CI runner. When I integrated it into a client project that was bleeding API keys through a shared Notion page, the migration took an afternoon, and the developers stopped fighting it on day one. That last part is underrated — the best secrets tool is the one your team will actually use instead of routing around.

The honest tradeoff: Infisical is not trying to be Vault. It does dynamic secrets and PKI, but its center of gravity is static application secrets and developer workflow. If your requirement is "issue short-lived database credentials that expire in 15 minutes and rotate automatically across a fleet," you can do it, but you are no longer in Infisical's sweet spot.

OpenBao: the open Vault engine, minus the license tax

OpenBao is the interesting one, because it is Vault — the same security model, the same API paths, the same kv, transit, and pki secret engines — just continued under MPL 2.0 by a community that did not want to live under BSL. If you already know Vault, you already know OpenBao; the CLI is bao instead of vault and your muscle memory transfers almost completely.

The release cadence has been steady and, frankly, generous with features that HashiCorp historically gated behind Enterprise. OpenBao has shipped roughly quarterly since 2.0 in July 2024, and the latest as of this writing is v2.5.4, released May 16, 2026. Two milestones stand out for self-hosters:

• Namespaces landed in v2.3 (June 2025) — multi-tenancy and workload isolation that, in HashiCorp Vault, is an Enterprise-only paid feature. You route requests via path (/my-namespace/secrets) or the X-Vault-Namespace header, with full bao namespace CLI support.
• Horizontal read scalability arrived in v2.5.0 (February 4, 2026) — HA standby nodes can now serve reads locally while writes forward to the active leader. Again, this is functionality that was Enterprise-gated upstream, now in the free open core.

That is the real pitch: you get the Vault engine and a couple of features that would cost real money on the commercial side, for the price of running it yourself. The catch is the catch Vault always had — operational complexity. You have to think about seal/unseal, auto-unseal with a cloud KMS or a transit key, Raft storage and quorum, audit device configuration, and policy HCL. None of that is hard once you have done it twice, but the first production deployment has a real learning curve, and a misconfigured seal will lock you out of your own secrets at the worst possible moment.

On a VPS, OpenBao is lean — a single Go binary with integrated Raft storage runs comfortably on 1 vCPU and 1 GB of RAM for small workloads. The resource cost is not the binary; it is the operator's attention.

HashiCorp Vault: the enterprise original

Vault is still the most battle-tested secrets engine in existence, and for some buyers that is the whole argument. If you are in a regulated industry that needs vendor support contracts, a named compliance attestation, FIPS 140-2 builds, and the assurance that comes with IBM standing behind the product, Vault Enterprise is a defensible choice and the open forks are not.

But for the self-hosted VPS audience this site serves, the BSL license and the post-acquisition direction are friction. The Community Edition is free but deliberately limited — namespaces, HSM auto-unseal, performance replication, and disaster-recovery replication are Enterprise features. So if you self-host the free Vault Community Edition, you are running an engine that is functionally behind what OpenBao now ships in its open core. That is the strange position HashiCorp's own licensing created: the free fork has overtaken the free original on several features that matter to platform teams.

Pricing is the other wall. Vault Enterprise self-managed pricing is quote-only — you contact IBM/HashiCorp. For context on the order of magnitude, the cheapest production-grade managed tier, HCP Vault Dedicated, starts around $1,152/month for a small cluster before client fees. For a homelab or a lean startup running a handful of VPS boxes, that math does not work, and it is not meant to.

Day-2 operations: the part nobody benchmarks

Feature tables make these tools look closer than they feel in production, because the real difference shows up on day two — the day after install, when something needs maintaining. Here is where I have actually spent time with each.

Backups. Infisical's backup story is just "back up PostgreSQL," which is a problem I already solve on every site with pg_dump and a nightly cron. If you can back up a Postgres database — and you should already be doing that — you can back up Infisical. OpenBao and Vault store data in integrated Raft, so you take consistent snapshots with bao operator raft snapshot save; it works well but it is a new operational verb your runbook has to learn, and restoring into a fresh cluster has its own unseal dance.

The seal/unseal trap. This is the single biggest gotcha for newcomers to the Vault model, and it applies to both OpenBao and Vault. After any restart, the store comes up sealed and serves nothing until you provide unseal keys (or auto-unseal kicks in via a cloud KMS or a transit key from another instance). I have watched a team panic during a routine VPS reboot because nobody had documented who held the unseal shares. Infisical has no equivalent failure mode — it comes back up with its database like any normal app. If your team is small and reboots happen unattended, that operational simplicity is worth a lot.

Audit logging. All three can tell you who read which secret and when, which matters the first time you have to answer that question for a security review. The Vault engine (OpenBao/Vault) writes structured audit devices to file or syslog; Infisical surfaces an audit log in its UI and API. For a compliance auditor who wants raw, tamper-evident logs, the Vault-style audit devices are the more defensible artifact.

Authentication methods. Vault and OpenBao ship a long list of auth backends — AppRole, JWT/OIDC, Kubernetes, cloud IAM, TLS certs — which is exactly what you want when machines, not humans, are the primary consumers. Infisical covers the common cases (machine identities, OIDC, tokens) cleanly, and for an app-secrets use case that is plenty. But if your access model is "fifty different workload types each authenticating differently," the Vault engine's breadth is the deciding factor.

How I would decide (a simple matrix)

Here is the decision tree I actually use when a client asks me to pick one:

• You want secrets out of plaintext with the least friction → Infisical. Best UI, gentlest curve, PostgreSQL + Redis you already know. This covers maybe 70% of small-to-mid web teams.
• You left Vault specifically because of the license → OpenBao. It is the cleanest migration path — same API, same model, drop-in for most setups — and you keep namespaces and read scaling for free.
• You need dynamic secrets, PKI as a CA, and a hardened policy engine, on open terms → OpenBao again. It is the open inheritor of everything Vault was good at.
• You are an enterprise that needs vendor support, compliance attestations, and replication SLAs → Vault Enterprise. Pay for it; it earns its keep at that scale.
• You are a homelab or solo dev → Infisical for app secrets, or OpenBao if you specifically want to learn the Vault model. Skip commercial Vault entirely.

What this looks like on my own stack

To be concrete about the first-hand part: across my seven aggregator sites, secrets currently live in a structured .secrets/ directory — one JSON file per service, exactly the pattern these tools are designed to replace. When I set up the CVE tracking pipeline for CyberShieldTips (which aggregates from the NVD feed), the credential sprawl was real: database passwords, an NVD API key, IndexNow tokens, and SSH credentials for the publish step, all touching the same cron job. That is precisely the kind of mess a secrets manager fixes — one authenticated fetch at runtime instead of secrets baked into a dozen scripts.

My recommendation, and the direction I am moving my own infrastructure, is Infisical for the application-facing secrets (the API keys and tokens that scripts read at runtime) because the developer ergonomics are unmatched, and OpenBao reserved for anything that needs dynamic, short-lived credentials — the moment you want a database login that exists for 15 minutes and then evaporates, you want the Vault engine, and OpenBao gives you that without the license headache. I would not start a new self-hosted project on commercial Vault in 2026 unless a compliance requirement forced my hand.

Frequently asked questions

Is OpenBao really a drop-in replacement for Vault?

For the vast majority of setups, yes. OpenBao forked from the last MPL 2.0 Vault release and preserves the API paths, secret engines, and auth methods. The CLI is renamed from vault to bao. Migrations from Vault Community Edition are generally straightforward; the divergence grows over time as each project adds its own features, but in mid-2026 compatibility is still very high.

Can I run any of these on a cheap shared host?

No — all three need a persistent process and (for Infisical) PostgreSQL and Redis, which shared hosting does not give you. You want a VPS. OpenBao and Vault are happy on a 1 vCPU / 1 GB box for small workloads; Infisical wants 2 vCPU / 4 GB because of the database and Redis alongside it.

What is the difference between OpenBao namespaces and Infisical projects?

OpenBao namespaces are true isolated mini-Vaults — separate policies, mounts, and tokens under one cluster, designed for multi-tenant platform teams. Infisical's projects-and-organizations model is simpler and oriented around application boundaries and team access rather than full cryptographic isolation. For most app teams, Infisical's model is enough; for platform teams running many tenants, OpenBao namespaces are the stronger primitive.

Does the BSL license actually affect me if I just self-host Vault for my own use?

For purely internal use, BSL 1.1 permits it — you are not reselling Vault as a service. The practical issues are the Enterprise feature gating (namespaces, replication, HSM auto-unseal are paid) and the strategic uncertainty of building on a product whose owner has shown it will change terms. Many teams move to OpenBao not because BSL blocks them today, but because they would rather not be exposed to the next license change.

Which one has the best secret rotation?

For dynamic, automatically rotated, short-lived credentials — database logins, cloud IAM, PKI certificates — the Vault engine (so Vault or OpenBao) is stronger and more mature. Infisical handles rotation and dynamic secrets too and keeps improving, but its design center is developer-managed application secrets, so for heavy dynamic-credential workloads OpenBao is the safer pick.

The bottom line

If I compress 11 years of handling other people's credentials into one sentence: pick Infisical when the problem is developer workflow, pick OpenBao when the problem is a real secrets engine on open terms, and pick Vault Enterprise only when a compliance contract demands it. The license exodus that created OpenBao was not noise — it genuinely shifted the best free option away from HashiCorp, to the point where OpenBao's open core now ships namespaces and read scaling that cost money upstream. For the self-hosted VPS crowd, that is the headline of 2026: you no longer have to choose between a great secrets engine and an open license. You can have both.

Whatever you choose, the worst option is the one most of us are still running — secrets in plaintext, sprawled across scripts and config files. Stand one of these up on a $10 VPS this week. Future you, the one who didn't leak a production password to a public repo, will be grateful.