Laravel 4 works out its environment from the hostname

Laravel 4 decides which of the app/config/{env}/ directories to merge by matching the machine’s hostname against a list you write in bootstrap/start.php. It works until someone joins with a laptop whose name is not on the list, at which point they get the default — and the default is production.

// bootstrap/start.php — 4.0, a list of machine names per environment
$env = $app->detectEnvironment(array(
    'local'   => array('*.dev', 'dev-box', 'laptop-2'),
    'staging' => array('web-staging-1'),
));

// 4.1 accepts a closure, so the machine no longer has to be on a list
$env = $app->detectEnvironment(function () {
    return getenv('APP_ENV') ?: 'production';
});

Falling back to production is the safe direction in the abstract and the wrong one in practice: the new machine reads the production config directory, which on a badly set up project means real credentials on a laptop and a developer wondering why the queue is draining. The closure form moves the decision to an environment variable set once per machine — in the vhost with SetEnv, or in the php-fpm pool with env[APP_ENV] — so a hostname change is no longer a deployment concern. Laravel 4.1 also reads .env.local.php, a PHP file returning an array that populates $_ENV, which is where the values belong once the name of the environment is settled; the file is gitignored and the config directory holds only what is safe to commit.