Nvidia Runs OpenBao in Production: The Vault Fork's Enterprise Moment, and How to Wire It Into Kubernetes

On May 20, 2026, NVIDIA joined the public adopters page of OpenBao, the community fork of HashiCorp Vault — and the adopter text names the workload: NVIDIA Cloud Functions (NVCF), the company's auto-scaling serverless GPU control plane, relies on OpenBao as part of its internal secrets-management infrastructure. NVIDIA's own docs show OpenBao injecting secrets into the Kubernetes pods NVCF schedules. The most valuable hardware company on earth runs its GPU platform's secrets on the fork.

That settles the question this post opened with: OpenBao has crossed the enterprise-viability line, and a self-hosted PaaS can now bet its tenant-secrets layer on it with production precedent behind the decision. What follows is the evidence file behind that call, what the 2.5 and 2.6 releases changed for multi-tenant platforms, and the one Kubernetes integration pattern to use — because OpenBao archived its own Kubernetes operator in February, and the replacement is not another bespoke operator.

The enterprise evidence, in one table​

Two months ago we compared Vault Community Edition against OpenBao on licensing and namespaces and concluded OpenBao was the only option that cleared both the embedding-license bar and the multi-tenancy bar. What changed since is not the argument — it is the company the fork keeps:

The driver behind most of this is digital sovereignty, not price. ControlPlane's APAC head told TechTarget that enterprise interest surged this year, that roughly 75% of the firm's strong OpenBao leads sit outside the US, and that EU buyers in particular want secrets stored in infrastructure they control rather than in a vendor's region. When the EU's Cyber Resilience Act reporting obligations began this month, "who can patch my secrets manager and under what license" stopped being a philosophical question and became a procurement checkbox — one a Linux Foundation-governed MPL-2.0 codebase answers cleanly and a BSL-licensed one answers awkwardly.

One honest calibration: OpenBao's ecosystem is still far smaller than its sibling fork OpenTofu, which lists 163 supporting companies. Adopting OpenBao in late 2026 means joining the enterprise wave early, with NVIDIA and SAP as cover — not late, with a decade of precedent. For a platform choosing a secrets backend it will live with for years, "early with marquee cover" is a perfectly good place to be, as long as you price in the gaps in the last section below.

What v2.6 changed for multi-tenant platforms​

OpenBao 2.6.0 shipped July 14, 2026, and two of its headline features read like they were designed for exactly one customer: a platform running many tenants' secrets on one cluster.

Namespace sealing is the bigger one. Namespaces went GA in June 2025 and gave OpenBao the logical isolation Vault reserves for Enterprise — each tenant gets its own policies, auth methods, and secret engines inside one cluster. Sealing adds the cryptographic half: a namespace can now be created with its own Shamir seal configuration, so a tenant's access to its namespace can be revoked via a seal operation without impacting any other tenant on the same cluster, with seal status synchronized globally across multi-node deployments. Logical isolation says tenants cannot see each other's secrets; per-namespace sealing says one tenant's key ceremony does not touch another tenant's availability. A PaaS offering "bring your own unseal keys per app" just got its primitive.

Workflows (sys/workflows) let operators define simplified, managed interfaces over OpenBao's standard API — create a workflow once, let users execute it without learning the full API surface. Platform teams can now put a narrow self-service operation ("rotate my database credentials," "issue a short-lived cert for this deploy") in front of tenants without handing them raw Vault-API power or building a bespoke proxy service. ControlPlane's team called this the integration point for internal developer portals, which is precisely what a PaaS tenant dashboard needs: a scoped action, not a token with opinions.

The supporting cast matters too. Horizontal read scalability (2.5.0) automatically upgrades every existing HA standby node with read support, so a cluster's read capacity grows with node count instead of funneling through the active node — the scaling direction a secrets backend actually needs, since secret reads outnumber writes by orders of magnitude. The project's March deep-dive and its OSSNA 2026 talk lay out the longer arc: using namespaces as the isolating boundary so write scalability can eventually follow reads. And distroless container images (openbao-distroless, containing only the OpenBao binary) shrink the CVE surface of the thing guarding every other credential you own.

