Using the new Drupal 8 Configuration manager, how can I prevent it from installing the Devel module on certain environments? As far as I know, installing it on my local means the next time I export the configuration and move it to my other environments (dev, test, prod), it will automatically be enabled.

  • Is using drush acceptable? I found out the other day about drush config-export --skip-modules=devel. There might be something similar without using drush, but I do not know.
    – mradcliffe
    Commented Feb 1, 2016 at 17:28
  • So I'd have to do that every time I export the config? There has to be a better way :|
    – cambraca
    Commented Feb 1, 2016 at 18:06
  • Maybe you can add some config files to your .gitignore. Commented Feb 4, 2016 at 12:05
  • 1
    This is related: drupal.stackexchange.com/questions/185536/…
    – Les Lim
    Commented Feb 5, 2016 at 21:58
  • 2
    I think this question is too broad in retrospect. There are probably many good answers because it depends on what the build and development process is for the site.
    – mradcliffe
    Commented Jan 23, 2017 at 17:37

10 Answers 10


Method: Drush

  • Drush can ignore the enabled states of extensions when synchronizing configuration.

    drush cex --skip-modules=devel

    drush cim --skip-modules=devel

  • With Drush CMI tools you can operate with a list of configuration to ignore.

    drush cexy --ignore-list=/path/to/config-ignore.yml

    drush cimy --delete-list=/path/to/config-ignore.yml

Method: Modules

  • You can use the Configuration Split module that allows you to:

    1. Split off some configuration to dedicated folder
    2. Blacklist configuration
    3. Ignore a set of configuration
    4. Configured by configuration entities
  • Configuration Read-only mode module

    This module allows to lock any configuration changes done via the Drupal admin UI. This can be useful in scenarios where for example configuration changes should not be done on the production environment, but only on staging or local environments.

    $settings['config_readonly'] = TRUE;

  • And another module is the Environment Config that allows you to override configuration on a per-environment basis.

  • 2
    I really don't like having all the library dependencies for the devel module on my production servers, so I add it to composer using composer require --dev drupal/devel. Added bonus is that composer install is faster, making prod deploy faster.
    – Duncanmoo
    Commented Sep 17, 2018 at 8:09

Update: The feature described below was removed lately https://www.drupal.org/project/config_split/issues/2926505

If you are using drush in your deployment process you can do the following:

Create a drushrc.php file in the same directory as your settings.php (for example: docroot/sites/default) and put the following:

