gitversion-controlenvironment-variablesfile-sharingsecret-key

How to share .env with teams


I have a question about .env file. I know it is a file that contains secrets like API key and password. I also read that you should not commit it to VCS like GitHub. This is fine if I am working alone, but of course, I have team members. So, how should I share the file with someone in my team then? If a new developer joins, do I have to email .env to him/her?

Thank you for your help in advance :)


Solution

  • As you mentioned, it's not a good idea to store secrets in a repository. If you're discussing production secrets, then typically you don't want those on developer machines at all, and you can use some sort of secret store. For example, your CI system, such as Travis CI or GitHub Actions, will typically have a way to store secrets that you can use when deploying code. This will keep them in an encrypted state where they won't be exposed except when you're doing deploys.

    Some other environments also use a more general secret store such as Vault. This is not only good for production, but can also be used to store development secrets (which should be different and have limited access). If you have a bastion or shell host that you use in production, you can grant developers access to the development secrets on that system, and use a script in your repository to automatically fetch them when setting up the repo. Then they'll be stored in a location that's secure, and if they need to be rotated, the developer can simply run the script to get new ones.

    In general, you should be using some sort of secret store for these as much as possible, and be sure that users are fully authenticated (preferably using strong password and some sort of 2FA mechanism) before they can get access. If you do that, then sharing secrets becomes less burdensome because it's just a matter of provisioning access to the secret store.

    Note that a .env file can also contain things that aren't secrets, like other environment variables that are needed to run, such as the type of environment (development or production). Those are fine to store in the repository, and if you need to mix secret and non-secret data, you can create a script which takes the development values from a template file and merges in the development secrets to create the .env. Be sure to mark the .env file as ignored in .gitignore so that users don't check it in accidentally.