.env file
A .env file stores configuration as KEY=VALUE pairs that apps load at startup. Learn how it works, when to use it, and why it shouldn't hold plaintext secrets.
A .env file is a plain-text file that stores configuration as KEY=VALUE pairs, one per line. Applications read it at startup to load environment variables such as database URLs, API keys, and feature flags. It separates config from code, but the values are unencrypted, so a .env file should never be committed to version control.
How it works
At startup, a loader reads the .env file line by line and injects each KEY=VALUE pair into the process environment. Most languages have a library for this, such as dotenv in Node.js or python-dotenv. Your code then reads values through the standard environment API, for example process.env.DATABASE_URL. Because the file lives alongside the project but outside the codebase, the same code can run against different values in local, staging, and production. The format is deliberately simple: no nesting, no types, just strings. Lines starting with # are comments, and blank lines are ignored.
Common mistakes
The biggest mistake is committing a .env file to Git, which leaks every secret in it to anyone with repository access and to the commit history forever. Always add .env to .gitignore and share a redacted .env.example instead. Other pitfalls include copying the same file across machines over chat or email, letting values drift between teammates, and keeping unencrypted secrets on developer laptops. These habits cause secret sprawl. Tools like Envless replace ad-hoc .env files by encrypting values client-side and syncing them across environments, so plaintext never sits in a shared file.
.env file FAQ
No. A .env file holds plaintext secrets, so committing it exposes them to everyone with repo access and leaves them in commit history. Add .env to .gitignore and commit a placeholder .env.example with empty values instead.
A .env file contains real values and stays out of version control. A .env.example lists the same keys with blank or dummy values and is committed, so teammates know which variables to set without exposing the actual secrets.
Avoid chat, email, or shared drives, which scatter plaintext copies. Use a secrets manager that encrypts values and controls access, then have teammates pull them at runtime. This keeps a single source of truth and an audit trail of who accessed what.
Ship secrets, not chaos.
Start free today and discover why developers trust Envless for end-to-end encrypted, versioned secrets across every environment.