Secrets management is a pretty tricky subject. It’s hard to get right, and even harder to make it a good user experience.

And yet, I’m going to recommend something that might not come to mind when you think of good UX: HashiCorp Vault.

In short, HashiCorp Vault is kind of like 1Password, BitWarden, or KeePass — a password and secrets manager — but designed for technical teams, companies, and developers. It goes way beyond your everyday password manager. Vault integrates with tons of systems, supports automatic secret rotation, multiple secret engines, and (most importantly for me) a variety of authentication methods.

So why is secrets management tricky, and when do you actually need it?

Why Secrets Are Hard (and When You Need to Manage Them)

At CodeCannon, we deal with three main use cases for managing secrets and having a shared repository.

Local Development

When developers install our CodeCannon app locally, they sometimes need access to production API keys — for example, a mailing client or the OpenAI API.

The simplest (and worst) way to handle this is to just send people the secrets directly. They store them somewhere, and that’s that. But this approach has a few obvious problems:

• You’re probably using an insecure transfer method (Discord, Slack, email, or sketchy “secret sharing” sites like PrivNote or OneTimeSecret).
• When someone leaves the company, you’ll need to rotate or revoke those secrets — which means recreating keys and resending them manually.
• It’s just cumbersome. Gathering, sharing, and updating secrets by hand is a waste of time.

For this use case, you could get away with a shared vault in something like 1Password or KeePass. These don't really offer anything in way of automation, but they can work fine for local development. As soon as your workflow grows beyond that, it starts breaking down.

GitHub Actions

Sometimes you need secrets for your CI/CD pipelines. GitHub Actions has built-in environment secrets, which work fine — until you need to update them.

If you share the same secret across multiple repositories or workflows, every rotation means updating each one manually. That’s painful and error-prone.

Kubernetes Clusters

Services running in Kubernetes also need secrets. One option is to Base64-encode secrets manually and upload them to your cluster — or to use something like Sealed Secrets.

Those approaches work, but they’re inconvenient if you also need the same secrets in other places, like GitHub Actions or external services that don’t have access to your codebase.

That’s where Vault comes in.

How We Use Vault at CodeCannon

We run a Vault server that stores most of our secrets. We use a few authentication mechanisms, mainly:

• Kubernetes cluster authentication, and
• GitHub workspace authentication.

Here’s how it works:

Secrets are stored in Vault (usually in a key-value store). Developers can access them using their GitHub personal access token. If a user is part of our GitHub workspace, they automatically get access to the secrets they need for development.

When they clone a CodeCannon repository, all they have to do is run make env. The script fetches secrets from Vault, authenticates via their GitHub token, and saves them locally.

In Kubernetes, we use the External Secrets Operator, which syncs secrets from Vault using Kubernetes authentication.

In GitHub Actions, a simple script connects to the Vault API, authenticates with GitHub credentials, and fetches whatever secrets it needs.

Everything is programmatic and automated. When a secret updates in Vault, that change propagates to all consumers — usually automatically, or with one command.

Sounds like a great developer experience, right?

It is — once it’s running.

Vault Setup Is a Nightmare

A friend once told me:

“Vault is a foot gun.” - A. Friend

And I get it.

Setting up Vault is not for the faint of heart. The documentation isn’t necessarily bad, but it assumes deep knowledge of Vault’s core concepts before you can even get started. Debugging? Also a pain. You’ll spend half your time wondering what broke and how to fix it.

Vault does have a UI, but it’s limited. It works for basic tasks and some configuration, but a lot of options simply aren’t available there — meaning you’ll end up diving into the docs and doing everything through the CLI anyway.

Once Vault is up and running, I’d give it an 8/10 for usability.

But the setup process? A 3/10 — and that’s generous. Expect some self lobotomizing urges and hope you don't have to debug your configs.

Final Thoughts

Vault has plenty of advanced features we don’t use (yet), but it’s nice to know they’re there if we ever need them.

If you want to improve your developers’ lives and ruin your DevOps team’s weekend, look into Vault. When it works, it’s a dream. When you’re setting it up, it’s pure pain.

It’s kind of like Kubernetes that way. Or come to think of it, like DevOps in general.

Hope you found this useful! I’d love to hear about your own secrets management setup — do you use Vault or something else entirely?

Thanks for reading, and see you next time.