I've two environment, dev and staging. I'm using the ReCaptcha module.

In the developpement environment, I have some api keys a other config which until now, are exported thanks to drush cex inside the recaptcha.settings file

site_key: mysite_key
secret_key: mysite_secret
verify_hostname: false
use_globally: false
  theme: dark
  type: image
  size: ''
  tabindex: 0
  noscript: false
  default_config_hash: mydefault_hash
langcode: fr

If I update my staging files website, the config from the development is imported with drush cim.

How can I, without another module, prevent this ?

In my settings.local.dev.php, I've added this line and ran drush cex :

$settings['config_exclude_modules'] = ['recaptcha'];

And it gave me this result

enter image description here

The config is completly deleted, but I'd like to keep all the config but not the site_key / secret_key (such as theme etc...)

I wish I could have a config for the development and the staging separetly, but still using drush commands.

  • 1
    You don't need to mess around with exports here, your secret key should never be in the codebase anyway. Use a config override in settings.php instead, much simpler
    – Clive
    Commented Aug 11, 2021 at 14:00

1 Answer 1


You don't need to exclude the API keys from export; instead, you can set them in code, and then it doesn't matter what gets exported. (...probably. Some modules will not work with this approach.)

You can override config directly in settings.php.

Here's an example with Swiftmailer module taken from one of my sites.


transport: smtp
smtp_host: smtp.example.com
smtp_port: 465
smtp_encryption: ssl
smtp_credential_provider: swiftmailer
    username: ''
    password: ''
sendmail_path: /usr/sbin/sendmail
sendmail_mode: bs
spool_directory: ''
  default_config_hash: RSNbRD3ekSaZoE19f3eHhm93gKOcD2PtmaAVmV3XMes
langcode: ja

Now I want to use a different API key for dev + production. So, in settings.php, I set the config manually:

  $config['swiftmailer.transport']['smtp_credentials']['swiftmailer']['username'] = 'apikey';
  $config['swiftmailer.transport']['smtp_credentials']['swiftmailer']['password'] = 'ABCDEFGHIJKLMNOP'

In my case I'm using a switch to detect an environment variable (live, test, dev, etc.) because that's how the host Pantheon does it, but you can do the same thing with settings.local.dev.php files.

Config in settings.php will never be exported; drush will ignore it. However, Drupal will always prioritize config set in code over .yml files. As a result, if you need to change this, you will have to update the code itself; you won't be able to make changes from the UI anymore.

Also note that it is a potential security issue to check API keys into version control like this.

The Config Override module adds a warning to admin screens that reminds you that you are overriding values in code.

If security is a concern, there's the Lockr module, which was built specifically to handle the use case of juggling API keys, but you have to pay for that.

  • This is tricky, because my client will probably change the key one day or another (my question is more global than only one module in fact), so in this case, I don't think doing it by the code is the best approach... But if I end up by doing by the code, if I understand well, I have to add this $config['recaptcha.settings']['site_key'] = "mycustomky"; inside settings.local.dev.php ?
    – mt.i.1
    Commented Aug 11, 2021 at 14:07
  • @mt.i.1 Yes, that looks correct. Commented Aug 11, 2021 at 14:15
  • It's working well on front, is it possible to "link" key in the database so that it appears in the backend ? Those fields are required, and I can't submit the form to save the other settings
    – mt.i.1
    Commented Aug 11, 2021 at 14:49
  • @mt.i.1 You can use the production field value or a dummy field value (a bad API key that validates) to allow you to save the config. Commented Aug 11, 2021 at 17:28
  • 1
    If you don't want to save passwords and API keys in the active config (where they will be exported as YAML and exposed in the code repo in plaintext) or in a settings file (also exposed in the code repo as plaintext) you can store these values in a secrets.php file, unique per environment, which can be sourced by settings.php or settings.local.php. Commented Aug 11, 2021 at 23:14

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.