Notice: article was updated in Oct 2019, with latest Laravel 6 example.

While working with a team and with different environments like local, staging and production, there are different settings for each machine. For that we have .env and .env example files. How to use them effectively?

First, the theory – what is .env and .env.example?

In your main Laravel folder you should have .env file which contains various settings, one row – one KEY=VALUE pair. And then, within your Laravel project code you can get those environment variables with function env(‘KEY’).

Don’t confuse it with .env.example file – it is used as an information file for all team members to know what keys and values may be needed.

The rule of teamwork and working with git repositories is that .env file is NOT committed to the repository, it is included in .gitignore file.

It is really convenient, cause then people on your team can change their variables locally without committing them to the repository. Also, you may (and should) have different .env files for your local server, testing server and live server – with same keys, but with different values, like different DB credentials, environment name (APP_ENV) or queue drivers.

Now, .env.example file, on the contrary, is included in the repository and not gitignored. It is used as an example file for you to know what KEY=VALUE pairs you need for your project. Most often it is used to copy it to .env file and then change the values.

You can also read about it in the official Laravel documentation.

Laravel 6 default .env.example

As it stands now for Laravel 6, current .env.example which comes from Laravel project looks like this:

APP_NAME=Laravel
APP_ENV=local
APP_KEY=
APP_DEBUG=true
APP_URL=http://localhost

LOG_CHANNEL=stack

DB_CONNECTION=mysql
DB_HOST=127.0.0.1
DB_PORT=3306
DB_DATABASE=laravel
DB_USERNAME=root
DB_PASSWORD=

BROADCAST_DRIVER=log
CACHE_DRIVER=file
QUEUE_CONNECTION=sync
SESSION_DRIVER=file
SESSION_LIFETIME=120

REDIS_HOST=127.0.0.1
REDIS_PASSWORD=null
REDIS_PORT=6379

MAIL_DRIVER=smtp
MAIL_HOST=smtp.mailtrap.io
MAIL_PORT=2525
MAIL_USERNAME=null
MAIL_PASSWORD=null
MAIL_ENCRYPTION=null

AWS_ACCESS_KEY_ID=
AWS_SECRET_ACCESS_KEY=
AWS_DEFAULT_REGION=us-east-1
AWS_BUCKET=

PUSHER_APP_ID=
PUSHER_APP_KEY=
PUSHER_APP_SECRET=
PUSHER_APP_CLUSTER=mt1

MIX_PUSHER_APP_KEY="${PUSHER_APP_KEY}"
MIX_PUSHER_APP_CLUSTER="${PUSHER_APP_CLUSTER}"

As you can see, quite a lot of those values are empty. And, to be honest, by default you will actually need to change only a few of them – related to database connection:

DB_HOST=127.0.0.1
DB_DATABASE=laravel
DB_USERNAME=root
DB_PASSWORD=

To be honest, some of those variables in Laravel are quite opinionated – for example, PUSHER – I would dare to say that 95% of Laravel projects won’t need that, so I wouldn’t include it into a default .env.example. But that’s only a personal opinion.

Don’t forget .env.example

Golden rule: if you add some variable into your .env file, it also has to be present in .env.example – copy the key there with empty value. Then other people on your team would pull down that file and will know that they need that variable for project to run.

One example of not following this rule was when I was testing some Laravel products for reviews and one of them was Attendize – ticket selling system based on Laravel. After installing it, I’ve got an error:

RuntimeException in DingoServiceProvier.php line 82:
Unable to boot ApiServiceProvider, configure an API domain or prefix

Weird one, I thought. And only after some googling, I’ve found out that I needed to add one line to .env file:

API_PREFIX=api

And that line wasn’t in .env.example file. Although I didn’t even really use the API, without that line the whole app didn’t even load. An expensive mistake.

In short, .env files are a really convenient way to set your environment variables (and in our QuickAdmin we also generate an example .env.example for you), but don’t forget to use it – especially when working in a team.