Per Environment Config in Drupal 8

One of the biggest improvements in Drupal 8 is the new configuration management system. Config is now decoupled from code and the database. Unlike Drupal 6 and 7, developers no longer have to rely on the features module for moving configuration around.

Most large Drupal sites, and some smaller ones, require per environment configuration. Prior to Drupal 8 this was usually achieved using a combination of hard coding config variables and features. Drupal 8 still allows users to put config variables in the settings.php file, but putting config in code feels like a backward step given D8 emphasis on separating concerns.

For example we may have a custom module which calls a RESTful API of a backend service. There are dev, stage and production endpoints that we need to configure. We also keep our config out of docroot and use drush to import the config at deployment time. We have the following structure in our git repo:

+- .git/
+- .gitignore
+- config/
|  |
|  +-
|  |
|  +- base/
|  |
|  +- dev/
|  |
|  +- prod/
|  |
|  +- stage/
+- docroot/
+- scripts/
+- and-so-on/

When a developer needs to export the config for the site they run drush config-export --destination=/path/to/project/config/base. This exports all of the configuration to the specified path. To override the API endpoint for the dev environment, the developer would make the config change and then export just that piece of configuration. That can be done by runing drush config-get mymodule.endpoint > /path/to/project/config/dev/mymodule.endpoint.yml.

Drupal 8 and drush don't allow you to import the 2 config sets at the same time, so we need to run 2 drush commands to import our config. drush config-import --source=/path/to/project/config/base && drush config-import --partial --source=/path/to/project/config/dev. The first command imports the base config and the second applies any per environment overrides. The --partial flag prevents drush deleting any missing config. In most cases this is ok, but watch out if you delete a view or block placement.

Best practices are still emerging for managing configuration in Drupal 8. While I have this method working, I'm sure others have different approaches. Please leave a comment if you have an alternative method.

Update 11-Mar-2016:Removed --partial from base import. This prevented old configuration being removed during updates.

Hi, Configuration per

Manuel Adan wrote:


Configuration per environment must be overridden always using config override feature. Your website has to have only one global configuration, overridden locally by settings.local.php or even with a custom module. See documentation at:

Added Fri, 2016-07-29 06:42

RE: Hi, Configuration per

Dave wrote:

Hi Manuel,

I have been successfully using the method I've outlined above. I am aware of the option to override configuration in settings.php, but to me that feels like a D7 solution.


Added Fri, 2016-08-26 18:25

Brilliant, just what I was

Darvanen wrote:

Brilliant, just what I was looking for.

I used this method with custom written yaml files to provide differing API endpoints for different environments.

Thank you.

Added Mon, 2017-04-10 16:58

Meh, more complicated

Patrick wrote:

Personally I don't see why you need to fix what isn't broken. This would require me to also change my deploy scripts. Further slowing down development in the early stages. The "that's so last version" attitude is just ridiculous.

It makes no sense to adopt something just because it is new if it is not also better in some way. This does not seem better from my perspective. You just make the process needlessly more complicated.

Added Thu, 2017-06-15 01:45

Brilliant its very informative

Henry @ ingic web design california wrote:

Really i personally told you this is very nice i like your thoughts. This coding pattern nobody tells us with on study, I am working on it this program coding its work properly. keep it up great work.

Added Tue, 2017-08-08 06:21

Post new comment

The content of this field is kept private and will not be shown publicly.
  • Lines and paragraphs break automatically.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Allowed HTML tags: <a> <em> <strong> <cite> <code> <ul> <ol> <li> <dl> <dt> <dd> <p> <div> <blockquote> <pre>

More information about formatting options

By submitting this form, you accept the Mollom privacy policy.