This is the fourth part of a multi-part series on OpenBao's features.

Last time we talked about how to declaratively configure audit devices and initialize OpenBao. We saw how this made integration of OpenBao in a wider ecosystem or product (such as EdgeX) easier.

Like the last part, this part focuses on the operator experience, but for consumption of OpenBao's plugins: auth methods, secrets engines, auto-unseal devices, and more.

Our motivation here is to build towards a more OpenTofu-like, extensible ecosystem. Easier consumption, community-maintained plugins, and a future plugin registry will lead to more developers writing plugins and expand the usefulness of OpenBao for everyone.

Slides and content from Michael's talk at Open Source @ Siemens 2026, diving into OpenBao's origins and why it is the sustainable choice.

For a video, see Siemens' official YouTube channel.

Welcome everyone to my talk on OpenBao and sustainable secrets management! I'm Michael "Hofi" Hofer, CTO at Adfinis and Chair of the OpenBao Technical Steering Committee (TSC).

It's fantastic to be back here in Zug for Open Source @ Siemens - for me personally, this event is always an annual highlight. Huge thanks to the Siemens crew for organizing such a great event! Every year it gets better, and this time we even have romantic ambient lighting to go with it. I'm already looking forward to next year.

Also, a quick shout-out to Jan and Pasquale for the overview on CIP earlier. It's really cool to see a neighboring Linux Foundation project in action.

Today I want to share how we can ensure secrets management remains open, community-driven, and sustainable for decades to come.

This is the third part of a multi-part series on OpenBao's features.

In the past few parts, we talked about low-level technical features that OpenBao core maintainers and plugin authors can take advantage of to make secrets management safer and more scalable.

This part focuses on something that applies to operators of OpenBao: better operator experience for initial configuration. We focus on one question:

This is second part of a multi-part series on OpenBao's features.

Today we focus on transactional storage. While the earlier blog posts focused on the what and how of transactions in Raft, this post will focus on the measurable impact of transactions in OpenBao and their lack in Vault. We will demo some possible ways of creating snapshots which cannot restore and are not consistent on Vault and show how we used transactions to achieve consistency on OpenBao.

At Open Source Summit North America, I met Dr. Justin Cappos, professor at NYU and major OpenSSF contributor and working group lead, and several of his students.

Along with broader discussions of how OpenBao and gittuf might integrate, we talked about Shamir's unsealing and its fundamental problem: it is a side-effecting process with high-entropy results. You can wrap it around a common dictionary, hex or base64 encoding, or other means to make the key shares more consumable by humans, but the results will still be complex and hard to input and store.

The problems I'm looking for a scheme to solve are two fold:

This is the start of a multi-part series on OpenBao's features.

Nearly every single networked interface returning a list of results supports subsets. SQL supports the LIMIT and OFFSET keywords, along with a rich language for filtering returned results. Google Cloud KMS APIs supports pageSize, yielding a nextPageToken, for iterating over multiple pages of results.

Many resources in Vault and OpenBao return lists: KVv2 secrets, PKI's certificate lists, SSH's roles, and more.

Paginated lists were shipped in OpenBao v2.0.0 as our very first feature in our very first release!

So, why doesn't Vault support paginated lists?

Slides and content from Alex's Open Source Summit NA 2026 talk, describing the horizontal scalability features of OpenBao.

For a video, see the Linux Foundation's official YouTube channel.

Welcome everyone to my talk on OpenBao and how we added horizontal scalability to the project. I'm Alex Scheel, Head of OpenBao Development at ControlPlane, a long time member of the OpenBao TSC, and chair of the OpenBao Development Working Group.

I've been fortunate to have a hand in the development of OpenBao since nearly the beginning of the project, and before that, at HashiCorp's Vault CryptoSec team.

If, like me, you were wishing you could get out for a post-lunch walk, thank you for staying, but we'll have to settle for some photos of Minneapolis I've sprinkled through the presentation. And thank you all for visiting Minnesota, whether from near or far!

Summary​

In this blog post, I will give you an overview of the new Horizontal Scalability feature of OpenBao, its (current) limitations and planned future developments. In the second part, I will show some benchmarks to see in which cases the new feature helps (spoiler: it works best in read-heavy workloads, but doesn't improve write-heavy workloads).

As the summer of 2025 closed, OpenBao's Dev WG and TSC put together and approved a new technical direction and roadmap for 2025-2026. But before we get into the details, I think is important to look back at and celebrate what all we've accomplished this year:

1. Many technical initiatives have landed, from namespaces to transactional storage, to CEL support, and many smaller things in between.

2. Many continuing working groups and large technical initiates have been started, from the horizontal scalability WG, focused on read scalability; the UI WG, focused on a rewrite of our EmberJS Web UI into React; to the PKCS#11/KMS WG, focused on including external keys into OpenBao. Thank you to everyone who participates in these!

3. Many, many contributions from many, many contributors! We welcomed:

   • 741 commits to main,
   • 287 contributors in the past year,
   • 10 new committers, and
   • 4 new moderators!

   And like I say nearly every meeting, a special thanks to all net-new contributors! A fresh set of eyes brings wonders to a storied project, and often revisiting earlier design choices let us improve the experience.

And yes, not everything on the 2024-2025 roadmap was completed. Don't worry, you can still contribute items from it if you want! But for a community just starting out, with its first formal direction proposal, I think the response we got exceeded my wildest expectations.

Imagine starting a mentorship program with a big goal and... not a perfect plan. Sound familiar? That was us, three months ago. We had a brilliant mentee, Fatima Patel, a crucial feature for OpenBao’s roadmap, and a healthy dose of "let's figure this out as we go."

Spoiler alert: it worked. Spectacularly. But not because we had all the answers on day one. It worked because we treated the mentorship itself like an open-source project: we iterated, adapted, and optimized for success in real-time.

This is the story of how we structured—and restructured—a 12-week program that ended up giving OpenBao a scalability boost and fantastic contributions.