I tend to stuff my .env.example with the variables I need for development. We're using docker so the DB settings are pretty generic

eg

DB_CONNECTION=mysql
DB_HOST=database
DB_PORT=3306
DB_DATABASE=laravel
DB_USERNAME=laravel
DB_PASSWORD=laravel

for live, you just copy up a specific .envfor that environment and keep it out of version control.

The example just contains hints for the developer or devops to fill with the real values.

A lot of CI I'm seeing does a copy of the .env.example if the .env doesn't exist. It's expected that the .env.example is put into source control. Given that, how do you store your credentials (db, and the like)? Obviously not committing those. Is it practice to set those as the "default" in the various configs? Or do you just edit the .env after and run the config:cache?

@pacobelan I think it boils down to, a lot of developers don’t actually know what an .env file is. It’s a replacement for environment variables in environments where using true env vars is difficult, i.e. local development. But in environments such as CI, you absolutely should be using environment variables.

Like @automica, I put my local configuration in my .env.example file. That way, when checking out the project, I can copy that file to .env and get up and running straight away with something like Homestead or just the built-in php artisan serve if I ned to test something really quickly. But any other environment, I will set up environment variables proper. It means you also don’t have to worry about configuration on every deploy; the configuration is already there.

See the readme here, this explains .env pretty well:

https://github.com/vlucas/phpdotenv

Edit: Also during install it should be copied with this:

        "post-root-package-install": [
            "@php -r \"file_exists('.env') || copy('.env.example', '.env');\""
        ],