HashiCorp Vault vs OpenBao: een grondige vergelijking voor platformteams

Als je vandaag een secrets manager kiest en je shortlist begint bij HashiCorp Vault, ben je het aan jezelf verplicht om OpenBao serieus te bekijken. Het is geen curiositeit meer. Het draait in productie bij GitLab. Het is de standaard secret store in EdgeX Foundry 4.0. Het zit onder de Open Source Security Foundation met een gepubliceerde roadmap, werkende governance en een release cadence die sinds GA opvallend stabiel is. En het staat onder MPL 2.0, wat meer uitmaakt dan veel evaluaties toegeven.

Dit is geen hot take en geen aanval op een van beide projecten. Ik heb Vault clusters in gereguleerde omgevingen gezet en de twee projecten van dichtbij gevolgd sinds de fork. Het juiste antwoord is zelden voor de hand liggend en valt bijna nooit samen met de luidste mening van die week. Dus dit is de lange, zorgvuldige versie: licenties, feature parity, de Enterprise-features die er echt toe doen, de gaten die OpenBao nog heeft, het migratiepad, en een keuzemodel dat je kunt gebruiken zonder te gokken.

TL;DR

• HashiCorp Vault staat nu onder BUSL 1.1 en is eigendom van IBM. OpenBao is een MPL 2.0 fork vanaf Vault 1.14 die onder de OpenSSF leeft.
• Voor 80% van de basisgevallen (KV, PKI, dynamische database credentials, Kubernetes auth, Raft HA) zijn de twee functioneel inwisselbaar.
• OpenBao heeft grote Enterprise-gaten gedicht: open-source namespaces, HSM/PKCS#11 unsealing, de Transform secrets engine en read scalability via standby nodes zitten allemaal in mainline.
• Vault Enterprise wint nog steeds op Performance- en DR-replicatie, Sentinel policies, FIPS 140-3 builds en een managed dienst (HCP Vault Dedicated).
• Bouw je een product op een secrets manager, draag je terug bij upstream, of wil je toekomstige IBM-licentiebeslissingen vermijden? Dan is OpenBao het veiligere fundament.

Inhoudsopgave

• Waarom deze vergelijking überhaupt bestaat
• De licentievraag, in gewone woorden
• Waar de twee projecten vandaan komen
• Feature parity, de eerlijke versie
• De Enterprise-features die er nog toe doen
• Operationele zaken: HA, replicatie, schaal
• Kubernetes-integratie vandaag
• Migreren van Vault naar OpenBao
• Performance en footprint
• Gezondheid en governance van de community
• Wanneer Vault het juiste antwoord is
• Wanneer OpenBao het juiste antwoord is
• Wanneer het echt om het even is
• Risico: waar kan het misgaan?
• Belangrijkste punten

Waarom deze vergelijking überhaupt bestaat

Negen jaar lang viel er over Vault niets te vergelijken. De secrets manager van HashiCorp was wat de meeste teams pakten, de documentatie was diep, de community was gezond, en de licentie was MPL 2.0. Erop bouwen bracht geen bijzonder risico met zich mee.

Dat veranderde op 10 augustus 2023, toen HashiCorp elk product in zijn portfolio van MPL 2.0 naar de Business Source License 1.1 verschoof. Vault 1.14 was de laatste MPL release. Vanaf Vault 1.15 ging alles onder BUSL. De licentie geeft elke release een vertraging van vier jaar voordat-ie naar MPL terugvalt, en voegt een Additional Use Grant toe die voorkomt dat iemand een "competitive offering" tegen de betaalde producten van HashiCorp aanbiedt.

OpenBao werd vier maanden later aangekondigd op de Open Source Summit in Tokio, in berichtgeving die op 8 december 2023 verscheen. De eerste GA release kwam op 16 juli 2024 als v2.0.0. IBM rondde zijn overname van HashiCorp van 6,4 miljard dollar af op 27 februari 2025, en Vault is nu een IBM Software product. Per april 2026 is BUSL niet teruggedraaid en is er geen publiek signaal dat dat gaat gebeuren.

Dus de vergelijking bestaat omdat het onderliggende product in tweeën is gesplitst. Ze delen hetzelfde DNA, maar de projecten zijn echt uit elkaar gaan groeien, en de keuze die voor je ligt is niet meer alleen "gebruik Vault."

De licentievraag, in gewone woorden

Licentiediscussies worden snel filosofisch. De praktische versie is simpeler.

