Pantheon gives you three environments out of the box — dev, test, live. Getting Drupal's configuration to behave differently across them without manual intervention or version-controlled secrets is where Config Split earns its place.
The problem with a single config export
A single drush cex export captures everything — including development-only modules like devel, kint, and stage_file_proxy. If you deploy that config to production and run drush cim, those modules get enabled on live. That's bad.
Config Split setup
Install Config Split and create three splits: development, staging, and production. Each split has a folder and a list of config items that only belong to that environment.
# In settings.php (per environment)
# Pantheon sets the PANTHEON_ENVIRONMENT variable automatically
$env = $_ENV['PANTHEON_ENVIRONMENT'] ?? 'dev';
$config['config_split.config_split.development']['status'] = ($env === 'dev');
$config['config_split.config_split.staging']['status'] = ($env === 'test');
$config['config_split.config_split.production']['status'] = ($env === 'live');Key rule: Never put the Config Split status config into version control. The status: true/false on each split is set dynamically per environment in settings.php. If you export it, you'll override your dynamic setting on the next cim.
What goes in each split
Development split: devel, kint, stage_file_proxy, verbose logging config, shield module config. Production split: caching config, aggregated CSS/JS settings, Google Analytics production key, CDN config. Staging split: shield module (to password-protect the test environment).
Deployment workflow
On every Pantheon deployment, the post-deploy script runs drush cim -y. Because the environment variable is set, the correct split activates automatically. No manual intervention, no environment-specific branches, no secrets in git.