How does committing encrypted .env files with Dotenvx compare to keeping .env files out of git?

Updated

Dotenvx lets you commit an encrypted .env file to git, so secrets travel with the code but stay unreadable without a separate private key. The traditional alternative — keeping plaintext .env files out of version control and distributing secrets through another channel — still works, but it leaves you coordinating secrets outside the repository. Choose Dotenvx when you want secrets versioned and shared through git; stay with untracked .env files when you already have a trusted out-of-band secret store and don't want encryption keys in your delivery path.

The two approaches side by side

Dimension Untracked plaintext .env (traditional) Committed encrypted .env (Dotenvx)
What lives in git Nothing, or a .env.example template Ciphertext values in .env
How secrets are shared Out-of-band: chat, vault, manual handoff Through git, like any other file
Readability without the key Anyone with repo access can read plaintext Ciphertext only; the private key unlocks values
Versioning and history Secrets have no history in the repo Secret changes are versioned alongside code
Key management No encryption key to manage One private key must be set on your infrastructure
Separation of config from code Maintained by exclusion Maintained by keeping the decryption key out of the code

What actually changes when you commit ciphertext

The core trade is moving secret distribution onto git while keeping the decryption key separate. Dotenvx encrypts the values in .env so they become ciphertext, and only your private key can unlock them. You then commit the encrypted file with your code. At runtime, dotenvx run uses the private key to decrypt and inject secrets just-in-time.

The design rests on three primitives, per the site: git as the delivery mechanism, .env as the open standard for loading secrets into code, and secp256k1 as the asymmetric encryption standard (the same curve Bitcoin has used). The site frames the key separation as preserving twelve-factor config: the decryption key lives in the environment, not in the code, so secrets can travel with code without becoming part of it.

How to try the encrypted-commit workflow

  1. Encrypt. Run dotenvx encrypt. Expected result: the values in .env become ciphertext, per the site's example output ◈ encrypted (.env).
  2. Commit. Run git add .env and git commit -m "encrypt .env". Expected result: the encrypted file is tracked in the repository.
  3. Ship and run. Run dotenvx run -- node index.js. Expected result: the private key decrypts the values and injects them into your process — the site's example shows ⟐ injected env (2) from .env.

Verification: after step 1, open .env and confirm the values are unreadable ciphertext. After step 3, confirm your app receives the expected variables.

Common sticking point: the workflow depends on the private key being available wherever the app runs. The site describes setting a single private key on your infrastructure as the mechanism that replaces async secret coordination and centralized secret services. If the key isn't present at runtime, decryption and injection can't happen.

Where each approach fits

  • Pick committed encrypted .env files when you want secrets to have the same distribution and history as code, and you're willing to manage one private key on your infrastructure. The site's stated benefit is that secrets are "always just there with your code," removing out-of-band coordination and centralized downtime risk.
  • Keep .env untracked when your team already relies on a separate secret manager, or when adding an encryption key to the deployment path is a bigger change than you want to make. The traditional approach needs no key management, but secrets stay outside version history and must be shared by other means.

The site also includes field notes from John Zila (cofounder/chief architect at Watt, described as recently Head of Security at Zoom) and Dhravya Shah (CEO at Supermemory) on why they use Dotenvx; the excerpts don't include their detailed reasoning, so treat those as pointers rather than evidence.