Vault is BUSL 1.1. De exacte Additional Use Grant in het Vault LICENSE bestand zegt: "You may make production use of the Licensed Work, provided Your use does not include offering the Licensed Work to third parties on a hosted or embedded basis in order to compete with IBM Corp's paid version(s)." Elke release valt vier jaar na publicatie terug op MPL 2.0. Intern gebruik, aanpassen, herdistributie, dienstverlening eromheen en bijdragen terugkoppelen mogen allemaal. Wat niet mag, is een managed secrets-management SaaS bouwen op Vault en concurreren met HCP Vault Dedicated.

OpenBao is MPL 2.0. Geen Additional Use Grant, geen competitive offering clause, geen vier jaar vertraging. Je kunt het in een product embedden, als managed dienst aanbieden en er geld voor vragen. Je draagt bij zonder een CLA-equivalent dat bijdragen vasthaakt in een BUSL-product.

Voor één bedrijf dat secrets management draait voor zijn eigen engineers heeft BUSL nul praktische impact. Je concurreert niet met HCP Vault. Je kunt Vault installeren, schalen, aanpassen en tien jaar lang draaien zonder de licentie ooit tegen te komen. Dat geldt voor de meeste lezers, en dat is wel zo eerlijk om hardop te zeggen, want anders ontspoort het gesprek.

Voor een vendor die een product bouwt is de rekensom precies omgekeerd. Bevat jouw product een secrets manager en weet je niet zeker of je aanbod als "competitive" met HCP Vault telt, dan zit je nu in juridisch terrein dat je niet hoefde op te zoeken. GitLab is het schoonste publieke voorbeeld: zij moeten een secrets manager in hun CI/CD pipelines embedden en patches kunnen terugkoppelen, en dat kon onder BUSL niet zonder juridisch risico. Ze kozen OpenBao. Dat is een redelijk antwoord op een echt probleem.

Voor organisaties die simpelweg de voorkeur geven aan OSI-goedgekeurde licenties (overheden, bepaalde inkoopprocessen, open-source-eerst beleid) is MPL 2.0 de enige optie van de twee.

Waar de twee projecten vandaan komen

OpenBao is niet uit de lucht komen vallen. De eerste werkgroepbijeenkomst was in november 2023 met engineers van het IBM Open Horizon edge-computing team, voordat de overname door IBM überhaupt bekend was. Sebastian Stadil (CEO van Scalr, ook een van de OpenTofu-organisatoren) hielp het project naar buiten te brengen. Het splitspunt was Vault 1.14.0 (de laatste MPL 2.0 release), de binary werd hernoemd naar bao, en het project sloot zich aan bij LF Edge in april 2024.

In juni 2025 verhuisde OpenBao naar een passendere thuisbasis en trad het toe tot de OpenSSF als Sandbox-project. Even precies: OpenBao is geen CNCF-project. De OpenSSF is een aparte Linux Foundation sub-foundation gericht op open-source security, en daar zit OpenBao nu.

De actieve backers per april 2026:

• GitLab. Officieel toegetreden in juli 2024, stemrecht behaald in oktober 2024. Alex Scheel is zowel Staff Backend Engineer bij GitLab als voorzitter van de Technical Steering Committee van OpenBao. GitLab gebruikt OpenBao als de native secrets manager voor zijn CI/CD pipelines.
• IBM (via het Open Horizon project, vóór de HashiCorp-overname).
• Orange. De Franse telecom steunde de toetreding tot LF Edge omdat het paste binnen hun Sylva 100% open-source beleid.
• EdgeX Foundry. Verving Vault door OpenBao als standaard secret store in EdgeX 4.0 "Odesa" op 1 april 2025.
• Percona. Gebruikt OpenBao als KMIP key provider voor PostgreSQL transparent data encryption.
• ControlPlane. Lanceerde op 12 maart 2026 een commercieel enterprise-supportaanbod voor OpenBao.

Vault zelf zit nu onder IBM Software (niet onder Red Hat). Die organisatorische plek is veelzeggend. IBM Software is een commerciële softwaredivisie. Red Hat is de open-source platformtak. Waar een product intern terechtkomt zegt iets over hoe IBM het gaat exploiteren.

Feature parity, de eerlijke versie

