.env vs a secrets manager (Doppler, Infisical, Vault)

TL;DR

• .env files — dead simple, free, zero infra. Works until you have > 5 engineers or multiple environments.
• Secrets managers — rotation, audit, RBAC, dynamic secrets. Needed when ownership of production matters.
• Most teams use .env locally and a secrets manager in production. These aren't mutually exclusive.

When .env is enough

Plain .env files work great when:

• You're solo or have < 5 people on the team.
• Config values change rarely (once a month or less).
• Your host's dashboard handles production injection (Vercel, Railway, Fly).
• You have fewer than 20 env vars per environment.

The toolchain is just a text editor, your host's env UI, and a .env.example to document structure — generate one in the browser.

When you need a secrets manager

• Rotation: you need to replace a key and have every service pick up the new one automatically.
• Audit: you need a log of who read which secret when.
• RBAC: different devs see different subsets of secrets (prod-only for senior engineers, read-only for contractors).
• Dynamic secrets: DB credentials that rotate every hour, IAM creds scoped per-request.
• Compliance: SOC 2, HIPAA, GDPR auditors want to see these features.

The three options in 2026

Doppler

Hosted SaaS. Best UX of the bunch. Web dashboard to manage secrets, CLI to pull them into local dev (doppler run -- npm run dev), native integrations with Vercel/Netlify/Railway/Kubernetes/Docker. Free tier handles small teams; paid starts around $7/user/mo.

Pick if: you want the fastest path from .env to managed secrets.

Infisical

Open-source. Self-hostable or use their cloud. Feature parity with Doppler at a lower price point and the option to keep everything on-prem. Kubernetes-native operator for auto-injecting secrets into pods.

Pick if: you want Doppler's ergonomics but with control over where the secrets live.

Hashicorp Vault

Enterprise-grade. Dynamic secrets, transit encryption, short-lived cloud credentials, strict policy controls. Operational overhead is real — you need dedicated people to run it.

Pick if: you have compliance requirements, multi-tenant architecture, or a dedicated platform team.

Decision matrix

Migration path — .env → managed

1. Scan your .env with the leak checker. Rotate anything it flags — assume it's been in your inbox, Slack, and git history.
2. Create environments in your secrets manager (dev, staging, prod).
3. Import current .env values via their CLI.
4. Replace .env loading in your app with the secrets manager's SDK or CLI wrapper (e.g., doppler run -- node server.js).
5. Commit a .env.example (generator here) so structure is still documented.
6. Delete .env from every developer machine.

FAQ

Can I use a secrets manager for local development too, not just production?

Yes, and many teams do — running doppler run -- npm run dev locally means every developer always has current secrets with no manual syncing. The trade-off is a dependency on network access and the provider's uptime for local dev, which is why some teams still keep .env as an offline fallback.

Do secrets managers protect against a secret being logged or printed accidentally?

Not by themselves — that's an application-level mistake (e.g. console.log(process.env)) that no secrets manager prevents. What they do add is an audit trail showing the secret was read, and easy rotation once you notice the leak.

Is a secrets manager overkill for a two-person startup?

Usually yes at first — the free tiers of Doppler and Infisical remove the cost objection, but the setup and workflow overhead isn't worth it until you actually feel the pain: manual secret-sharing, a second production environment, or a compliance requirement.

What's the actual migration effort from .env to a secrets manager?

For a small app, under an hour: import the .env via CLI, swap the start command to the wrapper (doppler run -- ...), and confirm the app boots. The bigger cost is usually updating CI/CD pipelines and every developer's local workflow, not the migration itself.

One honest trade-off

Secrets managers are another service that can go down. If Doppler has an outage and you're pulling secrets at boot, your service can't start. Mitigations: cache secrets locally with TTL, use the secrets-manager-as-build-time-injector pattern instead of runtime pulls, or run a local cache sidecar.

Recommendation

For any production workload with > 5 engineers: pick Doppler or Infisical today. The rotation + audit features pay for themselves the first time you need to respond to a leaked key. Keep .env for local dev only, and scan it before sharing.