Working with the .env file

.env are unique for each environment. You should not keep it in git repository

As @khoanguyenme suggests, you have one .env file per environment. This file is ignored by default in .gitignore.

Make sure that you update the .env file before you make a deployment to make things smooth. You can use .env.example that is included in your VCS to keep track of all the keys you'll need across your environments.

So in Forge, you'll set your environment variables in your site details under the Environment tab:

Tick that your app is L5 and let Forge make the magic gather :)

Forge rocks !

If you like Forge, you'll love Envoyer ;)

Yes I do understand why and how it works, but I meant for local development and production as two separate files, or do I need to change the one .env file every time I want to post to production.

Ideally you'd add the variables into your PHP environment without an .env file. If not, just create an example (.env.example) with the required variables within git, then change it to .env and put in the values.

@bashy not sure I follow on this?

@lstables try not to think of them as files. The .env file itself is a workaround for development environments (although an Envoyer deploy still uses them).

Essentially, using the file allows you to make changes to your "environment" without needing to reload your web server config each time.

You don't commit the file to version control because generally the stuff you keep in their is sensitive (API keys, passwords, etc). It's not limited to that, either. Things like DB driver and debug switch can be set in it.

But for each environment - whether that is local in Homestead, staging on a VM on your local network, or production on a Forge deployed DO droplet - the environment configuration exists only on that host, because it is specific to that environment.

As @bashy says, ideally you add it to yor environment without the file (I think Forge does, Envoyer doesn't). Creating a file in your VCS that tracks they keys only gives you a reference for what you need to configure in each environment when you deploy.

Overall, the file is not copied between environments and whilst some things may not change (a Mandrill API key for example) you still configure them per environment.

I wrote about this on my blog a little while ago and go into more detail, which I hope gives you some more clarity on the topic.

@deringer ok thanks for this but I still don't see how I can have one file for local and one for production without keep swapping the details each time i push to github.

You can't (without modifying stuff), you missed all the L5 discussions about it :P

Using the .env file is meant for local only, in production you would have these variables set in your environment already.

@lstables your production file lives in production only and you local one lives locally only.

If you're using Forge, they'll be set in nginx (I think, haven't actually used forge for that myself).

If you're ysing Envoyer, it will sync the .env file for you then on each deploy, it will symlink the file from /base/path/.env to /base/path/current/.env.

There is no longer any need for multiple .env or config files.

@bashy yes realised all this last few days in my .env file I had all local setting then set production settings in Forge and it just worked.