Het meeste van wat je dagelijks gebruikt werkt op beide hetzelfde. Sommige zaken zijn alleen op OpenBao identiek. Een paar dingen horen nog steeds bij Vault Enterprise alleen. Behandel onderstaande matrix als werkende checklist, niet als heilige tekst: er komt elk kwartaal iets bij in OpenBao en het gat dicht zich maandelijks.

Secrets engines

De kop van het verhaal hier is de Transform secrets engine. In Vault zit die in de Advanced Data Protection module en betaal je een Enterprise-licentie. In OpenBao zit hij in mainline en is hij gratis. Gebruik je format-preserving encryption of tokenization voor PCI-achtige data, dan is dat een echt kostenverschil.

De MongoDB-verwijdering is interessant. OpenBao heeft de MongoDB database plugin op principe verwijderd: MongoDB is overgestapt op SSPL, dat is geen OSI-goedgekeurde licentie, en het project koos ervoor geen integraties te leveren met niet-OSI software. Hang je af van dynamische MongoDB credentials, dan is dat een wrijvingspunt waar je rekening mee moet houden.

Auth methodes

De meeste teams merken het verschil niet. Hang je SAML-auth direct op de Vault-laag, in plaats van Vault achter een OIDC-proxy te zetten, dan zit je in Enterprise-only territorium.

Storage backends

OpenBao heeft hier bewust gesnoeid. Productie-storage op OpenBao is Integrated Storage (Raft) of PostgreSQL. De legacy backends (Consul, DynamoDB, S3, etcd, ZooKeeper, MySQL, Cassandra) zijn weg. Vault Community ondersteunt ze nog steeds als community-onderhouden opties, al duwt HashiCorp zelf al een paar releases iedereen richting Raft.

Dit is het soort snoeiwerk dat tijdens migratie pijn doet als je net op de Consul-backend zat, maar het levert wel op: minder code paths om te auditen, minder verrassingen in release notes, en een kleinere blast radius bij storage-bugs. Wat mij betreft een redelijke trade-off.

Seal/unseal

Hier heeft OpenBao stilletjes ingehaald: PKCS#11 auto-unseal was lang een van de meest genoemde redenen om Vault Enterprise te kopen. Nu zit het in OpenBao. Eén operationeel verschil is het waard om te kennen: OpenBao's PKCS#11 implementatie eist dat het sleutelmateriaal extern wordt aangemaakt vóór initialisatie, terwijl Vault Enterprise zijn eigen sleutels genereert. Schrijft je security policy voor dat HSM-sleutels extern worden geprovisioned, dan is dat eigenlijk een feature. Wilde je dat Vault dat voor je deed, dan bestaat die workflow niet in OpenBao.

De static seal is OpenBao's eigen vondst. Hij leest een AES-256-GCM sleutel uit een bestand of environment variable, wat klinkt als een foot-gun en in een vertrouwensloze omgeving is dat ook zo. In Kubernetes deployments waar het platform zelf de vertrouwensgrens vormt (sealed Pod, gecontroleerde Secret, et cetera) haalt het de afhankelijkheid van een cloud-KMS netjes weg.

Namespaces

Dit is veruit het grootste Enterprise-parity verhaal dat OpenBao heeft uitgeleverd. Namespaces waren de belangrijkste multi-tenancy feature van Vault Enterprise: één cluster dat meerdere geïsoleerde tenants bedient met eigen auth, policies, secrets engines en tokens. Ze zijn nu open source in OpenBao, GA in v2.3.1 (25 juni 2025).

OpenBao's implementatie is ontworpen om API-compatibel te zijn met Vault Enterprise namespaces, inclusief hiërarchische namespaces, namespace locking, de -ns CLI vlag en self-service admin delegation. Er zijn nog gaten: per-namespace storage backends, namespace sealing en niet-hiërarchische namespaces staan op de roadmap maar zijn nog niet GA. Voor de meeste multi-team Vault deployments die Enterprise primair om de namespaces hadden gekozen, is OpenBao nu voldoende.

Policies

Vault heeft Sentinel (Enterprise-only) voor policy-as-code: EGPs (Endpoint Governing Policies) hangen aan API-paden en kunnen regels afdwingen, ook op niet-geauthenticeerde paden zoals login; RGPs (Role Governing Policies) hangen aan tokens en gelden globaal. Sentinel kan dingen die ACLs niet kunnen, zoals tijd-van-de-dag restricties of IP-range enforcement.

