Where .env Went Wrong: Why a Shortcut Became a Broken Architecture

The .env file started as a simple shortcut but evolved into a fragile architecture for managing secrets and configuration. It fails to define requirements, lacks a formal specification, and creates security risks by mixing sensitive data with ordinary settings. I argue for separating durable declarations from protected storage and explicit delivery to fix these fundamental flaws.

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.
  1. eigencoder

    Hm, I haven't seen these issues personally. We only have one `.env` file and it's just for local secrets. Configuration emphatically does not go in `.env` and ideally is in docker compose and defined in code (we use Pydantic Settings).

  2. c-hendricks

    Also mise: https://mise.jdx.dev/environments/

  3. qntty

    I use Pydantic Settings for this, would be nice to see a comparison to that. I do like the idea of keeping this in a configuration file.

More from this day

2026-07-31