I have read on the github page of dotenv, that you shoudn't use .env files in the production enviroment.
Where can i put Service Keys for PayPal API if not in the .env for production and keep the keys out of version control? Is there a place meant for that?
Why shouldn't you use .env files in production? I think it means that they shouldn't be committed to Version Control. You just need to manually create the file on your production server or upload the .env manually and of course make sure it is outside of your public directory.
It does 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. This can be achieved via an automated deployment process with tools like Vagrant, chef, or Puppet, or can be set manually with cloud hosts like Pagodabox and Heroku.
But again, I think that mainly refers to ensuring that you keep it out of VC. You can of course "hard code" the values within your config files.
I use Laravel Forge and I'm not sure what approach that takes.
I read also it is better to set up actual server env variable in production. Like configuring apache so it populate the env variables with the good values.
I use Laravel Forge and I'm not sure what approach that takes.
I'm almost sure forge sets up your server env variables
@pmall I know it sets them up but what I'm not sure about is what it does.
Does it just create a .env file for me (which is what I assume, but as the OP mentioned above, the dotenv GitHub page suggests that this isn't ideal), or does it look through the config files and swap-out the relevant key => value pairs.
@mstnorris No, the third way is to configure the server so the env variables does not need to be read from .env file. This is just, well, server environment variables.
As in your quote :
In production, the actual environment variables should be set so that there is no overhead of loading the .env file on each request.
Forge will add them straight into the PHP environment. Normally in /etc/php5/fpm/pool.d/www.conf (default file) or /etc/nginx/sites-available/sitevhost_name and include it in the fastcgi_param vars.
I sometimes use .env in production, depends on the setup you're working with. Apache allows for PHP env vars to be set quite easily compared to Nginx.
I don't see a reason why not to use it, apart from the additional file request. If I find some time, I will run some benchmarks against my server to see if it impacts performance and report back here.
I guess .env will be cached by the OS pretty fast, but will see.
Just to add to this, I believe in using a .env.production file for the bulk of non-sensitive vars and then specify any sensitive vars on the server. Server vars will take priority and this way you do not have to list your entire .env set in server.