OpenBao heeft CEL policies, specifiek ingebed in PKI en JWT auth. CEL is Google's Common Expression Language. Het is smaller dan Sentinel: het biedt geen path-overstijgende enforcement of token-niveau governance, alleen validatielogica binnen specifieke plugins. De OpenBao maintainers erkennen zelf dat het vandaag zwakker is dan Sentinel of OPA. De roadmap is om CEL naar meer plugins uit te rollen, maar pariteit is nog niet in zicht.

Hangt je governance-model aan Sentinel? Dan is dat een echte Vault Enterprise lock-in.

Audit devices

Beide projecten ondersteunen file, syslog en socket audit devices. OpenBao voegt een HTTP audit device toe voor laagvolume webhook-gebaseerde audit-rapportage, en laat je audit devices configureren in het configbestand (niet alleen via API). Dat laatste is echt nuttig: je hebt audit logging vanaf het allereerste request, voordat de API überhaupt bereikbaar is.

CLI en API

De CLIs zijn syntactisch identiek. vault kv put secret/foo bar=baz wordt bao kv put secret/foo bar=baz. OpenBao leest zowel BAO_ADDR als VAULT_ADDR, en de meeste scripts draaien na een sed-replace van één binary-naam. De API is hetzelfde /v1/... oppervlak. Het tokenformaat verschilt (Vault gebruikt hvs./hvb./hvr. prefixen; OpenBao gebruikt kortere s./b./r.). Oude Vault tokens blijven na migratie geldig tot hun TTL afloopt.

Een kanttekening: OpenBao belooft niet voor altijd volledige v1 API backward compatibility. Het huidige verschil is klein, maar het zal groeien zodra OpenBao features toevoegt die Vault niet heeft.

De Enterprise-features die er nog toe doen

Na alle parity-winsten: wat heeft Vault Enterprise nog dat OpenBao niet heeft?

Performance Replication en Disaster Recovery Replication. Dit is de grote. Vault Enterprise laat je meerdere clusters over regio's draaien met synchrone performance replication voor read-heavy workloads, plus een aparte DR replication channel voor failover. OpenBao heeft geen equivalent. Het OpenBao-antwoord is non-voter Raft nodes in een tweede datacenter die je bij failover kunt promoveren, wat werkt maar een ander operationeel model is. Draai je nu een multi-cluster Vault Enterprise topologie over regio's, dan is afscheid nemen van Vault Enterprise niet triviaal.

FIPS 140-3 builds. Vault Enterprise voegde FIPS 140-3 Level 1 compliant builds toe in v1.21 (oktober 2025). OpenBao heeft een open issue om FIPS builds te leveren via de GOFIPS140 ondersteuning in Go 1.24, maar er is per april 2026 nog geen officiële build. ControlPlane biedt FIPS 140-3 compliance aan als onderdeel van hun commerciële support, wat ik zelf niet heb geverifieerd. Is FIPS een harde regulatoire eis, dan is Vault Enterprise op dit moment het veiligere antwoord.

KMIP server. Vault Enterprise kan als KMIP server fungeren voor externe clients (databases, storage systemen, enterprise key management). OpenBao kan KMIP-unsealing doen als client, maar levert nog geen KMIP server. Het staat op de roadmap, gekoppeld aan de Transform engine, maar is niet uitgeleverd.

Sentinel. Hierboven al behandeld.

Secrets Sync. Vault Enterprise kan secrets uitduwen naar AWS Secrets Manager, Azure Key Vault, GitHub en vergelijkbare systemen. OpenBao heeft dit niet.

HCP Vault Dedicated. Een vendor-managed Vault, gehost door HashiCorp/IBM. Beschikbaar op AWS, Azure, GCP. Er is per april 2026 geen vergelijkbare managed OpenBao-dienst van wie dan ook. ControlPlane biedt enterprise support en migratiediensten, maar geen hosted operations.

Dat lijstje is korter dan een jaar geleden. De interessante vraag is of het nog verder krimpt, statisch blijft, of weer groeit naarmate OpenBao volwassener wordt.

Operationele zaken: HA, replicatie, schaal

Zowel Vault als OpenBao doen active+standby HA via Raft consensus. Drie of vijf nodes per cluster, leader bedient alle writes, standbys houden read-only replica's van de data.

