Why we built a self-hosted secrets manager nearly as easy as a .env file

Everyone is told to use a secrets manager, and most teams keep a .env file anyway. Here's why they're right, what self-hosting a secrets manager really costs, and what we built instead.

Every guide to running software in production tells you to use a secrets manager. Most teams keep a .env file anyway, and get called careless for it. They aren't. They looked at what the alternative costs and said no. We built RatelKey so the answer can be yes.

The file wins for a reason#

A .env file is the most successful secrets manager ever made. You write a line, your application reads it, and that's the whole setup. When the alternative costs a week of setup and a standing commitment to keep it alive, the file is the rational choice, and the industry has spent years telling people otherwise without ever making the alternative easier. Picking the file is what it looks like when the people doing the work refuse a second job nobody budgeted for.

What the file can't do arrives slowly. Someone leaves and you can't say what they had access to. A key leaks and you find it copied onto every laptop and server that ever needed it. A CI job needs one secret and gets all of them. Nobody can tell you who read what, or when. None of that hurts on day one, which is exactly why the file keeps winning.

How people leave the file#

There are roughly four ways out, and each one asks you to give something up.

Encrypt the files and commit them. The workflow stays the same and the secrets stop being plaintext in the repository. Now you manage who can decrypt them, through keys you hand out or cloud key permissions you grant, and access is still decided a whole file at a time. Knowing who opened what means setting up an audit database or reading your cloud's key logs. You've moved the problem into key management.

Use your cloud provider's secret store. Convenient if everything you run lives in one cloud, and the meter runs on every read: depending on the provider, you pay for the secrets you keep, the requests your applications make, or both. Everything outside that cloud, a second provider, a server in a rack, a developer's machine, has to be given its own way into that cloud's identity system first. Your secrets now live wherever your cloud bill does.

Pay for a hosted secrets manager. Sign up, and someone else runs everything. Your secrets live on their infrastructure, and your production systems depend on a service you don't operate being up, reachable and still in business. Their outage is your outage, and their breach is your breach.

Run a secrets manager yourself. Your secrets stay on infrastructure you own, and you decide how it's run. You also inherit all of it.

What self-hosting actually costs#

The self-hosted secrets managers on the market assume you have a platform team, and they're priced in its hours.

Some want their own database and a persistent cache running before they'll start at all. Others need storage configured, TLS put in front of them, and an initialization ceremony that hands you the keys to everything inside. Lose those and the data goes with them. Restart one of those servers and, unless you've wired it to a cloud key service, it comes back locked until enough of your keyholders type their shares back in by hand. A power cut becomes a meeting.

Then the people. Signing your team in means configuring authentication or connecting an identity provider you run or pay for. Invitations, two-factor and sign-in alerts wait on a mail server you set up. And before any of it goes near production, there's a hardening guide some twenty-odd items long, ending in a standing instruction to upgrade frequently, which you'll be rehearsing yourself.

None of it is unreasonable for a company with a platform team. All of it is a full-time job for everyone else. So teams read that list, close the tab and go back to the file, and they're right to.

What we built#

RatelKey is a self-hosted secrets manager built so that last option costs about as much effort as the file.

The secrets manager is the Burrow. You download it, run it, and it's ready. Everything it needs is built in, so there's nothing else to install or keep running. It holds your secrets organized by project and stage, versions every change so it can be undone, records every read and change, and optionally takes scheduled, encrypted backups. You decide which machines read what, from a single server to a fleet or a CI workflow, and your machines talk to your Burrow directly. They never go through us.

Everything around the Burrow that would otherwise turn self-hosting into a job, we run. RatelKey is the identity provider for your team, with two-factor, passkeys and single sign-on with your own identity provider. It sends your invitations, signs every update, and offers every Burrow an optional relay that makes it reachable from anywhere without opening a port, over a connection we can't read.

The trade we made#

Your secrets stay on your infrastructure. Signing in, email and updates run through us, because those are the parts that turn self-hosting into a job, and no team ever gained anything from running its own mail server. If you want to run every layer yourself, RatelKey isn't built for you.

For the teams who ship without a platform engineer, a secrets manager was always a good idea that came with one attached. We think it should come with a download button.

Download the Burrow

[email protected]

Building RatelKey — a self-hosted secrets manager whose decryption key never leaves your infrastructure.