I just want to understand the workflow of Magento 2 configuration settings.


In Magento 2, there are these command-line commands: app:config:dump app:config:import


Am I correct in saying:

  • app:config:dump is for importing from database into configuration file (app/etc/config.php).

  • app:config:import is for importing from configuration file (app/etc/config.php) into the database.

  • Assuming this is correct, would I only really use the configuration file when importing data into a new database from existing settings in a config.php file (ie run app:config:import once, then change everything I need in the admin backend instead of in config.php file (ie site specific styling etc).

  • After I am done with everything (so last step), I run app:config:dump, to update the config.php file again?

  • Somewhere along the way all my settings became locked in the M2 backend, I assume it is because I ran app:config:dump? (I figured out clearing specific entries from config.php json they will be editable again, and saved to database).

This workflow of locked configuration settings in backend is really inefficient so I decided to clear everything in config.php file (instead of the modules enable/disable) settings.

Can someone please clarify these for me please. Thanks

2 Answers 2


I have been fighting with the Magento deployment workflow and configuration properties for a while


1. It can be painful!

app:config:dump creates the env.php and config.php files dumping all the database config in them. They then "lock" these fields in the admin

A change to env.php or config.php files will instantly create an error 500 until it is read into the database. So put maintenance before you change things.

For one little change use the command line instead. (more later)

2. app:config:import first wipes all settings in the database

if a setting is not in the files, that particular option will be back to default. (whereas in #3 they are left as is)

I didn't expect that the first time!

The idea is that it is for a deployment in a stable deployment workflow where you clone everything eg deploying containers at installation

3. setup:upgrade will update settings from file only

Settings not in the file will be left as they are (whereas in #2 they are reset to default)

This allows you to set some settings locked in file while leaving others editable in admin.

BUT: running setup:upgrade it also clears generated files and caches, so you have to compile and deploy static again each time, not great if you just want to change a few small settings. (But in a magento workflow you can just copy the compiled and static files over from the build machine orrepository again which is quick)

UPDATE: @john-hall reports quite rightly that setup:upgrade --keep-generated will preserve the generated files to minimise disruption

4. config:set (saves to env or config) and config:sensitive:set (saves to environment) are the least disruptive way to change things

They update both the file and the database.

They do not wipe cache, generated files or anything - as a matter of fact for some things you might have to clear config cache manually to see an effect.

It can be complicated to figure out the path and options but but it beats having to go either of the previous two ways

eg: bin/magento --scope=store --scope-code=default config:set web/unsecure/base_url bin/magento config:set -c msp_securitysuite_recaptcha/frontend/enabled_login 0

There is a ridiculously long list to figure out, name wise, so I do

bin/magento config:show > configlist

so i have a file i can search through.

5. anything in these files is locked in admin

You can lock easily from command line or by putting it in the file and then importing/upgrading

6. the only unlock is remove-from-file and 'setup:upgrade'

there is no way to "unlock" via bin/magento config:set that I could find. There really should be. You have to leave it out of the files and then it will get unlocked. Note that you can then change it in admin, but you can't use config:import then

To use in a deployment/rollout system

Note: I am still not 100% there

A bit of work needs to be done on this approach because a lot of modules are sloppy and write into the config file settings which could be different from instance to instance, for example different between the dev, build and production instances. Theoretically they can mark variables in the module xml definition as "env" versus "config" or mark them as sensitive, but they don't.

1. sensitive settings go in environment variable, or env.php

these are not put into source control. I've stuck with env.php for now

2. setting that are going to be the same between all stay in config.php

This can be put in source control and copied from machine to machine.

I am using a partial config.php that leaves "open" things i want to allow changing from the admin interface so I have to use setup:upgrade not the config import. But then often this is rolled out with other changes so that would run anyway.

3. Things that are machine/environment specific go in env.php

You can move entire config sections out of config.php into env.php so that you have one env.php per machine/instance and a shared config.php

So whether something is in test mode or not, alternative email addresses etc.

This is one that will take time to decide.

I hope this helps

I have spent quite a few hours comparing, merging and producing my config.php and env.php that lock everything I want to speed up but leaves open things we want to be able to modify. It's not there yet, and just today I wiped entire sections trying to make something editable in admin again...

  • this is awesome stuff - how come this had no upvotes yet? thank you!
    – bayer
    Commented Aug 19, 2020 at 14:35
  • thanks @bayer glad it helped. too many things have to be learned the hard way on M2!
    – iphigenie
    Commented Aug 21, 2020 at 14:50
  • My apologies, to be honest stackexchange website never notified me that this question has received an update! I am busy reviewing all my questions, and this is most definitely useful. app:config:dump is the opposite of app:config:import as I originally suspected - it updates your config.php file. Commented Sep 15, 2020 at 8:09
  • 1
    you're right @CvRChameleon I didnt say anything about the dump part - just the config file/database storage and what is / isnt locked. And once you do app:config:dump everything in it will be locked to file version unless you remove the entries from file and do setup:upgrade
    – iphigenie
    Commented Sep 24, 2020 at 9:44
  • 1
    This is very helpful, +1 from me! You mention (accurately) that setup:upgrade will wipe out generated/DI data, however there exists a flag for this command --keep-generated which skips this step. This is a crucial step in our deployment process wherein after copying the RC from build to production, the exit codes from app:config:status and setup:db:status are evaluated to determine if the RC contains config or schema changes. If so, I execute setup:upgrade --keep-generated (a few seconds of downtime; enable maintenance first) to apply these changes. Exporting configs is still a PITA!
    – John Hall
    Commented Dec 4, 2020 at 16:46

Try this

open config.php file from app/etc/config.php location.

Now remove everything from this file except - modules array like below code :

return array (
'modules' => 
array (
'Magento_Store' => 1,
'Magento_AdminNotification' => 1,

then save this file !!

now after saving this file you need to run below command :

php bin/magento setup:upgrade

php bin/magento setup:di:compile

php bin/magento cache:clean

php bin/magento cache:flush

Then logged in to your backend admin panel - and check now configuration are unlocked and able to editable.

  • This only confirms my last statement : so I decided to clear everything in config.php file (instead of the modules enable/disable) settings. Don't I lose all the settings that are only in the settings file (not in DB) if I delete entries as you suggest? Commented Jun 24, 2020 at 10:46
  • This unfortunately does not clarify anything about the rest of my questions - the workflow of the configuration, which is part of this question. Commented Jun 24, 2020 at 10:46

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.