Drush in your instance

Drush is the command-line companion to Drupal — clear a cache, run database updates, list users, export config — and it's right there in your shell, ready to point at any of your sites. You don't install it and you don't configure it: BOA already ships the Drush versions your sites need, wires each of your sites up with an alias, and makes sure Drush runs on the correct PHP version for you.

Everything in this topic happens in your own shell — the o1.ftp login you use for SSH. None of it needs root, none of it touches the server, and none of it can reach anyone else's sites. It's the same Drush you already know from Drupal, just pre-set-up for your account.

Log in as o1.ftp — this matters for Drush

There's one thing to get right before you run a single Drush command: connect as o1.ftp, not as plain o1. (Your number may be o2, o3, and so on — the .ftp part is what counts.)

The .ftp login runs inside BOA's special shell, and that shell is what reads your PHP-version choice, makes the site-local vdrush work, and loads your sites' own contributed Drush commands. Under the plain o1 login none of that applies: Drush falls back to whatever PHP the system happens to default to, and you get confusing errors that look like Drupal or server problems but aren't.

So the rule for this whole topic is simple: if you're about to run Drush, you're logged in as o1.ftp. Getting into that shell is covered in Connecting to your account.

What's already set up for you

  • The Drush versions your sites need. drush on its own means Drush 8 (great for Drupal 6 and 7). Newer Drupal (10, 11) uses a site-local Drush that lives inside the site's own codebase — you reach it with vdrush. BOA keeps these side by side so the right one is always available.
  • An alias for every site. BOA writes a Drush alias for each of your sites, so you never have to remember a site's folder path or database details. You just target the alias — for example drush @example.com status — and Drush knows where everything lives. Run drush aliases to see your Drush 8 aliases, or drush11 aliases to see the aliases for your newer (Drupal 10+) sites.
  • The right PHP version. Drush runs on whichever PHP you've chosen for your command-line tools. That's a one-line setting you control — see Choosing your site's PHP version — and Drush picks it up automatically. (It's a separate choice from the PHP that serves your sites; the same page explains both.)

Updating your sites

For code and database updates on a hosted site, the safest route is the Aegir control panel — a Migrate task (to move a site onto an updated platform) or a Verify task. You can also update from the shell: on a Drupal 8+ site use the site's own bundled Drush (for example vdrush @example.com updb), because the legacy system Drush 8 cannot run updates on Drupal 8/9/10/11 — the system drush is for legacy Drupal 6/7 sites. The pages in this topic walk you through both.

In this topic

  • Running Drush — your first Drush command from the o1.ftp shell: the everyday jobs (clear a cache, run database updates, grab a one-time login link), picking the PHP version Drush runs under, and using a site's own bundled Drush with vdrush when a modern Drupal 10/11 site needs it — including the Unlock Local Drush step you run from the control panel first, and Lock Local Drush when you're done.
  • Drush aliases and contributed commands — how the per-site @alias works and how to list your aliases, why targeting an alias beats changing into a site folder, and what to do when a contributed command your site provides suddenly "isn't recognised".

Good to know

  • drush is Drush 8. For a Drupal 6 or 7 site, plain drush @alias ... is exactly what you want. For a Composer-managed Drupal 10/11 site, use vdrush instead — its version matches that site's own codebase.
  • Always target an alias. Prefer drush @example.com <command> over changing into a site directory and running a bare command. The alias points Drush at the right site, on the right database, with the right settings, every time.
  • Your sites' own Drush commands work here. If a module you've installed provides its own Drush command, it runs normally from your o1.ftp shell — no special step needed. (If a contributed command isn't recognised, the usual cause is being logged in as plain o1 instead of o1.ftp.)
  • During an upgrade, hold off. While your host is running a BOA upgrade, the special shell steps aside for a while, so a Drush or Composer command you run right then may use a different PHP version than usual. If something looks off and you know maintenance is happening, wait for it to finish and try again.

When it's not yours to do

Almost everything about Drush here is yours to run from your own shell. A couple of things sit on the server side by design:

  • Turning an old PHP version back on. BOA switches off PHP versions no site is using. If you need one back for a command-line task, that's a quick change your host makes — open a support request and say which version you need.
  • Allowing a contributed Drush command to run inside an Aegir background task (as opposed to your own shell). That's a host-side setting; if you need it, describe the command and ask your host to enable it for your instance.

Neither of these is a workaround you go hunting for — one short support request and your host handles it.

Where to go next