Enjoyed reading your article on 12 factor app for Wordpress. Doing some more research, I saw that there seemed to be some debate on the benefit of having the config in the environment. So can you give an example where having the config variables in the environment was helpful for a project vs just in PHP?
Also the docs say “phpdotenv is made for development environments, and generally should not be
used in production. In production, the actual environment variables should be set so that there is no overhead of loading the .env file on each request.”
So if someone is using Apache, do you recommend storing them in your Apache config (e.g., “SetEnv DB_NAME wp”)? Compared to putting a DB password in a PHP config file, is that approach as/more/less secure? (e.g., someone could see the password if they could see phpinfo())?
BTW, thank you for Bedrock and Trellis. The code and posts have been very informative and helpful!
set so that there is no overhead of loading the .env file on each request.
First step before you start worrying is to measure the problem.
Benchmark the difference between 10,000 requests with phpdotenv and 10,000 requests with the config hardcoded. My hypothesis is that you will not see a significant difference at all.
So many files are already loaded on each request that if there’s any measurable overhead associated with loading .env, it will be infinitesimal. I just don’t find the overhead argument to be convincing, certainly not without any data.
One interesting argument in favor of keeping .env was made by @swalkinshaw a while back:
The .env solution has more going for it because it’s not tied to PHP. You could source that file in Bash for instance and still have access to those env vars."
Moving environment variables to nginx/apache configs would eliminate this use case for .env files. I’m not sure how concerned we are with that.
The argument against .env is that it’s loaded on each request. Again, I don’t think there’s a measurable impact associated with that, but it still feels like we should perhaps move the environment variables to a place where they can persist between requests.
Lastly, an argument that I made against using envars for storing database passwords and the like is that those variables will get passed to subprocesses of the webserver. This means that if PHP spawns a subprocess, it will also be sending all of the database credentials for your webapp to that process. I don’t necessarily think this should be very concerning to us, however. But if we’re arguing in favor of moving the envars to server configs because it “feels” better, then we could just as readily argue that keeping these credentials strictly in php land also “feels” better.
That said, if we do away with .env for production, we could still keep it in composer.json either under require-dev or suggest.
It seems like the main argument for having the config in .env is that you could source it in Bash or some other program. My main question is: has there ever been a time where this was beneficial to you? I.e., do you have an example? Otherwise I could see how someone would consider it needless complexity.
I researched potential security concerns with having the database password in the web server environment. It seems like it should be okay but imagine if someone was working on another app and accidentally left a hole where they were accessible. I know the odds of this are probably really really slim but if we’re not getting any other benefit from .env…