One heads-up from the same release notes: v2.7.0 will remove several built-in auto-unseal mechanisms (AWS, Azure, GCP, OCI, Alibaba, PKCS#11), the file storage backend, the separate HSM distribution, and built-in Kerberos auth — all moving to external plugins. That is the right long-term shape, but if you deploy 2.6 with a built-in cloud-KMS seal, budget a plugin migration before you upgrade past it.

The Kubernetes wiring: ESO, not a bespoke operator​

Here is the decision this post exists to settle. OpenBao used to ship its own Kubernetes Secrets operator; the project archived that repository on February 20, 2026 — it is now read-only, and its README advises using the External Secrets Operator instead. ESO ships a native OpenBao provider, and the archived repo's final state points at it explicitly.

This is good news disguised as a deprecation. A fork-maintained operator would always trail ESO's provider matrix, review bandwidth, and release testing; consolidating behind the CNCF-adjacent standard means the OpenBao path inherits every ESO improvement (ClusterSecretStore scoping, push secrets, generator support) for free. When the upstream project itself declines to maintain a bespoke operator, running your own fork of that idea is volunteering for maintenance the maintainers already priced and refused.

The concrete architecture for a Cluster-API-managed fleet:

1. One OpenBao cluster, platform-owned, with namespaces GA-isolated per tenant app and namespace sealing where tenants need their own key ceremony.
2. Kubernetes auth per namespace, so each tenant's service account authenticates only into its own OpenBao namespace — the same trust boundary as the workloads, no long-lived tokens sprayed across clusters.
3. ESO SecretStore per tenant namespace pointing at OpenBao, plus ExternalSecret resources syncing remote values into ordinary Kubernetes Secrets the app consumes with zero OpenBao awareness:

apiVersion: external-secrets.io/v1
kind: SecretStore
metadata:
  name: tenant-secrets
spec:
  provider:
    openbao:
      server: https://openbao.platform.svc:8200
      path: tenant/acme
      version: v2
      auth:
        kubernetes:
          mountPath: kubernetes
          role: tenant-acme-reader
---
apiVersion: external-secrets.io/v1
kind: ExternalSecret
metadata:
  name: db-credentials
spec:
  refreshInterval: 5m
  secretStoreRef:
    name: tenant-secrets
    kind: SecretStore
  target:
    name: db-credentials
  data:
    - secretKey: password
      remoteRef:
        key: database/production
        property: password

Nothing in the tenant's container image knows OpenBao exists; rotation happens server-side and ESO re-syncs on its refresh interval. If a future backend ever replaces OpenBao, the migration unit is the SecretStore, not every app.

The honest gaps​

Three things to price in before you commit. First, OpenBao is still an OpenSSF sandbox project, not graduated or incubating — foundation backing with audits and a CVE process, but not the maturity stamp graduation implies. Second, the v2.7 plugin migration above is real deprecation churn: seals, storage, HSM, and Kerberos all move at once, so pin your 2.6 deployment deliberately and schedule the migration rather than discovering it mid-upgrade. Third, eight commercial support vendors is not IBM-scale support — the paid Vault is now IBM Vault Enterprise with that company's service apparatus behind it, while OpenBao's enterprise story runs through specialists like ControlPlane (which, to be fair, also sells a Vault-to-OpenBao migration tool, so the exit ramp is paved in both directions).

None of these outweighs the license arithmetic: Vault Community Edition's BSL still bars embedding in a product you sell, and OpenBao's namespaces-plus-sealing story now covers the isolation depth that used to justify an Enterprise contract. Watch the roadmap item ControlPlane flagged — short-lived secrets management for AI agents — because a PaaS issuing per-sandbox credentials to agent workloads will want exactly that primitive the moment agent sandboxes become tenants too.

The fork won the argument in July on licensing. In September it is winning the enterprise on adoption, releases, and a Kubernetes story that points at the standard operator instead of away from it. That is what "safe to bet on" looks like: not the absence of gaps, but gaps you can schedule around while marquee names absorb the career risk.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Owning your fleet means owning decisions like this one instead of renting them. Star the repo on GitHub or deploy your first app today.

Sources​

• TechTarget, "Nvidia adopts OpenBao, open source fork of HashiCorp's Vault" (June 18, 2026) — techtarget.com: NVIDIA added to adopters May 20; NVCF secrets injection; eight commercial support companies; Scheel to ControlPlane March 2026.
• GitHub openbao/openbao issue #3144 — NVIDIA's authorization to join the adopters page; adopter text names NVCF's internal secrets-management infrastructure.
• NVIDIA NVCF self-managed-clusters docs — docs.nvidia.com/nvcf/self-managed-clusters: runtime secrets injected by the OpenBao vault-agent sidecar.
• OpenBao 2.6.x release notes — openbao.org/community/release-notes/2-6-0: v2.6.0 (July 14, 2026) namespace sealing, workflows, auto-unseal plugins, distroless images; v2.7.0 removal schedule.
• GitHub openbao/openbao-secrets-operator — archived by the owner Feb 20, 2026; README advises External Secrets Operator with its native OpenBao provider.
• External Secrets Operator OpenBao provider docs — external-secrets.io/latest/provider/openbao.
• OpenBao, "Improved Horizontal Scalability" (March 25, 2026) and cipherboy's OSSNA 2026 talk "Horizontally Scaling Secrets Management" — read scalability in 2.5.0, namespace-boundary write-scaling roadmap.
• ComputerWeekly Open Source Insider, "OpenBao strides forward in the enterprise" — NVIDIA, Broadcom, GitLab, SAP support; v2.6 server-side workflows.
• ControlPlane Enterprise for OpenBao — control-plane.io/enterprise-for-openbao: GitLab, SAP, NVIDIA, Epic Games, Proton, G-Research validation; EU CRA reporting September 2026.
• Open Source For You, "NVIDIA, GitLab Back OpenBao For Secrets Management" (August 2026).