De nieuwe ontwikkeling die ertoe doet: OpenBao v2.5.0 (februari 2026) gaf HA standby nodes de mogelijkheid om read-requests lokaal te bedienen. Dit is de feature die Vault Enterprise verkoopt als Performance Standby Nodes. Writes gaan nog steeds door naar de leader. Reads zijn eventually consistent en kunnen per request worden uitgezet. De release notes en de aankondigingspost beschrijven de implementatie. Dit was eerder een per-node Enterprise licentiekost. Nu zit het in mainline OpenBao.

Vault Enterprise wint nog op cross-cluster replicatie. Performance Replication houdt meerdere clusters synchroon voor globale read-scaling. DR Replication onderhoudt een continu bijgewerkt standby-cluster voor failover. De roadmap van OpenBao bevat non-voter Raft nodes (in v2.2 al uitgeleverd) en er is lopend werk aan multi-cluster topologieën, maar synchrone cross-cluster replicatie staat niet op de korte termijn.

Snapshots: Vault Enterprise heeft ingebouwde geautomatiseerde Raft snapshots. OpenBao levert een aparte, officieel onderhouden openbao-snapshot-agent. Externe tool, zelfde uitkomst. Dat zou ik niet zwaar laten meewegen.

Kubernetes-integratie vandaag

Hier heeft OpenBao zichtbaar werk in uitvoering en een paar echte gaten.

De gearchiveerde Secrets Operator is het gat dat ertoe doet. Sync je secrets vanuit je secrets manager naar native Kubernetes Secret-objecten (zodat Pods ze als env-vars of bestanden kunnen mounten), dan heeft Vault een onderhouden operator daarvoor. De first-party operator van OpenBao is dood. De maintainers verwijzen gebruikers naar External Secrets Operator (ESO) met een OpenBao-backend, wat goed onderhouden is en in productie wordt gebruikt door veel teams. Maar het is een doorverwijzing, en wel zo eerlijk om dat hardop te zeggen.

Voor de meeste andere Kubernetes-patronen (Vault Agent sidecar injection via mutating webhook, init containers, directe Vault Agent integratie) trekt OpenBao gelijk op met Vault.

Migreren van Vault naar OpenBao

De officiële OpenBao migratiegids is specifiek: alleen Vault 1.14.1 (Community Edition) is de geteste basis. De gids waarschuwt expliciet: "This guide will not work on Vault versions 1.15.0 and newer; use at your own risk."

Vault Enterprise migratie wordt niet ondersteund. Het Raft data-formaat in Vault Enterprise is niet compatibel met Vault Community of OpenBao. Je kunt geen Vault Enterprise snapshot maken en die in OpenBao herstellen.

Het ondersteunde in-place proces is grofweg:

1. Stop een follower node, vervang de binary door bao, voeg toe aan het cluster met bao operator raft join, unseal en controleer voter-status.
2. Rol door alle followers, trigger dan een leader step-down, en migreer als laatste de oude leader.
3. Pas audit log file permissions aan als dat nodig is.
4. Verwijder disable_mlock uit je config (mlock is in OpenBao 2.0 verwijderd).
5. Haal cloud-provider plugins uit openbao-plugins (de core OpenBao binary bundelt ze niet).

Tokens die door Vault zijn uitgegeven blijven werken tot hun TTL afloopt, dus je hoeft niet elke client op het moment van cutover te roteren.

