Skip to main content
Skip to main content
SecurityJuly 26, 2026• 8 min read

Encrypt .env Files Before Commit

Committing a plaintext .env leaks every secret in your repository. If a copy must live in git, encrypt it first - here is the safe workflow.

Encrypt the whole file locally with the AES-256-GCM Encryptor. Paste, encrypt with a passphrase, save only the ciphertext.

The .env file that should never have been committed

Every developer has seen it: a repository with a .env file containing database credentials, API keys, and a production secret or two, sitting in git history forever.

Git history is a permanent record. Deleting the file today does not remove it from past commits, and any clone, fork, or CI cache can still contain it. Attackers scan public repositories for exactly these files.

The fix starts before the file exists: never commit secrets in plaintext. Encrypting is the fallback for the cases where a copy must exist in the repository at all.

The better options before encryption

  • gitignore the file - add .env and .env.* to .gitignore and never stage them
  • Use environment variables injected by your host, CI, or deployment platform
  • Use a secret manager for production values and inject them at runtime
  • Store only non-secret defaults in a committed .env.example, with placeholders

Note: Encryption is not a license to commit secrets casually. It is the last-resort pattern for teams that genuinely need a shared, versioned copy of configuration - for example offline setups or small teams without a secret manager.

Why AES-256-GCM for environment files

AES-256-GCM is an authenticated encryption mode: it provides confidentiality and detects any tampering with the ciphertext. If the file is modified in the repository, decryption fails instead of silently returning corrupted values.

Because .env files are usually small text, encrypting them as a single document with a passphrase is practical. The passphrase is stretched with PBKDF2, so a weak passphrase still costs an attacker real computation per guess.

Everything can happen in the browser with the Web Crypto API - the plaintext never needs to reach a server, which is exactly what a zero-knowledge workflow requires.

Encrypt an .env file before committing

  1. Open the AES-256-GCM Encryptor.
  2. Switch to file mode and select your .env file, or paste its contents into the text area.
  3. Choose password-based encryption and enter a strong passphrase - at least 12 random characters, ideally a passphrase of four or more words.
  4. Encrypt and save the output as .env.enc (or env.enc).
  5. Remove the plaintext file from the working tree and commit only the ciphertext, plus an env.example that documents the variable names without values.
  6. Share the passphrase with teammates through a channel outside the repository - a password manager, not a chat message or a PR comment.

Warning: There is no recovery if the passphrase is lost, and no security if it leaks. Store it in a team password manager, rotate it on member exit, and treat the ciphertext as only as strong as the passphrase.

Decrypting when a teammate pulls the repository

  1. Fetch the repository and open the AES-256-GCM Encryptor.
  2. Select the .env.enc file.
  3. Enter the shared passphrase and decrypt.
  4. Copy the values into the local environment or save the plaintext file locally - and make sure it is ignored by git.

Rotation and incident response

Encrypting secrets reduces exposure, but if a plaintext .env was ever committed, assume every secret in it is compromised and rotate them - even if you later remove or encrypt the file.

When a teammate who knew the passphrase leaves the team, rotate the passphrase and re-encrypt the file. Better: rotate the secrets themselves so the old ciphertext becomes useless.

Add a check to CI that fails when a plaintext .env file appears in a diff. A few lines of script are cheaper than the cleanup that follows a leak.

FAQ

Q.Is encrypting the .env file enough?

A.It protects the file contents in the repository, but it does not fix weak passphrases, key sharing mistakes, or secrets that already leaked in plaintext. Combine encryption with gitignore, secret managers, and rotation.

Q.Can I encrypt just one secret instead of the whole file?

A.Yes - encrypt individual values and store them as environment variables like API_KEY=$(decrypt ...). Whole-file encryption is simpler for small configs; per-value encryption gives finer control and is closer to how secret managers work.

Q.What happens if the passphrase is lost?

A.The ciphertext is unrecoverable. There is no backdoor in AES-256-GCM. Keep the passphrase in a team password manager and make losing it a process event, not a recovery problem.

Q.I already committed a plaintext .env. What now?

A.Rotate every secret in that file immediately - history and clones still contain it. Then add it to .gitignore, encrypt future copies, and consider history rewriting only for very small private repositories where you understand the consequences.

Q.Is it safe to encrypt my .env in a browser tool?

A.Only if the tool is truly client-side. The encryptor on this site runs entirely in your browser with Web Crypto API - nothing is uploaded. Verify the same property for any tool you use: check that encryption happens locally and the page makes no network request with your data.

References

  • NIST SP 800-38D – Galois/Counter Mode (GCM): https://csrc.nist.gov/pubs/sp/800/38/d/final
  • RFC 5116 – An Interface and Algorithms for Authenticated Encryption: https://www.rfc-editor.org/rfc/rfc5116
  • NIST SP 800-132 – Password-Based Key Derivation (PBKDF2): https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-132.pdf
  • OWASP Secrets Management Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/Secrets_Management_Cheat_Sheet.html

Encrypt your environment file

AES-256-GCM with a passphrase, entirely client-side. No upload, no account.

Open AES-256-GCM Encryptor

Encrypt first, or better, don't commit at all

Secrets in git are a permanent liability. Prefer gitignore and secret managers; when a versioned copy is unavoidable, encrypt the file locally with a strong passphrase and commit only ciphertext.

Encrypt and decrypt .env files in your browser with the AES-256-GCM Encryptor - nothing leaves your device.