Drush: The Drupal Shell for Practical Site Operations

By Greg Nowak. Last updated 2026-06-19.

Drush is still the fastest way to understand a Drupal site when you inherit it, need to release safely, or want to stop repeating the same admin clicks across environments. For agency teams and operations leads, that makes it more than a developer convenience. It becomes a practical control layer for audits, maintenance windows, and handovers.

The old version of this article pointed to a Drush 8-era PHAR download. That was normal at the time, but it is not the default approach now. As of June 19, 2026, the official guidance is Composer-based: add Drush to the Drupal project, run it from the project root, and use shared aliases for live and staging targets. The current compatibility table matters too: Drush 13 is the recommended line for Drupal 10.2+, while Drush 14 is the recommended line for Drupal 11.3+.

Need	Command	Why it matters
Inventory enabled contributed modules	drush pm:list --type=module --status=enabled --no-core	Shows what the site is actually carrying before cleanup, upgrade, or takeover work.
Run schema updates	drush updatedb -y	Moves database updates into a repeatable release step instead of a manual admin task.
Generate correct site-specific links	DRUSH_OPTIONS_URL=https://example.com drush user:login	Avoids wrong-domain links on multisite or proxied environments.
Check shared environment aliases	drush site:alias @self	Makes live, stage, and local targets visible to the whole team.
Run remote maintenance cleanly	drush @live cache:rebuild	Lets you act on the right server without extra SSH guesswork.

Five small Drush habits that usually save the most time in day-to-day Drupal operations.

Install it the current way

If you are working on a modern Drupal project, Drush belongs in the project dependencies, not as a random server-side utility that each person installs differently. That gives you a versioned toolchain, clearer onboarding, and fewer surprises when PHP, Drupal core, or hosting changes underneath you.

composer require drush/drush
vendor/bin/drush --version
vendor/bin/drush help

From there, run Drush from the project root. If you only work on one Drupal codebase locally, adding ./vendor/bin to your PATH is convenient. If you handle several client estates, keeping Drush project-local is usually the safer choice because it avoids one global binary quietly operating against the wrong PHP or Drupal stack.

The old PHAR-and-bashrc method is legacy guidance now. It is still useful to recognise it when you inherit an older server, but it should not be the default recommendation for a current Drupal 10 or 11 workflow.

Keep the useful commands, modernise the habit

The strongest part of older Drush cheat sheets is the intent behind them: list what is enabled, identify what is non-core, and make repetitive work scriptable. That still holds. What changes in 2026 is the habit around it. Let Drush do the filtering first, and only pipe the result onward when there is a clear reason.

vendor/bin/drush pm:list --type=module --status=enabled --no-core
vendor/bin/drush help pm:list

If you inherited one-liners that scrape table output with grep, the operational question is still valid, but the implementation is brittle. Drush documents output formats and field selection for this command, so when you need machine-friendly output for scripts or audits, prefer documented Drush options over regex against human-facing output.

This is also where business value shows up quickly. A short module inventory tells you whether a site is lean, over-customised, or carrying historical baggage. That is useful in presale discovery, takeover audits, security planning, and estimating whether an upgrade is straightforward or messy.

Use aliases before the project gets busy

Alias files are where Drush stops being a solo power-user tool and becomes a team tool. The official pattern is a self.site.yml file inside the project, with named environments such as @live and @stage. Once that exists, releases and support work become less dependent on one developer remembering server paths from memory.

# drush/sites/self.site.yml
live:
  host: server.domain.com
  user: www-admin
  root: /var/www/example/web
  uri: https://www.example.com
stage:
  host: stage.domain.com
  user: www-admin
  root: /var/www/example/web
  uri: https://stage.example.com

drush site:alias @self
drush @stage cache:rebuild
drush @live updatedb -y

For commands that generate links or need the correct site context, set DRUSH_OPTIONS_URL or pass --uri explicitly. This matters more than teams expect on multisite, reverse-proxy, or CLI-only environments. It is a small detail, but it prevents confusing login links and wrong-environment behaviour.

One more practical note: Drush documents that updatedb automatically enables maintenance mode during database updates. That is exactly the kind of boring safeguard you want inside a release routine, because it turns a risky manual step into something more predictable.

Why Drush still earns its place

Drush reduces time spent clicking around to answer simple questions: which modules are live, which environment are we on, can we run updates safely, and how do we target staging instead of production? For agencies, that shortens onboarding and makes support work easier to hand off. For site owners, it lowers the cost of recurring maintenance. For operations leads, it turns tribal knowledge into repeatable commands and files that can be reviewed.

If your Drupal estate has grown messy, Drush is usually where the cleanup starts: standardise aliases, inventory extensions, script the safe maintenance steps, and remove the guesswork from releases. If you want help turning that into a cleaner operating model without burning weeks of internal time, Greg can help with the audit, the release workflow, and the handover documentation.

Related on GrN.dk

Need help with this kind of work?

Talk to Greg about Drupal operations, audits, or release workflow cleanup Get in touch with Greg.

Sources

Last modified

2026-06-19