Config bridge

Map config() keys to options, and their stored values override config at boot — change a mail sender or the app name from the database, without editing .env or redeploying:

// config/options.php
'config_overrides' => [
    'mail.from.address' => App\Options\MailFromAddressOption::class,
    'app.name'          => App\Options\AppNameOption::class,
],

Options::set(MailFromAddressOption::class, '[email protected]');
// config('mail.from.address') === '[email protected]' after the next boot

// Register a mapping at runtime (applied immediately):
Options::overrides('app.name', AppNameOption::class);
Options::configOverrides();      // the active map
Options::applyConfigOverrides(); // re-read every mapped option into config() now

• Only the global scope is applied.
• A mapped option with no stored value leaves the existing config value alone, so framework and .env defaults are never clobbered.
• Mappings accept class-strings or registered keys. An unknown class or key in config_overrides throws InvalidOptionClassName at boot.
• The bridge reads its options without access control, so an option guarded by authorizeRead() still reaches config.
• At boot each mapping costs one existence check, plus a cached read when a value is stored. Errors while applying — for example, the options table not existing yet on a fresh install — are swallowed, so the app still boots.

Live mode

With options.config_overrides_live enabled, set() and forget() on a mapped option re-apply the config key in the current process; forget() reverts it to the value config had before the bridge touched it. Live mode rides OptionSet and OptionForgotten, so events must be enabled:

OPTIONS_CONFIG_OVERRIDES_LIVE=true

Boot-order caveat

Only code that reads a mapped config key after the package boots sees the override. Config consumed earlier in the bootstrap — or read from a config:cache’d file before providers boot — is unaffected.