In a PHP project, what does a .env loader do, and should production read its database credentials from a .env file?

## What a `.env` file is A `.env` file is a plain-text file in the project root with one setting per line: ``` APP_ENV=local DB_HOST=127.0.0.1 DB_PASSWORD="local-only-password" ``` It is a convention, not a PHP feature. **PHP never reads `.env` on its own** — no directive, no SAPI and no function loads it. A value there is invisible to your code until something parses it. ## What a loader does Loader libraries installed with Composer — `vlucas/phpdotenv` and `symfony/dotenv` are the common ones — run early in the bootstrap, usually from the front controller or the console entry point: 1. find and read the file (and sometimes environment-specific variants); 2. parse each line, handling quotes, comments and references to other variables; 3. skip names that already exist in the real environment, in their default configuration; 4. write the values into one or more stores: `$_ENV`, `$_SERVER`, and — depending on the library and how it is configured — the process environment via `putenv()`. Step 4 is the source of a classic confusion. If the loader writes only to `$_ENV`/`$_SERVER`, then `getenv('DB_HOST')` returns `false` while `$_ENV['DB_HOST']` works. Check which stores your loader fills and read configuration through the same path everywhere. ## Precedence: real variables win Because step 3 skips existing variables by default, a value set by the operating system, container or process manager overrides the file. This is deliberate: - a developer can keep a `.env` with local defaults; - CI or production sets real variables that take precedence without editing any file; - a stray `.env` accidentally deployed does not silently replace production settings, as long as production sets every variable. ## Development versus production | Concern | Local development | Production | |---|---|---| | Source of values | `.env` parsed by the loader | variables set by the platform, or secret files | | Who can see secrets | the developer | only the deployment system and the running process | | Cost | parsing a file on every request or command | none — the environment is already there | | Risk | a committed `.env` leaks secrets | a `.env` in the document root is downloadable | Some frameworks go further for production and compile the resolved values into a cached PHP file, so no `.env` parsing happens per request. The common thread is that production does not depend on a hand-edited `.env` on the server. ## Version control rules - Add `.env` to `.gitignore`: it holds real secrets for one machine. - Commit `.env.example` (or `.env.dist`) with every variable name and harmless placeholder values, so a new developer knows what to set. - Never place `.env` inside the web server's document root; a request for `/.env` would return it as text. - Rotate any credential that was ever committed, even if the commit was later removed — history keeps it. ## Per-environment database credentials For the common case of separate staging and production databases: - both environments read the same names — `DB_HOST`, `DB_USER`, `DB_PASSWORD` — so code never branches on the environment name to pick credentials; - staging's platform sets staging's values and production's platform sets production's, so no file contains both; - the application validates at boot that each required variable is present and fails fast with the variable's name (never its value) in the message. ## Why not just commit a config file per environment? A committed `config/production.php` with the real password puts the secret in every clone, every CI log that prints files, and every backup of the repository. Keeping the structure in code and the secret in the environment — or a mounted secret file — narrows who can read it to the machines that run the application.