By Vincent Chan
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:
| Layer | Choice |
|---|---|
| Team | 5 developers |
| Services | web app + API + background worker |
| Hosting | a PaaS like Fly.io or Railway |
| Data | managed Postgres and Redis |
| Third-party keys | Stripe, OpenAI, Resend |
| CI/CD | GitHub Actions |
| Local dev | .env files |
| Environments | dev, 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
.envand 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 environment rather than by individual secret,2 so you can't hide a single key inside a config someone can already reach. Honestly, that never mattered to me (it's partly why I modeled Capy's access the same way). For a team with tight need-to-know inside one environment it could bite, but most teams I'm comparing never feel it.
Environment & scope
Dev, staging, and prod are just configs under a project, and you switch between them with doppler setup or a --config flag. Branch configs let each developer fork the shared config locally and change a value without stepping on anyone else — and since the roles are already environment-shaped, the dev/staging/prod split maps onto access without a matrix to maintain by hand.
Infisical
Infisical is the best-balanced option here, and the one I'd hand a team that wants Doppler's ease with an open-source core it can self-host later. The cloud experience is clean once it's wired, the access controls are the most thorough of the CLI-first tools, and the feature set runs well past secrets. It loses a step to Doppler and Capy only on onboarding, where it makes you start in the browser. Pro is $18/identity/month, the core is MIT-licensed, and it reaches well past secrets into PKI, SSH, and dynamic credentials.1
Onboarding experience
I used Infisical's cloud rather than its self-hosted offering. The onboarding pushed me through the UI first: sign up, click through creating a project, add secrets. Then, to get those secrets into the runtime, I had to set up the Infisical CLI separately. Compared to other CLI-first based solutions, it felt slightly more cumbersome.
Daily friction
Once it's wired, infisical run -- npm run dev is the same clean zero-code injection everyone else offers. One myth worth killing: people still assume Infisical Cloud can't read your secrets, but it decrypts server-side. Infisical dropped default end-to-end encryption back in June 2023 because zero-knowledge made audit logs and access workflows impossible to ship.3 At the tier most teams use, the vendor can read your data, same as Doppler or AWS.
Access control & revocation
The access controls are genuinely good: visual RBAC, time-boxed grants that expire on their own, and an approval flow for sensitive changes. Roles scope down to the environment and folder, so you can hand someone staging without handing them prod. The per-identity price also counts machines as users, which adds up fast in 2026.
Environment & scope
A project carries its environments — dev, staging, prod — as first-class objects, with folders underneath for structure, and the CLI switches with --env. Because permissions attach to those environments and folders, the dev/staging/prod split and "who sees what" get configured in one place.
AWS Secrets Manager
AWS is the one nobody chooses so much as inherits, and I was no exception. If your whole stack is already AWS, the real upside is cost: a few dollars a month, where the dedicated tools bill per seat. But the developer experience leaves a lot to be desired wherever you run it. The honest reasons to reach for it are that it's already there and that it's cheap. The quality of experience is beside the point, and using it well probably costs far more than a turnkey product would. Pricing is legible at $0.40/secret/month plus $0.05 per 10,000 calls — about $6/month for fifteen secrets.4
Onboarding experience
There's no run wrapper, so getting a secret into an app means a boto3 call you write yourself: client setup, error handling, and a caching layer around what is ultimately one value — all after creating an IAM role and a resource policy. SDK code in every service, IAM before the first secret. The work is the plumbing around it.
Daily friction
The friction lives in the SDK. AWS's own guidance has you spreading the pieces across Secrets Manager, KMS, IAM, and Parameter Store, so "where do my secrets live" ends up with four answers. The one thing it gets right by default: every read lands in CloudTrail automatically,5 so the security team always has the log.
Access control & revocation
Access is IAM, which is powerful and verbose in equal measure. Granting a teammate a secret means writing or attaching a policy; cutting them off means editing it, and for a value they might have read, rotating the secret too. It's the most granular model here and the least pleasant to operate.
Environment & scope
AWS lacks a real "environment" primitive for secrets. You fake it by namespacing — /myapp/prod/... versus /myapp/staging/... — and scoping IAM policies to those paths, or, the way AWS actually recommends, by running a separate account per environment. Either way the dev/staging/prod split becomes one more IAM matrix to maintain by hand.
HashiCorp Vault
Vault is the one I have the most scar tissue from. None of that is the product being bad; it's the product being a platform you operate, with audit devices that refuse to serve a request they can't log6 and genuine dynamic secrets that expire on their own. For a regulated team that has to answer an auditor, that rigor is the point. For a fast-moving team it's a different planet, which is why it lands where it does. The licensing has shifted, too: BSL since 2023 (which spawned the Apache-licensed OpenBao fork now in production at GitLab), IBM ownership as of February 2025, and the managed SaaS reaching end-of-life on July 1, 2026. After that, the cheapest managed Vault you can buy is HCP Vault Dedicated, at roughly $1,870/month for a ten-client tier.7
Onboarding experience
A teammate of mine ran a Vault rollout at a previous company; getting it end to end — servers provisioned, deployed, secrets actually flowing into the stack — took over a month, a big chunk of it rewriting apps to pull secrets the Vault way. You hand-write a vault.hcl, run vault operator init (five unseal keys and a root token fall out), and unseal it. Enrolling users was its own slog — every new teammate a multi-step wiring job rather than a one-click invite.
Daily friction
For everyone else it's heavy in ways a feature list never shows. Every new person or service gets wired into an auth method (OIDC, LDAP, or AppRole), mapped to an identity, and handed an HCL policy that spells out the exact paths they can touch, so onboarding one teammate is effectively a small infra ticket. You re-enter three of those five unseal keys by hand every time the server restarts, and each service needs its own Agent sidecar just to read a secret, since Vault expects sidecars instead of a run wrapper.8
Access control & revocation
Access is policy-as-code: HCL policies bound to tokens and auth methods, granular down to the path. Revocation is genuinely strong — dynamic secrets carry a TTL and expire on their own, and you can revoke a lease or token outright. It's the most capable model here, and the most work to wield.
Environment & scope
You separate dev, staging, and prod with their own KV mounts or path prefixes, and grant access with policies scoped to those paths; Enterprise namespaces give harder, tenant-style isolation. It's as flexible as you want, and exactly as much hand-maintenance as that implies.
Akeyless
Akeyless is Vault's capability without Vault's operations. Most of the same toolkit — dynamic secrets, rotation, certificates, KMS, machine-identity governance — arrives as SaaS. The catch is the one that lands it here: it's an enterprise platform. For a regulated or machine-heavy shop that wants Vault's power delivered as SaaS, that's a strong trade; for a five-person team on a PaaS, it's more than the job needs.
Onboarding experience
Standing it up is closer to a few configuration screens than a cluster build. Reviewers on Gartner Peer Insights rate it noticeably easier to use than Vault (around 9.0 versus 7.6) and rate its support higher, and the recurring line is that they integrated the same things they would have with Vault, just faster.9 For dynamic or cached secrets you also run a Gateway in your own environment — a single Docker or Helm command to stand up, but still one more thing to operate.
Daily friction
Day to day it's CLI and console rather than a run-style wrapper you forget about. Once the Gateway is up it brokers the dynamic secrets and caching, so static secrets stay simple while the fancier paths carry a little infrastructure with them.
Access control & revocation
You define auth methods and access roles, binding each identity to the paths it's allowed to touch. The architecture is genuinely distinctive: Distributed Fragments Cryptography splits the encryption key so Akeyless never holds a complete copy — a real zero-knowledge-style guarantee. Revoking a role or rotating a dynamic secret is first-class.
Environment & scope
Secrets sit under a path hierarchy, so dev, staging, and prod become path prefixes with access roles mapped onto them, and a Gateway can sit per environment. It's the Vault way of scoping by path and policy, with a friendlier console on top.
1Password
I've used 1Password as a password manager for years. It's lovely the moment you're already inside it, and the cracks show the moment you need it to support infrastructure. Built for people, and stretched the moment you point it at machines. Business is $7.99/user/month with the developer tools bundled in.1
Onboarding experience
It's lovely to get started with: op run -- npm start behind a Touch ID prompt, and the local .env environment targets were genuinely smooth once set up. The slog is the import. Pulling vault values into a .env was a lot of clickOps: there's no command that just imports your existing file, so it's op item create one secret at a time, or the desktop-app Environments importer (still in beta) that produces a stored Environment rather than vault items, and it runs only in the desktop app.10
Daily friction
Once it's loaded, op run is pleasant. Push it toward machines and the password-manager bones show: reads cap at 10,000/hour on Business, with the API telling an over-eager service to come back in 59 minutes.10 Dynamic secrets and built-in rotation are both missing.
Access control & revocation
Sharing is vault-shaped: you add a teammate to a shared vault and they see what's in it. For machines it's clunkier — service-account permissions are immutable, so changing scope means recreating the account. Fine for people, awkward for a fleet.
Environment & scope
There's no native dev/staging/prod primitive. You model environments as separate vaults, or lean on the beta Environments feature for local .env targets. It works, but you're managing environments by hand, one vault at a time.
Capy
This is what I'm building, and I'm happy with where it landed against the rest. The model is genuinely zero-knowledge: Capy stores only ciphertext and can't read your secrets. That comes with honest tradeoffs, and I've put them in the sections below rather than bury them. The short version: it's the quickest, lightest way to a well-rounded setup that just works out of the box — and I'd point you at Doppler or Infisical the moment you need a non-engineer dashboard, or Infisical specifically for more granular access.
Onboarding experience
The reaction I keep seeing on someone's first run is some version of "wait, that's it?" You run capy, it opens a browser to log in, encrypts the .env you already have, uploads ciphertext, and rewrites the file with references — and about ninety seconds later the app is reading real secrets through process.env with nothing in the code changed.11 Getting to production is one more command: capy deploy pushes those secrets into your infrastructure, either through native integrations or as plain environment variables for everything else.
Daily friction
A committed keep.lock shows a secret change in a pull request the way a schema migration would. The honest cost is enrollment: because there's no server-held key to hand out, adding a teammate — or your own second machine — isn't a one-click invite. The new device has to be enrolled through capy transport, a key handoff from an already-trusted machine. It's the price of the security model, a real step that a server-trust tool like Doppler skips, and it's why daily friction lands at a B+ rather than an A. There's also no web dashboard, which for a developer-first team is a feature (everything stays in the terminal and in git, the same place your code already lives) and a gap only if non-engineers need to manage secrets themselves, where Doppler's or Infisical's console earns its place.
Access control & revocation
The part I'm proudest of is offboarding: one capy kick makes a teammate's key material inert on the spot — an O(1) cryptographic revocation that skips the rotation scramble. The honest tradeoff sits right next to it: the team custodies its own passphrase at creation, and it's irrecoverable if lost. Finer-grained, per-secret access isn't there either, which matters at enterprise scale and rarely for a fast-moving team.
Environment & scope
Secrets travel with the branch, so capy checkout staging lines up with git checkout staging. Dev, staging, and prod ride along with the git branches you already have, so your environments stay in step with your branches automatically.
Which one is easiest to set up?
For a fast-moving team, onboarding is the foremost question: which one is easiest to adopt, lightest to run, fastest to get a team onto. Same checklist, every tool:
| Tool | Get started | Share with the team | Full setup | Grade |
|---|---|---|---|---|
| Capy | one command, ~1 min | capy invite, one command, scriptable | ~20 min | S |
| Doppler | ~5 min (login/setup/run) | dashboard or CLI invite, env-scoped roles | ~30–45 min | A |
| Infisical | ~10 min (sign up, install, init) | dashboard invite + an RBAC role | ~1 hr | A− |
| 1Password | ~10–15 min (needs the desktop app) | shared vault (people easy; machines need service accounts) | half a day to a day | C |
| Akeyless | ~30–60 min (SaaS account + auth method) | RBAC roles and auth methods in the console | ~1 day (more with a Gateway) | C |
| AWS Secrets Manager | ~30–60 min (IAM role + first SDK call) | IAM users/roles plus a policy per secret | ~2 days | D |
| HashiCorp Vault | ~half a day (install, init + unseal, agents) | auth methods, policies, and tokens to hand out | 3 days-plus | F |
CLI-first tools share a secret in a command or two, while the heavier options make you write IAM policy or HCL first. For a fast-moving team, that gap is the difference between onboarding a solution in minutes or losing a day or a week to it.
Overall developer experience
Each grade is the weighted average of the four criteria: onboarding (40%), daily friction (30%), access control (20%), environment & scope (10%).
| Tool | Onboarding (40%) | Daily friction (30%) | Access control (20%) | Env (10%) | Grade |
|---|---|---|---|---|---|
| Capy | S | B+ | A | A | A |
| Doppler | A+ | A | A− | A | A |
| Infisical | A− | A | A | A | A− |
| 1Password | C | A+ (existing users) | C+ | B | B− |
| Akeyless | C | C+ | B | B | C+ |
| AWS Secrets Manager | D | C+ | C+ | B | C− |
| HashiCorp Vault | F | C | B | A | C− |
Capy and Doppler tie at the top with an A, Infisical a half-step behind at A−. Among the three it's a fit decision: Doppler for the broadest integrations and a dashboard non-engineers can use, Infisical for a mature open-source platform with a broad feature set, Capy for the quickest path to a setup that just works out of the box.
Which one for your team
Everything above grades one thing: developer experience. That focus is deliberate — poor DX is the main reason secrets management goes unadopted, and a tool a team never fully adopts secures nothing. But DX isn't the only reason to choose a tool, and each one here is genuinely the best answer to some question. Capy's claim is narrow: it ties for the best developer experience of the group, and leads outright on onboarding. Here's the honest case for each, played to its real strength:
| If your priority is… | Reach for | Because |
|---|---|---|
| The best developer experience — the quickest setup that just works | Capy | fastest path to shared, deployed, zero-knowledge secrets |
| The widest catalog of native integrations and a polished multi-user dashboard | Doppler | years of ecosystem breadth; syncs into nearly everything |
| A mature open-source platform with a visual console and broad features (PKI, SSH, dynamic secrets) | Infisical | MIT-licensed, large community, deepest open-source feature set |
| Staying entirely inside AWS without onboarding a new vendor | AWS Secrets Manager | native IAM and CloudTrail you already operate and trust |
| One tool for both team passwords and developer secrets | 1Password | consolidates human and machine secrets in software you already run |
| Vault-class capability and dynamic secrets, delivered as SaaS | Akeyless | the Vault feature set without the Vault ops; split-key cryptography |
| Provable audit, dynamic secrets, and policy-as-code in a regulated org | HashiCorp Vault (or OpenBao) | the deepest governance and capability in the category |
Capy ties for the best developer experience, and leads on the onboarding that decides adoption. The others win on reach, openness, cloud-native fit, consolidation, and governance. For plenty of teams, the friction Capy removes is exactly the one that was blocking adoption.
What goes next?
Every tool here makes secrets easier to handle, but none of them addresses the whole problem. Every time we add more rules and controls, we also raise the onboarding cost — and that higher cost is exactly what drives failed adoption for more and more teams. It's counterproductive.
And the problem keeps growing. We're now at 29 million new secrets leaked every year,12 now joined by AI agents that write millions of commits a month and leak secrets at twice the human rate.13 More services, more identities, more secrets — and piling on more manual configuration is the wrong answer. What Capy is building next is aimed straight at that — more in the next post.
Footnotes
-
Verified 2026 pricing — Doppler, Infisical, and 1Password pricing pages. ↩ ↩2 ↩3
-
Doppler Advanced Permissions docs (environment-level access only). ↩
-
Infisical Update, June 2023 (end-to-end encryption made optional); Infisical Security docs (server-side AES-256-GCM). ↩
-
AWS Secrets Manager pricing, Amazon Web Services. ↩
-
AWS Secrets Manager monitoring, AWS docs (CloudTrail always-on; per-secret IAM). ↩
-
Audit Devices, HashiCorp Vault docs (logging hard stop). ↩
-
HashiCorp Adopts Business Source License (2023); HCP Vault Secrets End-of-Life; OpenBao. ↩
-
Get Started with Vault, HashiCorp Developer; "Lessons Learned Using Vault", malgregator.com. ↩
-
Akeyless Distributed Fragments Cryptography docs; Gartner Peer Insights: Akeyless vs HashiCorp Vault. ↩
-
1Password service-account rate limits and Service Accounts docs (immutable permissions; 429 at the hourly cap; no
.envimport). ↩ ↩2 -
The State of Secrets Sprawl 2026, GitGuardian; "CISA Exposes Secrets, Credentials in 'Private' Repo", Dark Reading, May 19, 2026 (GitGuardian discovery; 844MB public since Nov 13, 2025). ↩
-
The Real Problem Isn't That AI Can't Write Secure Code, GitGuardian / The Hacker News, 2026. ↩