Er is een bekend issue (GitHub #1154) waarbij snapshots van Vault 1.14.8 in sommige scenario's niet zijn te herstellen op OpenBao 2.2.0. Test snapshot-restore in staging voordat je daarop in productie vertrouwt.

In de praktijk: zit je op Vault Community 1.14, dan is de migratie reëel maar niet eng. Zit je op Vault 1.15+ of Vault Enterprise, plan dan een schone export/import met je eigen tooling in plaats van een snapshot-transplantatie. De API-compatibiliteit is wat dat werkbaar maakt. Je kunt elk secret uit Vault uitlezen via de bestaande API, naar OpenBao schrijven via diezelfde API, verifiëren en omschakelen.

Performance en footprint

Er is een rumoerige GitHub-discussie geweest over OpenBao die duizenden keren trager zou zijn dan Vault. De korte versie: het was een benchmark-fout waarbij OpenBao in dev mode draaide (die gebruikt een inmem backend die bij elke transactie state kopieert) tegen Vault op Raft. Toen de OpenBao-maintainers de test opnieuw deden met Raft aan beide kanten, kwam het verschil uit op ongeveer 21%, terug te voeren op de sterkere transactionele storage-garanties van OpenBao.

Dat is een anekdotische benchmark van één gebruiker, geen gepubliceerde onafhankelijke meting. Maar het is een redelijke indicatie dat OpenBao in dezelfde performance-klasse zit als Vault onder realistische omstandigheden. Draai je een enkel Vault-cluster met een paar honderd operaties per seconde (dat dekt de meeste deployments die ik zie), dan is het verschil operationeel onzichtbaar. Duw je Vault tegen zijn schalingslimieten, benchmark dan je eigen workload voordat je omschakelt.

Gezondheid en governance van de community

Een tweejarige fork is een fragiel ding. Dit zie ik als ik naar de indicatoren kijk:

OpenBao. Rond de 5.900 GitHub stars en 408 contributors per eind april 2026. Ongeveer kwartaal-cadans aan minor releases sinds 2.0 (2.0 juli 2024, 2.1 november 2024, 2.2 maart 2025, 2.3 juni 2025, 2.4 augustus 2025, 2.5 februari 2026, 2.5.3 in april 2026). De roadmap-retrospective van oktober 2025 meldde 741 commits en 287 actieve contributors over het voorgaande jaar, met 10 nieuwe committers. OpenSSF Best Practices badge, vijf CVEs gemeld en gepatcht in 2025. Werkgroepen voor Horizontal Scalability, UI en PKCS#11/KMS. Single-release support model: geen LTS, je wordt geacht te upgraden.

Vault. Rond de 33.400 GitHub stars. De release-cadens onder IBM verschuift naar "IBM Support Cycle-2" met grosso modo jaarlijkse major releases en 2+ jaar standaard-support per major. v2.0 (ja, hetzelfde nummer als OpenBao 2.0, volledig onafhankelijk) verscheen op 13 april 2026 en sprong van v1.21 naar v2.0 om aan de IBM-supportlevenscyclus te koppelen. Backed door de engineering-organisatie van IBM met formele support-SLA's.

Een paar risico-indicatoren om aan beide kanten in de gaten te houden. Aan de OpenBao-kant: zware afhankelijkheid van Alex Scheel als zowel meest actieve committer als TSC-voorzitter, single-release support, en de gearchiveerde Secrets Operator als signaal dat niet elk onderdeel eeuwig onderhouden wordt. Aan de Vault-kant: de organisatorische plaatsing onder IBM Software (niet Red Hat), het uitfaseren van HCP Vault Secrets in 2026, en geen publiek signaal dat BUSL wordt teruggedraaid.

Beide zijn gezond genoeg om de komende twee tot drie jaar op te bouwen. Daarna wordt het echt voorspellen, en daarbij weegt de licentievraag zwaarder dan het aantal GitHub-stars.

Wanneer Vault het juiste antwoord is

Kies Vault als een of meer van het volgende geldt:

• Je hebt vandaag cross-region Performance- of DR-replicatie nodig en je topologie hangt erop.
• FIPS 140-3 compliance is een harde regulatoire eis en je leunt liever niet op een derde-partij supportvendor voor die compliance.
• Sentinel policies zijn deel van je governance-model. CEL in OpenBao is daar nog niet equivalent aan.
• Je wilt een managed dienst van de leverancier (HCP Vault Dedicated). Een managed OpenBao bestaat niet.
• Je hebt de KMIP server, Key Management secrets engine of Secrets Sync van Vault Enterprise nodig.
• Je zit diep in de IBM/Red Hat stack en strakkere native integratie met OpenShift, Ansible Automation Platform of watsonx is deel van je architectuur.
• Je draait Vault Community intern, zonder Enterprise-features en zonder plannen om er een product op te bouwen. BUSL raakt je in de praktijk niet, en het grotere ecosysteem is een echt voordeel.

Wanneer OpenBao het juiste antwoord is

Kies OpenBao als een of meer van het volgende geldt:

• Je bouwt een product dat secrets management bevat. De Additional Use Grant van BUSL voegt juridisch risico toe dat MPL 2.0 niet heeft.
• Je inkoopproces, overheidskader of open-source-eerst beleid eist een OSI-goedgekeurde licentie.
• Je hebt namespaces (multi-tenant Vault) nodig zonder voor Vault Enterprise te willen betalen.
• Je gebruikt de Transform secrets engine voor FPE, masking of tokenization en je wilt geen Vault Enterprise ADP afnemen.
• Je wilt PKCS#11/HSM auto-unsealing zonder Enterprise-licentie.
• Je deployt naar edge-omgevingen (de static seal is een schoner model voor Kubernetes-vertrouwde grenzen).
• Je wilt upstream bijdragen zonder een CLA die je bijdragen in BUSL-territorium plaatst.
• Je vindt het feit dat IBM eigenaar is van Vault een lange-termijn licentierisico en hedge je liever door op MPL 2.0 te bouwen.

Wanneer het echt om het even is

Voor deze workloads werkt elk van de twee:

• Plain KV secrets met team-gebaseerde ACL policies.
• PKI voor interne services, met automatische verlenging via cert-manager of Vault Agent.
• Dynamische database credentials voor Postgres, MySQL of een van de andere ondersteunde engines.
• Kubernetes auth-methode, Agent Injector voor sidecar secret retrieval.
• Single-region HA via Raft, inclusief read scalability via standby nodes (sinds Vault Enterprise en OpenBao 2.5+).
• Terraform/OpenTofu state-encryption keys via de Transit engine.

Voor deze gevallen zorgt API-compatibiliteit ervoor dat je bestaande code en IaC blijft werken. Het eerlijke antwoord is: kies degene wiens licentiehouding je liever op de plank hebt liggen en ga door.

Risico: waar kan het misgaan?

Hier wil ik specifiek zijn in plaats van vaag.

Het reële Vault-risico is niet dat IBM het tapijt onder iedereen wegtrekt en volledig proprietary gaat. Dat zou het ecosysteem-effect vernietigen waar Vault waarde aan ontleent. Het reële risico is dat BUSL blijft, een eventuele volgende licentie-aanscherping eerder incrementeel dan dramatisch is, en dat de geleidelijke verschuiving van Vault richting IBM-interne prioriteiten (afstemming op watsonx, Guardium, IBM lifecycle versionering) Vault minder aantrekkelijk maakt voor organisaties buiten de IBM-stack. Lees je de analyse van Ned Bellavance uit maart 2025, dan is de meest waarschijnlijke uitkomst onder IBM "Vault blijft shippen, BUSL blijft, het community-ecosysteem doet IBM minder dan enterprise klanten."

Het reële OpenBao-risico is governance-fragiliteit. GitLab heeft de TSC-voorzitter in dienst en is de grootste gebruiker. ControlPlane levert commerciële support maar is niet groot. Er is geen equivalent van de OpenTofu-launch waar vijf bedrijven vanaf dag één fulltime engineers betaalden. Als GitLab van koers verandert of als Alex Scheel vertrekt, hapert de snelheid. Het single-release support model betekent dat als je achterloopt op upgrades, er geen patch-stream is om op terug te vallen. De gearchiveerde Secrets Operator laat zien dat niet elk onderdeel eeuwig liefde krijgt.

Geen van beide risico's is zo ernstig dat het je beslissing vandaag moet sturen. Ze zijn reëel genoeg om in een vijfjaarsbeslissing mee te wegen.

Belangrijkste punten

• De licentie is het fundamentele verschil. Vault is BUSL 1.1, eigendom van IBM, met een competitive offering clause. OpenBao is MPL 2.0 onder de OpenSSF. Voor intern-only gebruik is het praktische verschil klein. Voor productbouwers, vendors en open-source-eerst organisaties is MPL 2.0 het veiligere fundament.
• OpenBao heeft de pijnlijkste Vault Enterprise-gaten gedicht. Open-source namespaces, PKCS#11/HSM auto-unsealing, de Transform secrets engine en read scalability via standby nodes zitten allemaal in mainline. Dat is een betekenisvolle verschuiving ten opzichte van waar het project bij v2.0 stond.
• Vault Enterprise wint nog op Performance/DR replicatie, Sentinel policies, FIPS 140-3 builds en een managed dienst. Is een van die vier niet onderhandelbaar, dan kies je Vault.
• Migratie van Vault Community 1.14 naar OpenBao is reëel maar overzichtelijk. Vanaf Vault 1.15+ of Vault Enterprise zit je op een API-gedreven re-import, niet op een snapshot-transplantatie. Plan dat in.
• API-compatibiliteit zorgt dat de meeste code, libraries en de hashicorp/vault Terraform provider op OpenBao blijven werken. Dat is geen permanente garantie, maar voor de komende paar jaar wel.
• De juiste keuze hangt af van wat je bouwt, niet van wie meer GitHub-stars heeft. Beslis eerst over licentiehouding en afhankelijkheid van Enterprise-features. De rest volgt daaruit.