Where .env Went Wrong
The article argues that the common practice of using .env files for configuration has become an architectural anti-pattern. It suggests that these files lack the necessary schema and validation to manage complex application secrets effectively.
Why it matters
It highlights a widespread technical debt issue in modern software development that impacts security and deployment reliability.
.env is one of software’s most successful accidents.
It starts as a shortcut for three export commands. Then it becomes the project’s configuration schema, secret store, environment model, onboarding guide, CI interface, and deployment format.
Environment variables do one job well: deliver strings to a process. .env turned that delivery mechanism into a source of truth.
A convenience became architecture. That is where .env went wrong.
Section titled “Environment variables only deliver values” Environment variables solve a small problem: getting values into a running process. The application can read DATABASE_URL without knowing whether a developer, CI system, or secrets manager supplied it.
A .env file makes those values easy to save and reload. That is useful. But teams also use the file to describe what the application needs. KEY=value cannot say whether a value is required, secret, safe to commit, available only in production, or restricted to one service.
Get smarter about the news
Sign up free for a feed built around what you actually care about, Dive Deeper research on any story, and the full text of every article.
Create free accountAlready have an account? Sign in