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.
The problem it's solving
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.
Dopbase
Open-source, self-hosted secrets management in a single file.
One binary contains the server, Admin UI, REST API, and command-line client
Quick start | CLI reference | Demo | Why Dopbase | How it works | Documentation | Security | Contributing | Code of conduct
The Admin UI ships inside the Dopbase executable, so there is no separate frontend to deploy.
Dopbase keeps application secrets organized by project and environment on infrastructure you control. Runtime data stays separate from the executable: its SQLite database, configuration, and master key live under ~/.dopbase by default.
Quick start
Install the latest release on macOS or Linux, then start a local server:
curl -fsSL https://dopbase.com/install.sh | sh
dopbase server start
Open http://localhost:8840 to finish setup in the Admin UI. The quick-start guide covers sign-in, importing a .env file, and running an application with its secrets.
Native release archives are available for macOS and Linux…
Installing it
curl -fsSL https://dopbase.com/install.sh | sh
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.
Downloading Dopbase 0.1.8 for darwin/arm64...
Installed Dopbase 0.1.8 to /Users/varshit.hegde/.local/bin/dopbase
Starting the server is one command:
dopbase server up
Dopbase
Secure, Simple and Private
Version 0.1.8
Public URL: http://localhost:8840
Admin UI: http://localhost:8840
API: http://localhost:8840/api/v1
Dopbase setup token (shown once):
setup_tViW7FWwlm_n7qSXjjqOM_sOy9dTN5_UyYe3ZL7sDYE
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.
Actually using it
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:
dopbase init acmeshop/development --from .env
Initialized acmeshop/development.
Project ID: prj_01M3K47BT6X81BNE54KASXEPE1
Environment ID: env_751368
Secrets: 6
One command, and all six secrets got imported and encrypted server-side. Listing them back doesn't show values by default:
$ dopbase secret list acmeshop/development
KEY VERSION UPDATED
DATABASE_URL 1 2026-09-28 04:26 UTC
JWT_SECRET 1 2026-09-28 04:26 UTC
REDIS_URL 1 2026-09-28 04:26 UTC
RESEND_API_KEY 1 2026-09-28 04:26 UTC
SENTRY_DSN 1 2026-09-28 04:26 UTC
STRIPE_SECRET_KEY 1 2026-09-28 04:26 UTC
You have to explicitly ask to see a value, and it re-prompts for your password before it'll actually show it:
$ dopbase secret get acmeshop/development STRIPE_SECRET_KEY --reveal
Password confirmation required.
? Password: ********
sk_test_51ABCDEF1234567890
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.
Multiple environments, and secrets that actually drift
A real app is never just one environment. So I cloned development into staging and production:
dopbase env clone acmeshop/development staging --yes
dopbase env clone acmeshop/development production --yes
$ dopbase env list acmeshop
PROJECT ENVIRONMENT ID UPDATED
acmeshop development env_751368 2026-09-28 04:26 UTC
acmeshop production env_555699 2026-09-28 04:26 UTC
acmeshop staging env_021195 2026-09-28 04:26 UTC
3 environment(s)
Then I rotated the Stripe key in production only, the way you'd do after an actual key leak or just a routine rotation:
$ printf 'sk_live_51PRODROTATEDKEY9876543210\n' | dopbase secret set acmeshop/production STRIPE_SECRET_KEY --stdin
Saved STRIPE_SECRET_KEY in acmeshop/production.
Version: 2
$ dopbase secret list acmeshop/production
KEY VERSION UPDATED
...
STRIPE_SECRET_KEY 2 2026-09-28 04:26 UTC
$ dopbase secret list acmeshop/development
KEY VERSION UPDATED
...
STRIPE_SECRET_KEY 1 2026-09-28 04:26 UTC
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:
dopbase run acmeshop/development -- node server.js
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.
A CI token, and proving it actually pulls the right values
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:
$ dopbase token create acmeshop/production --name github-actions-deploy --expires-in 720h
Created token github-actions-deploy for acmeshop/production.
ID: tok_01M3K47KD1YGBTGRMCBBQFEHVM
Expires: 2026-10-28T04:26:38Z
Token: dbs_D2YjuFlzupYWXYouQSoyIPt0TAZk0D4XVcUiOgnluTY
Warning: Store this token now. Dopbase will not show it again.
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:
$ DOPBASE_TOKEN="dbs_D2YjuFlzupYWXYouQSoyIPt0TAZk0D4XVcUiOgnluTY" dopbase run acmeshop/production -- env | grep STRIPE
STRIPE_SECRET_KEY=sk_live_51PRODROTATEDKEY9876543210
That's the rotated production key coming back, not the original dev value. So a deploy pipeline holding this token genuinely can't accidentally ship a stale or wrong-environment secret.
Every export needs a live human, and you can't script around it
I tried to export secrets non-interactively (piping a password, setting an env var, anything I could think of) just to see if there was some backdoor around the password prompt. There isn't:
$ dopbase export acmeshop/development --output out.yaml --format yaml --force
Error: interactive password confirmation is required for plaintext secret access
That error shows up even with --force, even with stdin piped, even inside a script. The only way to get plaintext out via export is a real terminal with an actual human typing a password into a masked prompt:
$ dopbase export acmeshop/development --output out.yaml --format yaml --force
Exported 6 secret(s) to out.yaml.
$ cat out.yaml
DATABASE_URL: postgres://app_user:pass@localhost:5432/acmeshop
JWT_SECRET: super-secret-jwt-signing-key-123
REDIS_URL: redis://localhost:6379
RESEND_API_KEY: re_123456789_abcdefghijklmnop
SENTRY_DSN: https://examplekey@o123456.ingest.sentry.io/123456
STRIPE_SECRET_KEY: sk_test_51ABCDEF1234567890
I ran the same check against every supported format (dotenv, json, yaml, toml, and docker) and they all produced clean, correctly shaped output, all gated behind the same live password prompt. This is a genuine design choice, not an oversight. export is for a human sitting at a keyboard. run and CI tokens are what you reach for when you want automation. If your mental model going in is "I'll export secrets in CI to seed another system," that workflow just doesn't exist here. You'd need run or a token instead.
I also noticed the session step-up isn't just for reveal and export, it applies to some writes too. When I tried to clone an environment a bit later in the same session, it asked me to re-authenticate before it would go through:
$ dopbase env clone acmeshop/development staging --yes
Error: recent human authentication is required. Run this command in a terminal to confirm your password
So "recent human authentication" is its own short-lived window, separate from your regular login session. It's a sensible extra speed bump for anything that touches plaintext or duplicates secrets across environments.
Importing without clobbering, and previewing the diff first
Real teams don't create secrets once and walk away. They update a .env file and need to sync the changes without wiping out keys that got added directly through the Admin UI. dopbase import handles this with a merge-by-default policy and a --dry-run flag that shows you the diff before touching anything:
$ cat update.env
DATABASE_URL=postgres://app_user:pass@localhost:5432/acmeshop_v2
NEW_FEATURE_FLAG=true
$ dopbase import acmeshop/development update.env --dry-run
Dry run complete. No changes were applied.
Mode: merge
Added: 1
Updated: 1
Unchanged: 0
Deleted: 0
That told me exactly what would happen (one new key, one updated value, nothing deleted) before I committed to anything. Running it for real without --dry-run applied that exact diff:
$ dopbase import acmeshop/development update.env --yes
Imported secrets into acmeshop/development.
Mode: merge
Added: 1
Updated: 1
Unchanged: 0
Deleted: 0
$ dopbase secret list acmeshop/development
KEY VERSION UPDATED
DATABASE_URL 2 2026-09-28 05:37 UTC
JWT_SECRET 1 2026-09-28 05:35 UTC
NEW_FEATURE_FLAG 1 2026-09-28 05:37 UTC
REDIS_URL 1 2026-09-28 05:35 UTC
RESEND_API_KEY 1 2026-09-28 05:35 UTC
SENTRY_DSN 1 2026-09-28 05:35 UTC
STRIPE_SECRET_KEY 1 2026-09-28 05:35 UTC
DATABASE_URL bumped to version 2, NEW_FEATURE_FLAG showed up new, and the five keys I didn't touch stayed exactly where they were. There's also a --replace flag for the opposite behavior, mirroring the file exactly and deleting anything not in it, which is what you'd want for a "the file is the source of truth" workflow instead of an incremental merge.
Backups are encrypted snapshots, not just a SQL dump
$ dopbase backup pre-review-test --output ./backup.dop
[1/2] Creating an encrypted backup on http://localhost:8840...
[2/2] Downloading the backup to ./backup.dop...
Backup complete.
Filename: pre-review-test.dop
Size: 18.44 KiB
Server: http://localhost:8840 (~/.dopbase/backups/pre-review-test.dop)
Saved to: ./backup.dop
Warning: This backup uses the instance master key. Restoring it on another server requires both files.
A .dop file is an XChaCha20-Poly1305 encrypted archive containing every project, environment, secret, runner token, and admin account. Not a plaintext SQLite copy you'd have to remember to encrypt yourself later. The warning at the end actually matters: the backup is encrypted with this server's master key, so restoring it somewhere else means bringing that key file along too (dopbase restore --key). That's the right tradeoff for a tool whose whole premise is self-hosting, since it means a stolen backup file alone is useless to anyone. But it also means your disaster-recovery plan needs to include the master key file, not just the .dop archive. Worth writing into your runbook on day one instead of after the first real incident.
restore mirrors this behavior. Pointed at a fresh, uninitialized server it completes the whole bootstrap for you. Pointed at an already-running instance it demands --yes plus admin credentials before it'll overwrite anything.
Some rough numbers
Nobody puts performance numbers in a "secrets manager" review, but since I had the binary sitting right there:
| Binary size | 21.5 MB (macOS arm64) |
Cold server start (server up to accepting connections) |
~450ms |
secret list round trip (localhost, warm) |
~200ms |
| Backup of a 3-environment, 18-secret instance | 18.4 KB, near-instant |
None of this is going to be the deciding factor over Vault or Doppler, but it does confirm the "single binary, not a JVM app pretending to be lightweight" pitch is real. Nothing here felt like it was warming up a database connection pool or spinning up a sidecar somewhere.
The one thing that actually impressed me
I wanted to see what happens to dopbase run if the server disappears mid-workflow, because that's the real question with any "fetch secrets from a server at runtime" tool. So I just killed it:
$ dopbase server down
Dopbase server stopped successfully.
$ dopbase run acmeshop/development -- env | grep STRIPE
STRIPE_SECRET_KEY=sk_test_51ABCDEF1234567890
It still worked. Dopbase keeps an encrypted local cache keyed by server, environment, and credential, and it falls back to that cache automatically when the server's unreachable:
$ dopbase cache list
SERVER PROJECT ENVIRONMENT ID FETCHED AGE
http://localhost:8840 acmeshop development env_751368 ... 1m
That's the difference between a cute CLI toy and something I'd actually trust in a deploy script. A secrets manager that hard-fails your build because its own server had a blip is worse than no secrets manager at all. This one degrades gracefully instead of just falling over.
What I didn't love
-
The Admin UI setup is browser-only for the first account. There's no CLI flag to bootstrap the first admin non-interactively. You either click through the setup link or hit the (undocumented) bootstrap API directly like I did. For a tool this CLI-first, I kind of expected a
dopbase admin bootstrapcommand. -
No user or role management from the CLI. Dopbase advertises four role-based permission levels, but every
dopbase --helptree I could find only manages projects, environments, secrets, and tokens. There's nodopbase user inviteordopbase role assignanywhere. If you need to add a teammate or change someone's role, that's an Admin UI trip, which kind of breaks the "I can do everything from a terminal" story the rest of the CLI tells so well. Update: I flagged this to the maintainer before publishing, and they told me proper RBAC is actively in the works for an upcoming version. They're still deciding whether it ships baked into the core binary or as an optional plugin, so people running solo don't end up carrying the weight of a permissions system they'll never touch. -
exportcan't be scripted at all, by design. I confirmed this isn't a bug. There's no flag, env var, or piped-stdin path around the live password prompt. Good for security, but if your mental model going in is "I'll export secrets in CI to seed another system," that workflow doesn't exist. You'd needrunor a token instead. - No hosted or managed option yet. It's genuinely self-hosted only right now. If you don't want to run and patch a server yourself, this isn't for you today. There's a "Cloud" section in their docs, so that might change.
-
No secret rollback from the CLI.
secret getshows a version number and eachsecret setbumps it, but I couldn't find a CLI command to view an old version's value or roll back to it. That might exist in the Admin UI. I didn't have browser access in my test environment to confirm either way. Update: the maintainer confirmed this one too, apparently a few other people have asked for the same thing, so it's not just me being picky. - It's young. v0.1.8, Rust backend, Vue admin UI, SQLite storage underneath. That's a perfectly reasonable stack for this problem, but "young" also means a small community, so don't expect a Stack Overflow answer if you hit something weird. I didn't hit anything that felt half-finished, but I also wasn't running it in production for six months.
Dopbase vs. the usual suspects
| Dopbase | HashiCorp Vault | Doppler / Infisical Cloud | Infisical (self-hosted) | |
|---|---|---|---|---|
| Deployment | One binary | Cluster-grade, multiple components | Fully managed, no deploy | Postgres + Redis + app services |
| Setup time | Minutes | Hours to days | Minutes (it's hosted) | An afternoon |
| Where secrets live | Your server | Your infra | Their cloud | Your infra |
| CI/runner auth | Scoped tokens | AppRole, many auth methods | API tokens | Service tokens |
| Offline/cache fallback | Yes (encrypted local cache) | No (fails closed) | No (needs network) | No |
| Best fit | Solo dev / small team | Large org, complex policy needs | Team that doesn't want any ops | Mid-size team wanting self-host + polish |
If your team already runs Vault or pays for Doppler, there's no real reason to switch. This isn't a "rip and replace" pitch. But if you're a solo dev or a small team whose current "secrets manager" is a .env file and pure muscle memory, Dopbase is about the least infrastructure you can put between yourself and that problem. And the offline-cache behavior I tested above is a real differentiator, not just a checkbox feature nobody actually uses.
Questions I'd ask before adopting it
Can I use this if my whole team isn't comfortable with a CLI? Yes. There's a full Admin UI, and everything I did with the CLI (create projects, set secrets, clone environments, view tokens) has a UI equivalent. I just didn't have browser access in my test environment to screenshot it.
What happens if I lose the master key? Based on the backup warning above, you lose the ability to restore backups onto a different server. Treat the master key file with the same care as the secrets it protects, and back it up somewhere other than right next to the .dop files.
Can I run this in Docker or Kubernetes? The binary itself has no external runtime dependencies since SQLite is embedded, so it should containerize the way any single Go or Rust binary does. I didn't actually test a container deployment though, this was a local macOS install.
Is my data safe if the project shuts down? It's Apache 2.0 and the binary is genuinely standalone. You're not depending on a SaaS staying up, and your ~/.dopbase data directory plus a backup file is everything you need to keep running or migrate off.
Should you use it
I ran the whole flow. Init, secret set and get, environment cloning, secret rotation across environments, all five export formats, import --dry-run, CI token creation and use, encrypted backups, and run with the server both up and deliberately killed. Nothing broke or surprised me in a bad way. The security defaults (masked values by default, password re-confirmation on reveal, export, and sensitive writes, a checksummed install script, encrypted backups tied to a master key) are exactly the kind of decisions I'd want a secrets tool to make without me having to configure them in myself.
The gaps are real but narrow: no CLI user or role management, no way to script an export, no CLI-level rollback. None of those feel like dealbreakers for the audience this is actually built for. They're the kind of thing you'd file an issue for, not walk away over, and the maintainer's already told me two of the three (role management and rollback) are on the roadmap.
It's open source (Apache 2.0), it's a single 21MB binary, and you can read exactly what it does to your secrets before you decide to trust it with them:
dopbase server up
Repo's here if you want to look under the hood yourself: github.com/dopbase/dopbase. If you end up trying it, I'd genuinely like to know what you hit that I didn't cover here. Drop it in the comments.
Top comments (0)