The Drupal 8 configuration management works best when importing and exporting the whole set of the sites configuration. However, sometimes developers like to opt out of the robustness of CM and have a super-set of configuration active on their development machine and deploy only a subset. The canonical example for this is to have the devel module enabled or having a few block placements or views in the development environment and then not export them into the set of configuration to be deployed, yet still being able to share the development configuration with colleagues.

This module allows to define sets of configuration that will get exported to separate directories when exporting, and get merged together when importing. It is possible to define in settings.php which of these sets should be active and considered for the export and import.


Video and Slides from the Drupalcon Vienna presentation.

Help to improve the online documentation.


The important part to remember is to use Drupal 8s configuration management the way it was intended to be used. This module does not interfere with the active configuration but instead filters on the import/export pipeline.
If you use this module you should have a staging environment where you can let the configuration management do its job and verify that everything is good for deployment.

How it works

The module depends on Config Filter for the integration with the import/export pipeline of the Drupal UI and drush. The configuration is read from the main directory and also from split directories under the hood. Presenting Drupal with the unified configuration of the sync directory and the extra configuration defined in splits.
Importing and exporting works the same way as before, except some configuration is read from and written to different directories. Importing configuration still removes configuration not present in the files. Thus, the robustness and predictability of the configuration management remains.


You may need to single-import the split configuration if it changes apart from which extensions are split off. (You can also not configure the sync directory from the UI for similar reasons.)

Upgrade from beta2 or before

Since beta3 Config Split depends on Config Filter to do the heavy lifting and depends on services defined by Config Filter. However there is a bug in Drupal core that prevents enabling the new dependency in an update hook. #2863986: Allow updating modules with new service dependencies

Up to beta6 there was crutch code in place to work around this limitation. See #2859628: Dependancy on non-existent service.
If you update from pre beat3 to post beta6 you need to patch core or make an intermediate update to beta6 or enable Config Filter before updating Config Split.

Please also do not override the services.yml with services defined in config split, as it was necessary in beta1.

Supporting organizations: 
Sponsored Development

Project information