The landscape
Where should development secrets live?
Six approaches hold most of this market. Each optimizes for something real, and each carries a tradeoff you accept with it. This page lays them out plainly, including the cases where Envmesh is the wrong choice.
01/Plaintext files
Plaintext .env files
The default. A file per project, read by every tool, with zero setup. Its universality is real: every framework, language, and CI system understands it.
Choose it when
- The secrets have no value — local database passwords, sandbox keys
- The project is a throwaway and will never hold a production credential
The tradeoff
Every process you run can read every key you own, and moving between machines means making copies that nothing ever revokes. This is the baseline the rest of the field exists to improve on.
02/Encrypted files
Encrypted files in the repository
dotenvx · SOPS · git-crypt · age
Keep the file, encrypt the values, commit the ciphertext. Git becomes the distribution channel, which means no new infrastructure and full version history for secrets.
Choose it when
- You want secrets versioned and reviewed alongside the code they belong to
- Your team already coordinates through git and can handle key ceremony
The tradeoff
The decryption key becomes the real secret, and distributing, rotating, and revoking that key across machines and people is left to you. Dotenvx's paid tier exists to solve exactly this gap.
03/Cloud managers
Cloud secret managers
Doppler · Infisical · Phase
A server of record with a CLI that injects values at runtime, plus the operational layer teams need: dashboards, access control, audit logs, rotation, and CI/CD integrations.
Choose it when
- Several people and environments share production secrets
- You need central audit, rotation, and access reviews — or evidence of them for SOC 2
- CI/CD pipelines consume the same secrets as developers
The tradeoff
An account, a network dependency for your source of truth, and a vendor inside your trust boundary. For a team, that trade is usually correct. For one person's own machines, it is a lot of apparatus for a local problem.
04/Password managers
Password managers with developer tooling
1Password CLI & service accounts
Extend a vault you already trust into the terminal: references in files resolve to real values at run time, SSH keys live behind biometrics, and human and machine credentials share one home.
Choose it when
- Your organization already runs on 1Password and trusts its custody model
- You want biometric-gated access and one vault for passwords and dev secrets alike
The tradeoff
Your secrets sync through the vendor's cloud, end-to-end encrypted but account-bound, and the developer workflow is an extension of a password product rather than its center of gravity.
05/Enterprise vaults
Enterprise vaults
HashiCorp Vault
Identity-based secret infrastructure at organizational scale: dynamic credentials with TTLs, PKI, encryption as a service, machine identity. Operated by a platform team as core infrastructure.
Choose it when
- A platform team exists to run it
- You need dynamic, short-lived credentials minted per workload
- Regulated infrastructure demands centralized identity and audit
The tradeoff
Operational weight. Vault earns its complexity at scale; on an individual developer's laptop it solves problems that are not present and adds several that are.
06/Local-first runtime
A local-first runtime
Envmesh
An encrypted store on each of your Macs, peer-to-peer sync between devices you approve in person, injection scoped to a single command, and separate, audited sessions for coding agents. No account, no server.
Choose it when
- You develop on one to three Macs and live in the terminal
- Coding agents run on your machine and you want their access scoped and logged
- You do not want another account, or another vendor holding your keys
The tradeoff
macOS only today. No team dashboard, no central policy, and no server-side answer for CI — provider adapters are on the roadmap for that seam. And custody is genuinely yours: if you lose every approved device without an export, the store is gone. That is the point, and it is also the responsibility.
07/In practice
The short version.
- One developer, one to three Macs
- Envmesh. If you would rather keep git as the distribution channel and manage a key yourself, dotenvx is the credible alternative.
- A team sharing production secrets
- Doppler, Infisical, or Phase. The account and the vendor are the price of central control, and for a team that price is fair.
- An organization already on 1Password
- The 1Password CLI is a reasonable dev-secrets layer before adding another product.
- A platform organization with dynamic-credential needs
- Vault, run by the team whose job it is.
These compose.
A team manager and a local runtime solve different halves of the same problem, and provider adapters are on the Envmesh roadmap for exactly this reason: your team’s manager stays the source of record, while Envmesh handles what happens on the machine — device scope, per-command injection, and agent sessions. Choosing one does not mean betting against the other.
Reviewed July 2026 against public documentation. All product names are trademarks of their owners. If something here is wrong or out of date, write to us and we will fix it.