All offers
Fixed-scope build
Open Source
OpenBao Implementation and Operation
Eight weeks to production secrets management on OpenBao — rolled out, wired into your workloads, and operated by us if you want. Fully open source, in your infrastructure, with key custody staying yours.
Duration
8 weeks, operation optional
Usual next step
Open Source Assurance
The problem
Secrets management is the piece of platform infrastructure that everyone depends on and nobody wants to own. It ends up as a mix of CI variables, Kubernetes Secrets committed in a hurry, a spreadsheet somebody swears is temporary, and one Vault instance that a person who has since left the company installed.
Two things have made this harder recently. HashiCorp’s move of Vault to the Business Source License changed the terms under which many organizations were running their secrets platform, and prompted a re-evaluation that most teams have not had time to finish. At the same time NIS2 and DORA have made credential handling, key custody, and access auditability into questions you are expected to answer with evidence rather than intent.
OpenBao is the open source answer to the first problem. It is a Linux Foundation project, API-compatible with the Vault versions most organizations are running, and it is genuinely open source, which means you can inspect it, run it anywhere, and leave. What it does not come with is an implementation.
What we build
A production secrets platform, not a proof of concept.
OpenBao deployed for high availability with your chosen storage backend, auto-unseal, and a tested restore path
Authentication methods wired to how your organization actually works: OIDC for humans, Kubernetes service accounts for workloads, AppRole or JWT for pipelines
Secret engines for the cases you have: static key–value, dynamic database credentials, PKI for internal certificates, transit encryption where applications should never hold a key
Policies as code, in your repositories, reviewed like any other change, so access is a pull request rather than a ticket
Workload integration: the secrets operator or agent injector pattern that fits your platform, so applications receive secrets without a developer ever handling one
Audit devices configured and shipped to your existing logging stack, with a retention position that matches your obligations
Key custody and break-glass arranged deliberately, documented, and rehearsed rather than assumed
If you are migrating from Vault
We inventory what you run today, map the engines, policies, and consumers, and sequence a migration that moves consumers in waves rather than attempting a cutover. Where a Vault Enterprise feature has no OpenBao equivalent, we tell you before you commit rather than after.
How it runs
Weeks | Phase |
|---|---|
1 to 2 | Discovery: current secrets estate, consumers, compliance constraints, availability and recovery requirements, migration scope if applicable |
3 to 5 | Build: high-availability deployment, auth methods, secret engines, policy as code |
6 | Integration: first consumers onboarded end to end, from pipeline and from cluster |
7 | Hardening: audit, key rotation, break-glass, backup and restore rehearsal |
8 | Enablement and handover to your operators |
Optional: we operate it
Secrets management is a service that has to be available at three in the morning and patched the week a CVE lands. If you would rather not staff that rota, we run it under an agreed service level: upgrades, security response, certificate and key rotation, availability monitoring, and incident response, with your team retaining full access and the ability to take it back at any point.
This is optional and priced separately. The implementation stands on its own and is designed to be operated by your team from handover.
Who it is for
Organizations replacing an unmanaged secrets estate, re-evaluating their position after the Vault licence change, or standing up secrets management properly for the first time as part of a platform build. It is most valuable where credential handling has become an audit question rather than only an engineering one.
What happens next
Most clients follow with an Open Source Assurance retainer covering OpenBao and the other components in their critical path, or hand day-2 operations to us while their platform team focuses on developer experience.
Interested?
Let us know your situation and the decision at hand. We will reply with a scope, a price, and an honest verdict on whether this implementation is the right step.