I've been on a bit of a "install random dev tools and see if they actually hold up" kick lately, and this time I pointed it at Dopbase. It's a secrets manager that claims to be a server, admin UI, REST API, and CLI all packed into one binary. No sponsorship, nobody paid me for this, I just grabbed it, installed it clean, and tried to break it. Here's what happened.
What I actually did, for context: installed it from a clean machine, read the install script before running it, bootstrapped the server, created a multi-environment project (development / staging / production) with six realistic secrets, rotated a key in production only, cut a CI token and used it non-interactively, tried every export format, ran an import --dry-run, took a backup, and killed the server mid-command just to see what would break. Everything below is copy-pasted straight from the terminal, not paraphrased from docs.
Every team eventually reinvents the same bad system for secrets. A .env file gets copied around Slack, a secrets.example.env sits three keys out of date, and there's always one person who "just has the prod values somewhere." It's fine until it isn't. Someone commits .env by accident, or the one person with the values goes on vacation right when staging breaks.
The usual fix is Vault, Doppler, or Infisical. They all work, but they all mean setting up another service, another auth flow, and for the hosted ones, another subscription. For a two-person side project or a small team that just wants secrets to stop living in Slack DMs, that's a lot of infrastructure to adopt for what's basically a glorified key-value store.
Dopbase's pitch is simple: one binary. Server, admin UI, REST API, and CLI client all in a single executable. No Postgres to provision, no Docker Compose file with six services in it. I wanted to see if that claim actually holds up, so I installed it clean and ran it end to end.
Before running any install script off the internet, I actually read it first. Worth doing for anything that pipes into sh. It turned out to be a plain POSIX script: it detects your OS and arch, downloads the matching release archive from GitHub, verifies it against a checksums.txt with sha256sum or shasum, and only then extracts and installs. No curl | sudo bash nonsense, no silent background daemon getting installed behind your back. It just drops a single dopbase binary into ~/.local/bin. That's the whole thing.
That setup token gets printed once, to your terminal, on first boot. Not emailed, not defaulted to admin/admin. You paste it into the Admin UI (or hit the setup URL it prints) to create the first admin account. It's a small thing, but it's the kind of small thing that tells you someone thought about the "what if this box is internet-facing for thirty seconds during setup" case.
This is usually where I bail on a "secrets manager" tool, because half of them want you to define a whole dopbase.yaml before you're even allowed to set a single value. Dopbase doesn't make you do that. I set up a fake project, acmeshop, a shop backend with a Postgres URL, a Stripe key, a JWT secret, a Redis URL, an email API key, and a Sentry DSN, all from one plain .env file:
One command, and all six secrets got imported and encrypted server-side. Listing them back doesn't show values by default:
You have to explicitly ask to see a value, and it re-prompts for your password before it'll actually show it:
Same story for export. Dumping secrets to a .env file or stdout requires a fresh password confirmation every single time, even if you're already logged in. That's a deliberate bit of friction and honestly I liked it. Most tools let a valid session token do anything a human can do. This one draws a line between "read metadata" and "see plaintext," and makes you prove you're still you before it lets you cross it.
A real app is never just one environment. So I cloned development into staging and production:
Then I rotated the Stripe key in production only, the way you'd do after an actual key leak or just a routine rotation:
Production shows version 2, development is still stuck on version 1. That's exactly what I want to see when I'm trying to answer "did staging actually get the new key or not" in the middle of an incident.
Running an app with secrets injected, with no .env file ever touching disk, works exactly the way you'd want dotenv to work:
Under the hood it fetches the environment and injects everything as env vars into the child process only. The values never get printed to your terminal.
The realistic version of "run this in a pipeline" isn't your own logged-in session, it's a scoped token that a GitHub Actions job uses. I created one for production with a 30-day expiry:
That's the only time the raw token gets shown, same "shown once" pattern as the setup token. Then I used it exactly like a CI runner would, with no interactive login at all: