bin/magento
The commands you type every day - cache:flush, setup:upgrade, setup:di:compile, indexer:reindex, module:status - and what each does.
bin/magento <command> [arguments] [--options] # e.g. bin/magento cache:flush config layoutbin/magento is a Symfony Console application and the second half of every change you make. Editing the file is the first half; one of these commands is what makes it take effect.
| What you changed | What to run |
|---|---|
di.xml, layout XML, a template, configuration XML | cache:flush |
| Added a module, a schema file or a data patch | setup:upgrade |
| A constructor signature or a plugin, in production mode | setup:di:compile |
| Products, prices or attributes, with indexers on schedule | indexer:reindex |
| Nothing - you want to know whether a module loads | module:status Vendor_Module |
| CSS, JS or templates, in production mode | setup:static-content:deploy |
Clean or flush
cache:clean removes Magento's own entries from the enabled cache types. cache:flush purges the whole cache storage, including anything another application shares with it. Flush is the bigger hammer, for when you cannot explain what you are seeing.
Shorthand
Any unambiguous abbreviation works, so bin/magento c:f is cache:flush and bin/magento s:up is setup:upgrade. Identical commands, fewer keystrokes. -n is --no-interaction, which scripts need.
What trips people up
The command list is not fixed. Before installation only setup:* commands exist, and modules register their own commands in di.xml, so a broken module can make commands vanish from bin/magento list.
Example
# a new module's files are on disk; nothing has happened yet
bin/magento setup:upgrade
# Cleaning up deprecated SET NAMES utf8 from database connections...
# Cache cleared successfully
# Updating modules:
# Schema creation/updates:
# Module 'Vendor_Catalogue':
# Schema post-updates:
# Data install/update:
# Module 'Vendor_Catalogue':
# ...
# Nothing to import.
# Upgrade completed successfully.
bin/magento module:status Vendor_Catalogue
# Vendor_Catalogue : Module is enabled
# after editing di.xml, layout XML or a .phtml template
bin/magento cache:flush
# Flushed cache types:
# config
# layout
# block_html
# ...
# after changing products, prices or attribute values
bin/magento indexer:reindex catalogsearch_fulltext
# Catalog Search index has been rebuilt successfully in 00:00:07When to use it
- Working out which command to run after a change that appears to have no effect.
- Writing a deploy script that upgrades a store without leaving it half-updated.
- Checking from the command line whether a module is enabled on a server you have just been given.
More examples
Clean, flush, and knowing which you ran
Naming types keeps the rest of the cache warm, which matters on a busy store where a full flush causes a visible slowdown. cache:clean skips disabled types, so if a type is switched off in the admin, cleaning it changes nothing - cache:status is how you find that out.
# remove Magento's entries from the enabled cache types
bin/magento cache:clean config layout
# Cleaned cache types:
# config
# layout
# purge the whole storage, shared entries included
bin/magento cache:flush
# Flushed cache types:
# config
# layout
# ...
# which types exist and which are on
bin/magento cache:statusThe production release sequence
The order is not arbitrary: setup:upgrade may add schema that compiled code expects, and static content must be published before traffic returns. --keep-generated leaves the generated classes alone when a build step produced them already; in 2.4.9 setup:upgrade prints a reminder to re-run setup:di:compile when it is in production mode and that flag was not used.
bin/magento maintenance:enable
bin/magento setup:upgrade --keep-generated
bin/magento setup:di:compile
bin/magento setup:static-content:deploy en_GB -f
bin/magento cache:flush
bin/magento maintenance:disableAbbreviations and non-interactive runs
The abbreviations are a Symfony Console feature and resolve only while they stay unambiguous, so c:c is rejected as soon as two commands start that way. Write the long form in scripts and documentation, where a future command name could make the short one ambiguous, and use the short one at your own prompt.
# these two lines are the same command
bin/magento cache:flush
bin/magento c:f
# so are these
bin/magento setup:upgrade
bin/magento s:up
# scripts should never be asked a question
bin/magento setup:upgrade -n
bin/magento setup:upgrade --no-interaction # the longhand of -n
# full stack traces when a command fails
bin/magento setup:di:compile -vvv
Discussion