CODEWITHSUNDEEP
phpapachelaravellaravel-5
Phil Cross
Phil Cross

Reputation: 9302

Laravel Environment confusion

Ok, so I thought I understood this, but it seems I don't have complete understanding of it.

I've just created an app on my local machine. I had a local .env file storing my local environment variables. I understand that when you commit the app to the server with git, the .env file isn't pushed, and that you should set the environment values on the server.

Well, I'm using DigitalOcean, and I have created a new virtual host file, and set the environment variables in there using the SetEnv APP_ENV local syntax.

When I access the site through the browser, I know it's picking up the env values because I get an error message saying that the base table isn't found, and the database name is what is set in my environment variables. This is fine, because I haven't run migrations yet.

However, When I ssh into the server, and run php artisan migrate, it appears to not be picking up the Env values. I assume this is because artisan is not running through an apache virtual host.

Does this mean I need to create a .env file which will store my database details etc? If so, what's the point in setting the environment variables in the virtual host file, and not just have a single .env file? By setting values in the Virtual Host config file, and also a .env file, I'm duplicating environment variables, which is surely bad practice?

If I shouldn't create another .env file for the server, how do I specify the environment values to use within artisan?

I hope I explained the question well enough, but if I haven't, or I need to clear something up, please ask.

Upvotes: 3

Views: 746

Answers (1)

Chris
Chris

Reputation: 58132

You need a .env file per environment that Laravel will run in. It is perfectly acceptable to have a .env for your local, and a different .env on your staging environment, etc, etc.

I am not clear from your question why you need to put variables in your vhost files. Just create a .env for the staging and a .env for the production environments on their respective servers. If you are building from automated scripts (like puppet or similar) the .env are intentionally simple enough that they are easy to create from scripts.

You can even have a few server examples .env stored in your repo named like .env.production-example so you know what your servers should look like (obviously without actually storing credentials in there).

Upvotes: 2

Related Questions