I tested 7 secrets managers in 2026 and graded them by DX. — Vincent Chan<br>Vincent Chan — Designer, Engineer & Founder in Vancouver<br>I am a designer, engineer, and founder living in Vancouver, Canada. I was involved in 0-1 founding roles of several companies, including TetraScience, Webacy, and SpaceList.<br>Today I am focused on building Capy, a secrets management platform so painless to use, you forget secrets are even something you need to worry about.<br>Writing
I tested 7 secrets managers in 2026 and graded them by DX.
May 30, 2026<br>The biggest problem in security is lack of good Design
May 19, 2026<br>Why I'm building a SaaS company during the SaaSpocalypse.
March 24, 2026
vincent chan.I tested 7 secrets managers in 2026 and graded them by DX.<br>Back
By Vincent Chan<br>A couple of weeks ago I argued that poor DX is actually the reason why people leak secrets. To inform how I'm building Capy, I signed up for every modern secrets manager and graded each one's DX against a fixed rubric.
The rubric
This test is meant to assess one thing: developer experience. Every tool went through the same setup and the same checklist, scored on four criteria, each from S Tier (effortless) down to F Tier (the tool fights you). I neglected feature-set, since there are already plenty of feature comparisons out there, and every single one of these solutions is better than having nothing in place.
The reference stack
I modeled it on the typical stack a fast-moving team runs — especially one that doesn't yet have a secrets manager:
LayerChoiceTeam5 developersServicesweb app + API + background workerHostinga PaaS like Fly.io or RailwayDatamanaged Postgres and RedisThird-party keysStripe, OpenAI, ResendCI/CDGitHub ActionsLocal dev.env filesEnvironmentsdev, staging, prod
The checklist
Onboarding is more than the first command. To grade it, I ran every tool from install to offboarding:
Install and authenticate.
Import the existing .env and run locally.
Share across five developers with access control.
Wire up the three environments.
Inject at deploy on the PaaS and in CI.
Stand up the lifecycle: rotation, expiry, auditing, offboarding.
The four criteria
Onboarding carries the most weight, because a tool you never finish standing up protects nothing.
Onboarding experience (40%). How fast you stand the tool up on the fixed stack, across two clocks: time to your first real secret, and time to fully set up (whole team shared, all three environments deployed, lifecycle in place). S is effectively a single command; A is under an hour; B a few hours; C about a day; D one to three days; F more than three.
Daily friction (30%). Reading, writing, syncing, switching environments. Does the secure path disappear into commands you already run? And does it stay visible to the security team, or go dark on them?
Access control & revocation (20%). The everyday experience of managing who can read what: adding a teammate, scoping what they get, cutting them off cleanly the day they leave.
Environment & scope (10%). Keeping dev, staging, and prod apart without hand-maintaining a permission matrix.
The tools, one by one
The writeups below are highlights and lowlights I experienced while using each tool. The commentary is primarily done through a UX and DX lens.
Doppler
Doppler was the one that made me nod. It's the most polished developer experience in the group: a quick, predictable CLI, secrets that follow you from local dev into CI and prod without copy-paste, and a run wrapper that keeps your app code from ever learning Doppler exists. Onboarding takes minutes and daily use all but disappears, which is what puts it at the top of the pack. Its one real ceiling is access granularity — more on that below. Team is $21/user/month, free up to three users, and service accounts don't count as seats — a quiet win for machine-heavy teams.1
Onboarding experience
What struck me first was the breadth of connectors and how clean the CLI felt: everything bootstrapped from the terminal, with the CLI handling the whole flow. doppler login, doppler setup, doppler run -- npm start, and the service had its secrets while the code stayed untouched. Twenty-plus integrations meant the same secrets flowed into GitHub Actions and the Fly deploy without copy-paste, so standing up all three environments ran about 30 to 45 minutes end to end.
Daily friction
One detail I appreciated: doppler run --mount hands secrets to the app through a Linux named pipe that gets wiped the moment the process exits, so the values stay off disk. The rest of the time you barely think about it — doppler run -- wraps whatever command you'd run anyway, and editing a secret in one config syncs it everywhere that config is referenced.
Access control & revocation
You invite a teammate from the dashboard or the CLI and scope them with environment-level roles, and cutting someone off is immediate, and you skip the rotation scramble. The knock people raise is that access scopes by...