Is there any usefull official documentation (with proper explanation) about the .env parameters?

Dotenv is a convenience for development, not intended for deployment along with your app. You would set real environment variables on your production server

Hi tykus,

You mean, for instance, use "database.php" for setting the database env vars ? Thats what I would guess when you say 'real environment variables'.

Well here is the source: https://github.com/vlucas/phpdotenv

The sentence 'dont use/not using .env for your production environment' comes along quite a few times over here but with no specific/detailed explanations. I wonder why actually as Laravel newcomers like myself find themselve's totally in the dark with such answers. Do you also dont know while providing the answer still? Well I just figured it out, after a very extensive (perhaps unnecessary?) hours long search and apache-testsession....

Instead of hardcoding the environment variables in any of the files related to the Laravel installation one would/should use the server's "virtualhost" directive.

Example, for knowledge sharing and practice sake:

I'm using the xampp Apache server (package) as my development server. Apache's virtualhost's directive is located at the path = xampp\apache\conf\extra\httpd-vhosts.conf

I deleted the following environment vars from .env:

DB_HOST=127.0.0.1 DB_PORT=3306 DB_DATABASE=laraveldb DB_USERNAME=root DB_PASSWORD=

Then I did set the parameters in httpd-vhosts.conf up like so and restarted the server via the xampp control panel:

<VirtualHost *:80>

SetEnv DB_HOST 127.0.0.1
SetEnv DB_PORT 3306
SetEnv DB_DATABASE laraveldb
SetEnv DB_USERNAME root
SetEnv DB_PASSWORD  

</VirtualHost>

Now Laravel gets the environment variables via php->getenv ( http://php.net/manual/en/function.getenv.php ) but I guess xampp sets getenv up by default as it worked instant.

I cant find a comprehensive enough manual/tutorial/documentation about the config-file.

Yet in the laravel docs Taylor states

To make this a cinch, Laravel utilizes the DotEnv PHP library by Vance Lucas.

By clicking the link you land at https://github.com/vlucas/phpdotenv

And the author explains

You should never store sensitive credentials in your code. Storing configuration in the environment is one of the tenets of a twelve-factor app. Anything that is likely to change between deployment environments – such as database credentials or credentials for 3rd party services – should be extracted from the code into environment variables.

Basically, a .env file is an easy way to load custom configuration variables that your application needs without having to modify .htaccess files or Apache/nginx virtual hosts. This means you won't have to edit any files outside the project, and all the environment variables are always set no matter how you run your project - Apache, Nginx, CLI, and even PHP 5.4's built-in webserver. It's WAY easier than all the other ways you know of to set environment variables, and you're going to love it.

NO editing virtual hosts in Apache or Nginx NO adding php_value flags to .htaccess files EASY portability and sharing of required ENV values COMPATIBLE with PHP's built-in web server and CLI runner

etc, etc. Oh auther has usage notes: https://github.com/vlucas/phpdotenv#usage-notes

And another reference from auther: https://www.12factor.net/config

Hi jlrdw, the information is to abstract for anyone unfamiliar with concepts like 'virtual hosts' or server variables/configuration.

Learning by example is a better way of learning imo, and the same goes for many others for that matter. It is the main reason why so many developers love the screencasts of laracasts instead of written tutorials, examples provide instant clarity.

I agree, docs can be confusing, like the homestead docs. I am not a rocket scientist. There a video from youtube was more helpful.

Update: Today I reproduced the results using the mysql environment variables from the Apache virtualhosts file and an interesting quirk showed itself.

I performed a new Laravel installation (composer), removed the database environment variables from the .env file and expected the new installation to pull in the virtualhost declarations just as the yesterday Laravel incarnation did but it didnt. After tinkering about an hour I deleted the installation and performed another, edited the files to match the yesterday installation but still it wouldnt pull in the data. Then I remembered some specific details from yesterdays installation, mainly that I performed a migration before removing the database environment variables from the .env file and while I didnt expect that to fix the current problem it actually did. So I also reproduced the (single) migration, removed the .env database environment variables again and finally the environment variables got pulled in from the Apache <virtualhosts> file.

So now I have to conclude that, somewhere in the code (one of the classes/files) a crucial setting (gets) changed during a/the (first) migration, a setting-change needed for the framework to accept the apache virtualhost environment variables. Quirky as it may seem (and it is really) Laravel will not pull in the environment data if this step is left out.

Yes, you're making it a lot more complicated than it needs to be by not just using the simple .env file, which will work on all servers no matter what. You've taken it from the app and put it in the server environment, so now you need to replicate all the steps and making sure the apache modules are installed, etc. for any server you want to install it on. Makes it a lot less "plug and play.

No, there's nothing in laravel changing anything to affect virtualhost settings when you run migrations, except for what your migrations are doing. Theres nothing anywhere that would affect virtualhost settings. Not everybody is using apache, either.

Hi Cronix,

You are wrong with your assumptions about nothing changing in Laravel during these steps but have it anyway you like.

You are right, not everyone is using Apache but I am and so are others and while this is just a development server I allready want myself to get used to NOT using the .env file, with production servers in mind allready, because like suggested by the .env publisher its bad practice.

So with all due respect there's nothing complicated about it, I'm just trying to lift some veils and aquire more knowledge about anything having to do with this particular piece of software. And perhaps you might believe this little quirk to be of no concern but I'm sure others will think otherwise.

There's nothing wrong with using .env on production. As you said, I see people say that but I haven't seen any actual documentation anywhere that says you shouldn't assuming everything is set up correctly. The wrong thing is to commit .env with your secrets to a repo where others can see it. Even the laravel forge service uses .env for production deployment and has an editor to change the values.

I hope you get it working.

There are 5 app params and 6 db params. the db params are the same as always, so what should be documented?

@Cronix, I believe these opinions and the advice still to be valid and valueble: https://laracasts.com/discuss/channels/laravel/the-location-of-env-file?page=1

As was suggested in that particular thread google "filetype:env" to get to know why it is considered bad practice to use the .env file on production servers.

Personally I believe it to be more of a hassle to edit the filestructure path, mapping .env to a safe directory. Another option would be to guard it with .htacces which by itself will also depend on particular server settings.

"I hope you get it working."

Cant think of a single reason why it wouldnt work.

@rsvb

This isnt about parameters, but about protocol.

It's only bad if it's publicly accessible. .env is in the site root, not document_root. A lot of people using shared hosing mess up intalling laravel properly because they can't set the document_root so they stick the whole project in the document_root directory, and yeah, you can read a lot of their .env files. But that's only because they don't know how to set their server up properly. If /public is the document_root, you can't get at .env. It's out of the public space. It all comes down to proper server configuration.

Just like you shouldn't be able to directly access yoursite.com/app/Http/Controllers/SomeController.php

For instance, this site is configured improperly: http://www.mybazaar24.com/.env

If it was set up properly, you wouldn't be able to read .env and get a 404

"If /public is the document_root, you can't get at .env. It's out of the public space. "

Yes that's how I would go about it in the first place but I also want to be able to consider other options if a particular host wont let me set things up 'my way'. I'm kinda mad that way, I'd rather (get to) know 5 different methods considering deployment tactics than limit myself to a single method (specialty), which is my personal strategy and (almost) always pays off eventually.

It is about the same reason I only consume about 1 or mostly 2 screencasts per each learning day. During every screencast I want to explore as many possibilities per featured subject as possible, taking myself into long hours of testing and exploring but in the end it always pays dividend.