In Laravel, what does the global `--env` option on an Artisan command actually change, and why can `php artisan migrate --env=staging` still hit your local database?

## What `--env` is On top of Symfony Console's standard global options, Laravel adds `--env` to every Artisan command, described as *the environment the command should run under*. It appears on every `help` screen and can be passed as `--env=staging` or `--env staging`. During bootstrapping Laravel reads it straight from the process's command-line arguments rather than waiting for normal option parsing, because it must influence loading before any command runs. It only exists for console commands; web requests ignore it. ## The two things it changes **1. The environment name.** When configuration loads, Laravel detects the environment. For a console command with `--env`, the value from the command line wins; otherwise the environment comes from `config('app.env')`. So with `--env=staging`: - `app()->environment()` returns `staging`; - environment checks in code, such as `App::environment('production')`, follow it; - the migration commands' **production confirmation** — which asks "Are you sure you want to run this command?" when the environment is `production` — is triggered by `--env=production` even on a laptop. **2. Which `.env` file is loaded — sometimes.** Before configuration, Laravel loads environment variables from a dotenv file. If the command has `--env` and a file named `.env.staging` exists in the environment directory, that file is loaded **instead of** `.env` — it is a replacement, not an overlay. If `.env.staging` does not exist, loading falls back to the usual lookup: `.env.<APP_ENV>` when the process environment names one, otherwise plain `.env`. ## Where it surprises people | Situation | Environment name | Where `DB_*` and other values come from | |---|---|---| | `.env.staging` exists, config not cached | `staging` | `.env.staging` | | `.env.staging` missing, config not cached | `staging` | usually `.env` | | `bootstrap/cache/config.php` exists | `staging` | the cached config; no `.env` file is read | The second and third rows are the trap. `php artisan migrate --env=staging` on a developer machine without `.env.staging` prints nothing unusual, reports the staging environment, and migrates the database in `.env` — your local one, or worse, whatever the last person pointed it at. On a server where configuration is cached, `--env` changes only the *name*: every configuration value still comes from the cache built at deploy time. It also produces a split you can observe: `app()->environment()` says `staging` while `config('app.env')` still holds the value that was configured. ## How to use it safely 1. Treat `--env` as a way to select a **local variant**, not a way to reach another server. Staging commands belong on staging. 2. Keep variant files explicit: if a workflow relies on `--env=testing`, make sure `.env.testing` exists in every checkout that runs it. 3. Before anything destructive, check what the command will actually talk to: - `php artisan about --env=staging --only=environment,drivers` - `php artisan db:show --env=staging` 4. Remember that cached configuration wins: on a server with cached config, changing environment variables or passing `--env` does not change configuration until the cache is rebuilt. 5. Use `--force` deliberately: on migration commands it skips the production confirmation, including one triggered by `--env=production`. ## A worked example of the incident A developer keeps a `.env.testing` for the test suite and has been told that staging "uses `--env=staging`". They run `php artisan migrate:fresh --env=staging --force` to reset what they believe is a disposable staging schema. There is no `.env.staging` on their machine, so the loader falls back to `.env`, which that week points at a shared development database used by the whole team. The environment name reports `staging`, so no production confirmation appears — and `--force` would have skipped one anyway — and `migrate:fresh` drops every table in the shared database. Nothing in the output looked unusual. Two habits would have stopped it: running `php artisan db:show --env=staging` first, which prints the real connection and host, and never using `--force` with `--env` from a laptop. ## Why interviewers ask The question separates people who have memorised "`--env` selects the environment" from people who know the loading order. It maps directly to real incidents: a migration run against the wrong database, a queue worker started with `--env=production` on a laptop that happily used local mail settings, or a server whose cached configuration ignored every change someone made while "testing with `--env`". The strong answer names the file-exists condition, the cached-config bypass, and a concrete habit for checking the target first.