I don't agree with this article. > Set your secret as the value of an environment variable, then in your program have a section that reads that data and assign

I don't agree with this article. > Set your secret as the value of an environment variable, then in your program have a section that reads that data and assigns it to a constant that can be accessed wherever it is needed. I would think sourcing an external file which utilizes filesystem permissions would be a much safer option. That external file would then be only accessible to the user who started the service needing that password. "env" is readable by every user. Further on the author contradicts themselves: > Using environment variables to store sensitive information is not a professional solution. Remember that storing other people’s data is a responsibility and a liability. As for source control, that should be done with templating. If you look at any of the major orchestration softwares, chef[0], ansible[1], saltstack[2], they all support Jinja templating. If you're going to bother doing this, you might as well do it properly. For a hobby I'd probably use use https://github.com/andreasjansson/envtpl https://github.com/andreasjansson/envtpl and use a small bootstrap shell script in bash. The good news about doing that is if you decide to move to something more professional such as chef, ansible, saltstack, you can use your same templates as it's all Jinja http://jinja.pocoo.org http://jinja.pocoo.org [0] https://docs.chef.io/templates.html https://docs.chef.io/templates.html [1] https://docs.ansible.com/ansible/latest/modules/template_module.html https://docs.ansible.com/ansible/latest/modules/template_mod... [2] https://docs.saltstack.com/en/latest/topics/jinja/index.html https://docs.saltstack.com/en/latest/topics/jinja/index.html