Drush
Drush is the command-line tool for Drupal. It runs cache rebuilds, database updates and configuration imports from a terminal or a script.
Drush is the command-line tool for Drupal. You type a short command in a terminal inside your project, and Drush performs the task on the site: it rebuilds caches, applies database updates, imports configuration, enables modules, runs cron or hands you a login link. Drush is not a module. It installs as a project dependency.
How Drush works in Drupal 11
Drush needs a site that was built with Composer. Add it with composer require drush/drush and call it as vendor/bin/drush from the project root. Drush 13 supports Drupal 10.2 or later and Drupal 11; Drush 14 supports Drupal 11.3 or later. Drupal.org notes that the Drush Launcher no longer works from Drush 12 onward, so use the copy in vendor.
Every command has a full name and usually a short alias. These are the ones you will meet most often:
| Command | Alias | What it does |
|---|---|---|
cache:rebuild | cr | Rebuilds all caches. |
updatedb | updb | Applies pending database updates. |
config:import | cim | Makes the site match the files in the configuration directory. |
config:export | cex | Writes the site configuration to files. |
pm:install | en | Enables one or more modules. |
core:cron | cron | Runs the cron tasks of all active modules. |
user:login | uli | Prints a one-time login link. |
sql:dump | Exports the database as SQL. | |
generate | gen | Creates boilerplate code for modules, plugins and services. |
Other projects can add their own commands, which is how a module can ship command-line tools of its own.
Example: a deployment
After new code reaches a server, the site needs its database and configuration brought in line with it. One command does the whole sequence:
vendor/bin/drush deploy -v -ydrush deploy runs the database updates, imports configuration, rebuilds the cache, runs deploy hooks and, on Drupal 11.2 and later, warms the cache. The deploy hooks are functions named HOOK_deploy_NAME() that run after configuration is imported.
For a core update, Drupal.org lists the same order: update the code with Composer, run drush updatedb, then drush cache:rebuild.
Useful details
drush updatedbputs the site in maintenance mode while the updates run, so plan for a short window.drush config:import --partialcreates and updates configuration from the source directory but does not delete configuration that is missing from it.drush sql:dump --result-file=auto --gzipwrites a compressed database backup. Withauto, Drush picks a date-based file name in~/drush-backups.drush user:loginprints a link for user 1 by default. Add--uid,--nameor--mailto pick another account.
Site aliases
A site alias is a short name for a site on another server. Drush reads them from drush/sites/self.site.yml in the project. Each environment lists a host, user, root path and URI. You then run drush @live cache:rebuild against that environment from your own machine.
Common mistakes
- Running Drush without a Composer-built site. Drush supports a single install method, and the site must list it as a dependency.
- Forgetting the cache after a code change. When a deployment looks half applied, run
drush crbefore debugging further. - Importing configuration before the code and updates are in place. Use
drush deployso the steps run in the intended order. - Running a command against the wrong site. In a multisite or with several aliases, check the target with
drush statusor pass--uri.
For marketing and content teams
You will rarely type Drush commands yourself, but you will see the effects. "Clear the cache" in a developer's reply usually means drush cr. A release that needs "updates and a config import" is drush deploy. If a page looks stale after a code release, asking whether the cache was rebuilt is a good first question.
With DXPR
DXPR builds on Drush for AI-assisted site work: its agent skills drive commands such as drush dxb:page:update and drush dxt:config:set so an agent can edit DXPR Builder pages and theme settings. See DXPR agent skills.