Skip to content
CH SCShop classdrupal · beginner · ~25 min · 5 steps

How to set up Drush, Drupal's command line tool

Install Drush in your Drupal project and learn the ten commands that make cache clears, updates, and backups a one-liner.

August 10, 2026 · by Dane Petersen

Drush is the command line for Drupal: cache rebuilds, database dumps, one-time login links, all without clicking through the admin. If you maintain a Drupal site and don’t have it yet, this is the best twenty-five minutes you’ll spend this month. You’ll need Composer installed and terminal access to wherever your site’s code lives.

Add Drush to your project with Composer

Drush installs per-project, not globally — each site carries the Drush version that matches its Drupal version, which is exactly what you want. From your project root (the folder with composer.json in it):

composer require drush/drush

Drupal 10 and 11 want Drush 12 or 13, and Composer will pick the right one for you. If it refuses with a pile of version conflicts, read the first few lines of the complaint — it’s usually an old package pinning things down, not Drush itself.

Run your first status check

Composer put the executable at vendor/bin/drush. Ask it how the site is doing:

vendor/bin/drush status

You should get a tidy table: Drupal version, database connection, PHP version, file paths. If “Database” says Connected, Drush found your site and you’re in business.

Make drush runnable without the full path

Typing vendor/bin/ forty times a day gets old. The old Drush Launcher tool is retired, so the modern fix is a shell alias. Add this to your ~/.zshrc (or ~/.bashrc):

alias drush='./vendor/bin/drush'

Then reload with source ~/.zshrc. Now drush works from any project root, and always runs that project’s Drush — no version guessing. If you use DDEV locally, you can skip this entirely: ddev drush status is already wired up.

Learn the daily-driver commands

These ten cover most maintenance days. Read down the list once now; your fingers will learn the rest.

drush status              # health check: versions, DB, paths
drush cache:rebuild       # (cr) clear every cache, fix "why is it stale"
drush user:login          # (uli) one-time admin login link
drush pm:list             # what's installed and enabled
drush sql:dump --gzip --result-file=../backup.sql   # database backup
drush updatedb            # (updb) run pending database updates
drush watchdog:show       # recent log entries, newest first
drush sql:cli             # drop into the database directly
drush config:export       # (cex) write config to files
drush config:import       # (cim) load config from files

The two you’ll use most are drush cr and drush uli — the second one alone pays for the setup the first time a client forgets their password. There’s a whole lesson on when to reach for which cache command in clearing Drupal caches the right way, and if you just inherited this site, our takeover checklist leans on Drush hard.

Verify with a cache rebuild

Prove the whole chain works with the command you’ll run most:

drush cr

You want one line back: [success] Cache rebuild complete. Then ask for a login link:

drush uli

Paste the URL it prints into your browser. If you land in the admin logged in as user 1 — without touching a password — Drush is set up, talking to your database, and ready for every other Drupal lesson in Shop Class.

That's the lesson. Back to the shop for more — or if this is the chore your organization never gets to,that's literally what we're for.