We are excited to introduce Namespaces to the OpenBao Secret Manager – a powerful feature designed to bring robust multi-tenancy and fine-grained isolation to your secrets management workflows.

What Are Namespaces?​

Namespaces in OpenBao are logical partitions within a single OpenBao instance, functioning as isolated environments where teams, organizations, or applications can operate independently.

Each namespace acts like a mini-OpenBao, with its own policies, authentication methods, secret engines, tokens, and identity groups. This architecture enables organizations to implement a true OpenBao-as-a-Service model, empowering internal customers to self-manage their environments securely and efficiently.

Great news for the OpenBao community! In a major step towards enhancing its own security and openness, EdgeX Foundry has officially adopted OpenBao as its default secret store for the EdgeX 4.0 release.

What is EdgeX Foundry?​

For those unfamiliar, EdgeX Foundry is an open-source, IoT/edge computing framework hosted by the Linux Foundation. It’s designed to enable seamless communication between devices, applications and services using a flexible, microservices-based architecture. Whether you’re working in automation, energy, or building management, EdgeX helps bring everything together in a standardized way.

As the OpenBao community starts development on Namespaces and the Horizontal Scalability Working Group has its kickoff, I wanted to take the opportunity to put forward a blog post describing how these two groups' work can compliment each other and provide an alternative path forward other than Vault Enterprise's Performance Secondary and Disaster Recovery clustering modes.

Slides and content from Alex's FOSDEM '25 talk about OpenBao's usage at GitLab.

For a video, see our official YouTube channel or on the FOSDEM video mirror.

Hello everyone! I'm Alex Scheel, a Staff Backend Engineer at GitLab and Chair of the OpenBao Technical Steering Committee. I'm here to talk about OpenBao and its usage at GitLab.

OpenBao returns from FOSDEM '25 and OpenUK's State of Open Con this week, reflecting on the travels and activities of the events.

Many thanks to Fatima for running the community calls in our absence!

photo credit: nicolas; pictured: alex

FOSDEM '25 was Alex's first time speaking at a conference and we are happy to report it was a success! The details of the talk were saved and will be published in a follow-up blog along with the recording when it is made available from the conference. It was great to meet so many people interested in identity and access management and OpenBao's role in solving secrets management problems, at GitLab and beyond.

Follow along with OpenBao's travels this week as we attend FOSDEM '25 and State of Open Con!

From snowy Minnesota, BaoBao took its first ride to London Heathrow to begin its voyage to FOSDEM '25. With a brief layover, it explored King's Cross and the Coal Drops Yard. Rich with history, this area has long been used as a rail hub for the UK and now is connected to Europe via the Channel Tunnel.

I'm happy to share that OpenBao will be present at two conferences in February: FOSDEM '25 in Brussels and State of Open Con 2025 in London!

The second half of 2024 saw several fabulous RFCs from different contributors to OpenBao. Here's a few worth highlighting and how you can get involved!

We are thrilled to announce the availability of OpenBao v2.1.0, focused on safety and scalability improvements!

This release spent some time laying the groundwork for safety and scalability improvements for releases to come. With the help of the community, OpenBao will now take advantage of transactional storage semantics from its underlying data store, giving operators and plugin developers confidence in the consistency of storage writes. This storage safety allows us to focus on alternative storage layouts for improving scalability, for instance, increasing the maximum number of mount table entries past the single-entry limit.

This release also features contributions from many new and repeat contributors; thank you all!

Overview​

OpenBao, like its upstream, favors the raft internal storage engine. While more complex than relying on a database for replication, this storage engine allows us to have lower latency on read operations, because it uses a local K/V implementation based on B+-trees. For workloads with low writes but high reads (typical of most uses of K/V secrets), this trade off allows for the best performance.

An earlier blog post talked about the availability of transactions in the main branch, this post will focus on the technical details of implementing transactions.