Skip to content

Comment on Where .env Went Wrongparent

Comments

- .env is the simplest and oldest / most boring solution. Secrets are passed to teammates by DM?

I don't see a reason to ever pass them. Sensitive production values should never be accessible to everyone, and for development the team should be able to create them themselves.

I usually keep very stupid values in .env.example, with the instructions to `cp .env.example .env`. In development it doesn't matter if the password is "password". In production the privileged admin sets up actual values.

- non-sensitive environment variables also need a home. I don't like the idea of cluttering the project with a .env.local or worse like .env.development.local

`cp .env.example .env` and the application uses .env just like in production, only with dummy values.

AboutSource Built by g1lg1l

Hackerly is an independent reader for Hacker News, built on the public HN API. Not affiliated with Y Combinator.