So this is apparently from earlier in the year, but doesn&#x27;t seem to have been discussed here before?<p>I&#x27;ll come out and say it: I disagree with this completely, and the &quot;solution&quot; suggested (a config file) is honestly worse (and has a lot more risks).<p>My work for clients is a mix of web app development and ops&#x2F;infrastructure - the single best improvement that I ask client dev&#x27;s to do (regardless of what I&#x27;m doing for them) is to start using Env Vars for environment specific stuff.<p>Sometimes it takes a while for developers who are used to projects with a single config file, committed to the repo, and thus using the same db credentials for all environments, local dev, shared dev, staging, prod - but ultimately it makes things <i>so</i>  much easier.<p>In particular I thought it was quite odd to complain about Env Vars being a &quot;hack&quot; to get around limitations, immediately before explaining that a popular (I guess?) app server for ruby&#x2F;rails has some caveats when reloading env vars.<p>&gt; However, this method (Env vars) is just a hack to get around their file system limitations and can cause unexpected problems.<p>&gt; When using environment variables with Unicorn, hot restarts don&#x27;t pick up changes to environment variables.<p>Pot, kettle, black, etc.<p>&gt; All gems used and sub-processes launched have access to all variable values, so if any of them log or transmit the output of &#x27;export&#x27; or ‘env’, your private data can be exposed.<p>If the sub-process&#x2F;code doesn&#x27;t need access to the environment variables, reset the environment the process starts in.<p>If the sub-process&#x2F;code does need access to the environment variables, shouldn&#x27;t you be actually reviewing what it does and how it works?