There are multiple ways to override the configuration on a per-environment base.
The config split module is a great tool for splitting complex configurations between the environments. E.g. having some development modules enabled/configured in development, but not installed/no database stored configuration for them in production.
Besides splitting entire module configurations, it also allows you to split single configuration items like parts of your solr settings. You can have them stored in separate configuration folders. These folders can be used as argument when running drush cim <folder> to get them re-imported to a site.
However, this kind of configuration management most often is overly complex, when your configuration differs slightly only between your environments (e.g. some URLs, IDs or flags, while other settings keep unchanged).
The better approach for minor differences might be overriding the configuration within your settings.php, or even better a settings.local.php file, which can be enabled by uncommenting the according inclusion lines at the end of your settings.php (given it's based on default.settings.php):
/**
* Load local development override configuration, if available.
*
* Use settings.local.php to override variables on secondary (staging,
* development, etc) installations of this site. Typically used to disable
* caching, JavaScript/CSS compression, re-routing of outgoing emails, and
* other things that should not happen on development and testing sites.
*
* Keep this code block at the end of this file to take full effect.
*/
if (file_exists($app_root . '/' . $site_path . '/settings.local.php')) {
include $app_root . '/' . $site_path . '/settings.local.php';
}
You can then override your environment specific configuration using the $config array in your settings.local.php:
$config['search_api_solr.settings']['site_hash'] = '...';
This will not alter the database stored configuration or the managed configuration imported using drush cim. Instead, it will override the database stored configuration during page load. Therefore, it might be wise to having production values stored in your database/configuration management and config overrides for your local and/or staging environments. Once you remove your overrides from your settings file, the database stored configuration (re-)applies.