$drush_ignore_modules = array(

$command_specific['config-export']['skip-modules'] = $drush_ignore_modules;
$command_specific['config-import']['skip-modules'] = $drush_ignore_modules;

This means, that you can manipulate the drush cex / drush cim commands to skip modules, during their process.

You can read more about Using the Configuration Module Filter in Drush 8.


For Drupal 8.8.0 and higher releases, there is a core setting to exclude configuration values without using any contributed module.

Just add the following line in your web/sites/default/settings.php file.

$settings['config_exclude_modules'] = ['devel', 'webprofiler'];

If you are using Drush to import/export configuration, you will need Drush 10+.

Run drush cex.

Read more on the change record, the documentation, or a discussion with people having problems using it.

NOTE: For more than two environments / configuration sets (dev, stage, live), this simple setting will not probably be enough.

drush cex --skip-modules was removed in favor of the Configuration Split module as explained in drush cex --skip-modules was removed in favor of config_split, but config_split is not feature-equivalent; thus, the solutions based on Drush have not worked for me.

For Drupal releases before Drupal 8.8.0, this the solution I suggest.

  • Install the Config Exclude module using composer require --dev, and configure it.

  • Add the following lines in the settings.php file.

    if (file_exists($app_root . '/' . $site_path . '/settings.local.php')) {
      include $app_root . '/' . $site_path . '/settings.local.php';
  • Add the Config Exclude module settings in the settings.local.php file, for example the following lines.

    $settings['config_exclude_modules'] = [

    The settings.local.php is not a requirement.

  • Require the modules you need on the development environment with composer require --dev (for example, composer require --dev drupal/devel). To install the site without the development modules, you use composer install --no-dev. (On your staging and production environments, you should always use --no-dev.)

  • Use drush cex as you would normally do. It will not not export any of the excluded modules settings.


I have noticed that the core.extension settings appear to have been modified after running the command above, but the corresponding .yml file is never written on the hard drive (even after confirming will be deleted and replaced with the active config), so there is nothing to be commited. I guess it depends on the internals of the Config Exclude module.

  • I had very similar experience as @GiorgosK following suggestions above. This solution worked perfectly for me and contains well thought out advice as well. I also noticed core.extension false negatives but it did indeed NOT change status for git so all is well. Thanks
    – vrwired
    Commented Jan 30, 2019 at 22:58

The Configuration Split module might be a viable solution for some.

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.


There's an interesting issue for Drupal 8.3.x: Allow development modules to opt out of config-export. The general concensus is that Configuration Split is currently the best solution.

Comment by swentel:

Just wanted to briefly document how config_split works: The config split config entity defines what is blacklisted, allowing you to blacklist modules and/or config objects. The canonical example, being devel, already has an interesting use case: it comes with system.menu.devel which, in case you blacklist devel, the menu config file will not be removed since there's no dependency. While it's not a major problem, config split allows you individually select that as well so it's removed on the environment.

Comment by geerlingguy:

I've tried a few different methods of managing environment-specific config, and config_split seems to hit the right usability vs. extra overhead balance the best so far. It's simple and lightweight, but allows me to mark (and continue to use) certain configuration only in certain environments.


There is a neat way of doing this, where you end up with your dev modules committed in composer for convenience and those modules' config is not added to your config export (there are 2 parts):

1. Composer require --dev When enabling a module which is purely for development then use the --dev flag:

$ composer require --dev drupal/devel

This results in those dependencies being added into the composer.json file under require-dev:

    "require-dev": {
        "drupal/twig_xdebug": "^1.0",
        "drupal/devel": "^1.0@RC"

So if you install the the site WITHOUT your dev modules you say:

$ composer install --no-dev

NB: On your staging and prod environments you should always do --no-dev

2. Use the config_split module

Configuration split module allows you to create groupings of configuration export which can be enabled or disabled in an environment.

I actually have 3 splits:

  1. Main site config (enabled everywhere; dev and staging and production)
  2. Staging config (enabled in dev and staging) - includes reroute email module
  3. Dev config - includes devel, kint... but not reroute email as that comes with having the staging config enabled in dev.
  • 2
    You really shouldn't be using dev dependencies in this way. They are more for tools, such as code sniffer, that you wouldn't need to run in production. If they are enabled and Drupal is expecting the module to be installed and the code isn't there then this could lead to instability of the site. Drupal/Composer might still attempt to load a file that is not on the file system if it is a dev dependency. Commented Sep 14, 2018 at 16:24
  • @FrankRobertAnderson you do not propose any better solution? I do not want devel module or dependent libraries on my production server, what do you propose?
    – Duncanmoo
    Commented Sep 17, 2018 at 8:11
  • Drupal doesn't really provide a good option for this. Your plan isn't horrible, but it will lead to issues if you are not careful. The issue I have with your plan is config_split becomes the pin that your whole site then hinges on. I would vote yours up if not for the dev dependency thing, which wasn't even a question in the OP. Commented Sep 17, 2018 at 14:26

I made a small script to do it all in one shot.


drush pm-uninstall devel -y
drush pm-uninstall field_ui -y
drush pm-uninstall field_name_prefix_remove -y

drush config-export

drush en devel -y
drush en field_ui -y
drush en field_name_prefix_remove -y

You can also see Config Ignore module.

This module is a tool to let you keep the configuration you want, in place.

Lets say that you do would like the system.site configuration (which contains that sites name, slogan, email, etc) to remain untouched, on your live site, no matter what the configuration, in the export folder says.

Or maybe you are getting tired of having the devel.settings changed every time you import configuration?

  • The Config Ignore module isn't suitable in this case. From the module page: Do not ignore the core.extension configuration as it will prevent you from enabling new modules with a config import. Use the Config Split module for environment specific modules.
    – bmunslow
    Commented Apr 27, 2018 at 13:20

You can use a deployment override module for this. Read the following link for detailed description:


However, Best way to do this would be to disable your module on local and then export the configuration.

Drupal provides a way to override the configuration settings in settings.php, but they are not valid for disabling/enabling modules.

From default.settings.php:

 * Configuration overrides.
 *  * To globally override specific configuration values for this site,
 * set them here. 
 * blah..blah...blah
 * There are particular configuration values that are risky to override. For
 * example, overriding the list of installed modules in 'core.extension' is not
 * supported as module install or uninstall has not occurred. Other examples
 * include field storage configuration, because it has effects on database
 * structure, and 'core.menu.static_menu_link_overrides' since this is cached in
 * a way that is not config override aware. Also, note that changing
 * configuration values in settings.php will not fire any of the configuration
 * change events.

Introduced in Drupal 8.8 there is a setting for that: How does the new config_exclude_modules setting work exactly?

To have the devel module excluded you

  1. Remove devel related configuration yaml files
  2. Add $settings['config_exclude_modules'] = ['devel']; to your settings.php or, even better, your settings.local.php.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.