Given that .env files are not supposed to be committed, where do you usually store your .env files in order to share with other people in your team or between groups?
For further actions, you may consider blocking this person and/or reporting abuse
Given that .env files are not supposed to be committed, where do you usually store your .env files in order to share with other people in your team or between groups?
For further actions, you may consider blocking this person and/or reporting abuse
dev.to staff -
GitProtect Team -
Indrakant Mishra -
Theo Jung -
Once suspended, ibrahimcesar will not be able to comment or publish posts until their suspension is removed.
Once unsuspended, ibrahimcesar will be able to comment and publish posts again.
Once unpublished, all posts by ibrahimcesar will become hidden and only accessible to themselves.
If ibrahimcesar is not suspended, they can still re-publish their posts from their dashboard.
Once unpublished, this post will become invisible to the public and only accessible to Ibrahim Cesar.
They can still re-publish the post if they are not suspended.
Thanks for keeping DEV Community safe. Here is what you can do to flag ibrahimcesar:
Unflagging ibrahimcesar will restore default visibility to their posts.
Top comments (8)
This depends on your configuration management tools (Chef, Ansible, Puppet, etc), basically how you deploy your software. In small projects I usually use Ansible script that:
In this case the configuration file is stored along with the Ansible script. This file can be encrypted using
ansible-vault. This setup is not ideal but works quite well for small projects.I store
.envfiles (and similar) in my continuous integration system (e.g. Jenkins) and let it automatically add the file when the project is built. If there is anything to be shared (i.e. default settings that are not confidential secrets) then I put it into a template file which I add to the project's repository (e.g..env.template).If you don't use configuration management tools (Chef, Puppet, etc), you can store them in Gists, Confluence, or similar documentation products. Also you can provide a default eg
.env.defaultthat can be used as a prototype with basic values (local env URL, local service configs, etc). At the very least, the default/template can list out the env variables that the app supports in any given commit.If you do dotenv sensibly, there should be no need to be shared in the team.
It's true that 12factor app ask you to out configuration in the environment, but this does not mean to add them in a
.envfile.Put only personal configuration there, like your token for a service, and put every other configuration in committed configuration files.
If you go down this path you will find that
.envare very personal and thus there should be no need to share them.If for some special reason you need to share them, encrypt them and share any way you like.
gpgor a service like onetimesecret.com/ may come handy.The only other path, but beware that may have some unintended consequences, is to commit a
.env.defaultsort of file that each Dev has to copy and fill appropriately.May I ask you what configurations are in your
.envfile?Have you considered secure-env? Full disclosure, this is an NPM I made out of necessity. how-secure-is-your-environment-fil...?
Hey kunal, i am using the secure-env package for one of my personal projects, but i am using typescript, is there types files for this package?
I tend to put in Google Drive or copy from prod/qa environment directly
We used to just pass them around in a USB. We eventually updated our projects to use to use Google KMS + Google storage, this way the secrets are encrypted and can be loaded anywhere.