Using .env for Environment Configuration

The .env file holds configuration values that differ between environments — local development, staging, and production — keeping them out of the codebase itself.

What Belongs in .env

APP_ENV=production
APP_DEBUG=false
APP_URL=https://example.com

DB_CONNECTION=mysql
DB_HOST=127.0.0.1
DB_DATABASE=myapp
DB_USERNAME=root
DB_PASSWORD=secret

Reading Env Values in Config Files

// config/database.php
'password' => env('DB_PASSWORD', ''),

Application code should read values through the config() helper — never call env() directly outside config files — since config caching (covered next) doesn't re-read .env at runtime.

Keeping .env Out of Version Control

The .env file should always be listed in .gitignore, with a .env.example committed instead to document which variables a fresh setup needs.

Multiple Environments

Different .env files (or environment variables set at the hosting-platform level) let the same codebase behave differently across local, staging, and production without any code changes.

With configuration handled safely, the next step is making sure Laravel doesn't have to re-read and re-process all of that on every single request.