I am working with a Drupal 8 setup when production, test and development environments which periodically sync database. In Drupal 7 it was easy to override the $conf variables in settings.php to force a site in maintenance mode. However, in Drupal 8, the maintenance_mode is not a configuration anymore, but a state that is not possible to override from settings.php, so we have to use additional drush command after each sync to put one of the environments to maintenance mode.

And I am confused how come State API documentation asserts it's environment-specific, when in fact, it gets synced together with database and it is not easy to keep environment-specific settings using State API.

On the contrary, $config is easy to override in settings.php (which is excluded during sync), so it does provide easy way of setting environment-specific configurations.

  • 2
    Code and configuration always goes upstream (local > dev > stage > prod) while a database only goes downstream (prod > stage > dev > local).
    – leymannx
    Commented Oct 18, 2020 at 21:15

1 Answer 1


When you copy your development/testing database to your production database, you're effectively replacing your production site's state with your development site's state. Therefore if you put your production site in maintenance mode, then import a database that says the site is not in maintenance mode, then your site will stop being in maintenance mode.

Conceptually, state is specific to an environment, so long as you aren't copying your database when you push changes from development to production.

Your solution may be to avoid doing these database imports altogether. If you are just making configuration changes on your local development site and just need to push those, you can export the site's configuration to code, commit it to version control, push that config to production and then import it. (See https://www.drupal.org/docs/configuration-management for info.)

If you are creating content in the local development environment that you need to push to production, then you may want to look at using the Migrate API.

If you absolutely must push these database updates but want the production site to remain in maintenance mode when you do it, then you'll need to put your development site into maintenance mode before copying its database to production.

  • Fair enough, though I am still confused how they divided the variables to $config and $state. At least some of them, like for example maintenance_mode could be considered as misplaced, because by definition States are variables not accessible by and not changed by users regularly. And the maintenance_mode can be in fact changed by users and quite frequently.
    – Nick
    Commented Oct 18, 2020 at 20:38
  • Maintenance mode can be changed by site administrators, but it's the status of a specific site, which should not be imported into another site, contrary to (for example) the setting that enables users to create new accounts without administrators authorization.
    – apaderno
    Commented Oct 19, 2020 at 9:55

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.