Local-first vs cloud secret managers for developers (2026)

This is usually framed as a competition. It isn't. The two approaches solve different problems, and the reason the debate persists is that people compare them at the wrong layer.

Cloud secret managers solve distribution and governance: getting the right secret to the right service, proving who accessed it, rotating it automatically, revoking it when someone leaves. Those problems require a server.

Local-first vaults solve developer ergonomics and exposure: having your own keys organised, encrypted, and reachable in two seconds without a network round trip — so you stop leaving them in .env files.

A team that only has the first still has developers with plaintext .env files on laptops. A team that only has the second cannot run production. Almost every mature setup uses both, and the interesting question is where the boundary sits.

We build a local-first vault, so weigh the framing accordingly. We've tried to be accurate about what it can't do.

---

The short version#

---

1. What "cloud secret manager" means#

Three fairly different families get grouped under this label:

• Cloud vendor stores: AWS Secrets Manager, GCP Secret Manager, Azure Key Vault. Deeply integrated with their own IAM, which is the main attraction — an app can read a secret via its instance role with no stored credential.
• Team SaaS: Doppler, Infisical, 1Password's service accounts. Focused on developer and CI workflow, usually with a good CLI.
• Self-hosted platforms: HashiCorp Vault, OpenBao. Most capable, highest operational cost.

What they share:

• RBAC — who may read which secret
• Audit logs — who read what, when, from where
• Rotation hooks, sometimes fully automated
• Dynamic secrets — Vault's distinguishing feature: it generates a short-lived database credential on request, valid for minutes. There's nothing durable to leak, which is categorically stronger than rotating a static secret well.
• Central revocation — one action removes access everywhere

That list is why production runs on these. None of it is achievable without a server.

---

2. What "local-first" means#

Secrets stay on the developer's machine and there's no backend to sync to. Examples: PassStore on macOS, pass with a local GPG key, KeePass with a local database.

What they offer:

• No network round trip. Copying a key is instant, which matters more than it sounds — see the latency section below.
• Works offline, always. Not "works from cache" — there was never a server.
• Fewer parties in the trust chain. No vendor, no jurisdiction question, no subscription that can lapse.
• No account to compromise. No credential-stuffing surface, no support-desk social engineering path.

What they cannot offer:

• No central audit. There's no server, so there's nothing to log. If you need to prove who read a secret, this is disqualifying.
• No sharing. Deliberately. Sharing needs access control and revocation, which needs a server.
• No automated rotation. You rotate at the vendor and update your entry.
• No recovery. No account means nobody can reset your master password. Forget it without a backup and the vault is gone.
• Per-device. Multiple machines means manual export and import.

---

3. Side by side#

---

4. Latency is not a vanity metric#

The usual objection to local-first is that a couple of seconds doesn't matter. It matters because of what people do instead.

A developer who needs a key twenty times a day, and waits through a CLI auth prompt and a network call each time, will do the rational thing: copy the value into a .env file once and stop paying the cost. That file then sits in the project tree for months.

This is the mechanism behind most .env sprawl. It isn't ignorance — it's a predictable response to friction. The security property you actually want is "the secure path is the fastest path," and any tool that loses on speed loses on adherence.

Cloud managers can win this too — op run and doppler run inject at process start with no plaintext on disk, which is genuinely good. The point isn't cloud-versus-local, it's that a workflow people route around provides no security regardless of its architecture.

---

5. The hybrid most teams converge on#

Two rules keep it coherent:

One owner per secret. If a value exists in three systems, at least one is stale, and you'll discover which at the worst possible moment. Everything else holds a pointer, not a copy.

Production credentials never reach laptops. The most-broken rule in secret management. When someone genuinely needs production access, that's a break-glass process — documented, time-boxed, audited — not a value pasted into a local file. Break-glass is exactly what cloud managers are good at, and exactly what local vaults cannot provide.

---

6. How to decide, concretely#

Ask these in order:

