DEV Community

Discussion on: Please don't commit .env

Collapse
 
tiguchi profile image
Thomas Werner

I looked into this for a project a while ago. I think it's an interesting solution for securely sharing secrets among people who are authorized to configure production servers.

But I also believe that those secrets shouldn't be shared across the entire team to avoid disaster mentioned in some of the anecdotes in this thread, specifically the one about the intern publishing production keys in an .env file. That intern and other devs shouldn't have ever access to those keys in the first place.

I feel that anyone who needs to have access to 3rd party API credentials for local development should just try to generate their own, by signing up developer accounts with those 3rd party web services and registering their own API clients.

It's overhead. But it only needs to be done once and makes absolutely sure that a leak of such credentials is not going to cause any major issues.

In case there is no easy way to sign up yourself (e.g. payment processor APIs) an encrypted store via Git like that makes sense for sharing sandbox environment credentials.

Ideally I believe that .env files and similar configuration files that contain confidential production credentials should be stored in the (encrypted) storage of the CI server and only bundled on build & deploy. A single source of truth, and a single possible point of failure.