At a previous consulting engagement, a SaaS company had a cron job that ran a script to rotate logs. The script contained the line:
cp .env .env-$(date +%Y-%m-%d)
Every day, a new .env-YYYY-MM-DD file was created. The .gitignore only listed .env (no asterisk). One day, a developer ran git add --all and committed 90 days worth of .env- files to a public repository. Within six hours, bots had scraped the AWS keys and spun up $50,000 worth of cryptocurrency miners.
The fix was three lines:
A .env (environment) file is a simple text file used to store environment variables in a key-value format. It's commonly used in software development to configure applications without hardcoding sensitive information (like API keys, database credentials, or environment-specific settings) into the source code.
The .env file (pronounced "dot env") is a simple text-based configuration file used to store environment variables for software applications, particularly in development and server-side environments (e.g., Node.js, Python, PHP, Go, Ruby). Its primary purpose is to separate configuration from code, adhering to the twelve-factor app methodology. This report details its structure, usage, critical security considerations, and best practices. At a previous consulting engagement, a SaaS company
| Practice | Rationale |
|----------|-----------|
| Use .env.example | Provide a template with dummy values and clear placeholders. |
| Keep it minimal | Only store variables that change per environment (DB credentials, API keys, feature flags). Hardcode truly constant values. |
| Validate at startup | Application should crash early if required variables are missing or malformed. |
| No secrets in client-side code | .env files are for server-side or build-time only. Never bundle secrets into frontend JavaScript. |
| Use prefix naming | e.g., APP_, DB_, API_ to avoid collisions with system variables. |
| Production alternative | For deployed apps, use platform environment variables (Heroku, AWS ECS, Kubernetes ConfigMaps/Secrets) rather than on-disk .env files. |
config/production.env
Or, use naming without the dot prefix:
env.production
env.development
These files are less likely to be served statically because they lack the leading dot that triggers special web server rules. Every day, a new
# Check if your ignore rule covers the dash
cat .gitignore | grep "\.env"
Correct line: .env* (with asterisk)
Incorrect line: .env (missing asterisk)
When multiple dotenv-style files are used, libraries or frameworks typically define a precedence order. Examples: Or, use naming without the dot prefix: env