1. Do auditors require per-read logs? If yes, you need a cloud manager. Nothing local satisfies this, and no amount of process substitutes for it. Stop here.

2. Do multiple people need the same credential? If yes, cloud manager. Sharing through a local tool means Slack, and that's how leaks happen. (Better still: issue per-developer credentials so a leak is traceable and revocable individually.)

3. Is your actual pain plaintext .env files and keys in Git? Then start with Git hygiene plus a local vault. This is the common case, it's cheap, and it can be done this afternoon. Adopting Vault to fix .env sprawl is using a control plane to solve an ergonomics problem — you'll get the operational cost and keep the sprawl.

4. Do you need short-lived credentials for databases? That's Vault's dynamic secrets, or cloud IAM auth. A different category from both options here.

5. Are you comfortable with another SaaS holding developer credential material? A legitimate question with no universal answer. For most teams the answer is yes and the risk is small. Some prefer not to expand the trust chain.

More: Doppler vs local .env management · best tools to manage developer secrets in 2026.

---

7. Compliance, without overclaiming#

Regulated environments generally require encryption at rest, access control, and an audit trail. A cloud secret manager provides all three as a product feature, which is why compliance conversations usually end there.

A local vault can reduce scope — if developer credentials never reach a third party, that processor isn't in your data flow. But it does not produce audit evidence, and anyone telling you a local-first tool satisfies an access-logging control is wrong.

What we can state factually about PassStore: no cloud sync, no account server, no telemetry that transmits secret values, AES-256-GCM at rest with Argon2id key derivation, source available under MIT. Whether that satisfies a specific clause in your framework is a question for your compliance team — not for us, and not for an engineering blog.

OWASP reference: Secrets Management Cheat Sheet.

---

8. Where PassStore fits#

Squarely in the laptop row of that table, and nowhere else.

• AES-256-GCM vault encryption, Argon2id key derivation (Security)
• Touch ID / Secure Enclave unlock; auto-lock so the readable window is minutes
• No cloud sync, no account server
• Workspace per repo, with .env groups, API keys, database URLs, SSH credentials
• Vault health audit for reused and weak values
• Clipboard auto-clear; command palette and menu bar access
• macOS 26.0+, free, MIT: github.com/ilmakio/PassStore

It does not replace your cloud secret platform, and we'd push back on anyone claiming a local vault can. What it addresses is the layer cloud managers structurally don't reach: the plaintext files on developer machines, which is where a large share of real leaks originate.

Download PassStore

---

Can I use a cloud secret manager for local development too?#

Yes, and if you already run one it's often the right call — one system, one source of truth, no sync question.

# Inject at process start, no plaintext on disk
doppler run -- npm run dev
op run --env-file=.env -- npm run dev

Both are good patterns. Consider adding a local vault only if: you work offline often, you dislike a network dependency on your inner loop, you want your personal keys outside the company system, or the CLI auth flow is slow enough that people are copying values into .env to avoid it.

Watch for that last one specifically. It's the failure mode, and it shows up as .env files reappearing despite a perfectly good cloud manager being available.

---

Isn't storing secrets locally less secure than a managed service?#

Not inherently, and the framing hides the real trade-off.

A well-built local vault and a well-built cloud manager both use sound cryptography. The differences are structural:

Cloud adds: audit, sharing, rotation, revocation, recovery, multi-device. Also: a vendor to trust, a network dependency, a subscription, and an account that can be attacked.

Local adds: no third party, no network, no account, verifiable behaviour if open source. Also: no audit, no sharing, no recovery.

For production, cloud wins decisively — governance is the entire job. For one developer's own test keys, the calculus flips: audit and sharing are worthless to you, while "no vendor, no account, works on a plane" is worth something.

The genuinely insecure option is neither. It's the plaintext .env file that exists because both alternatives felt like too much work.

---

Related#

• Local-first secrets for developers
• Doppler vs local .env management
• Open source secret managers compared (2026)
• How to manage secrets without using cloud tools
• Guide: Secret manager for macOS