GoKawiil.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.
Environment variables only deliver values 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.
Those requirements outlive any process and any developer laptop. They belong in a durable project declaration. .env stores values for delivery; it cannot define the application’s secret model.
How does SecretSpec solve this? SecretSpec separates the committed declaration from value storage and delivery. The CLI and SDKs resolve the same declaration regardless of where values live or how applications receive them.
A string is not a schema Section titled “A string is not a schema”
... continue reading