Laravel config cache: why env works locally and fails after deployment

A service reads env('SUPPLIER_TOKEN') directly from its class. It works during development, then behaves differently after configuration is cached on the server. The application has mixed configuration loading with runtime business code.

Read environment values in configuration files

// config/services.php, inside the returned array:
'supplier' => [
    'url' => env('SUPPLIER_URL'),
    'token' => env('SUPPLIER_TOKEN'),
],

Then use the configuration repository from application code:

$token = config('services.supplier.token');
if (!is_string($token) || $token === '') {
    throw new RuntimeException('Supplier integration is not configured');
}

The error is deliberately generic. It should not print the token or dump the environment.

Rebuild the cache during deployment

After placing the correct environment configuration on the server, rebuild Laravel's configuration cache using the PHP binary that runs the application. Restart long-running workers as part of the deployment procedure so they load the new application state.

A command-line PHP version can differ from the web server's version on shared hosting. Confirm both instead of diagnosing every deployment mismatch as a framework defect.

Test missing configuration explicitly

Set the configuration key to null in a test and verify that the integration refuses to run. Set it to a local fixture value and assert the expected request through an HTTP fake. Do not rely on a developer's real environment to make a test pass.

Treat configuration changes like code changes: they need a reproducible release step and a recovery path. Keep secret values outside version control and outside diagnostic output.

Laravel's configuration documentation describes cached configuration and environment access. The application should read config values rather than reimplementing that loading process.