The Tool Desk
Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Antihost offers Linux VPS plans with full root access, unlimited traffic on a 1 Gbps port and a 14-day free trial.
Install Drush inside your Drupal project with Composer, then run it from that project’s local vendor/bin directory. SSH to the VPS, enter the directory containing composer.json, check PHP and Drupal compatibility, run composer require drush/drush, and verify the installation with vendor/bin/drush status. Site-local Drush keeps the command version tied to the codebase you deploy, which is safer than relying on an unrelated global binary.
What you need before installing Drush
Drush is the command-line administration tool for Drupal. It can rebuild caches, run database updates, import or export configuration, manage modules and themes, generate code, and support remote synchronization. On a VPS, it runs in the same PHP environment as the Drupal application, so the shell account, PHP version, Composer dependencies, filesystem permissions, and database access all matter.
Do these 3 things before closing this tab:
1Scan for outdated or missing drivers - takes under a minute2Repair Windows errors before they cause bigger problems3Fix the driver behind crashes, sound loss and screen glitches
- SSH or terminal access: Use an account that can read the Drupal project and execute PHP and Composer. Avoid running routine Drupal commands as
root; use the account that owns the project files or the web-service account when your deployment model requires it. - A Composer-managed Drupal codebase: The directory must contain the Drupal project’s
composer.json. A manually assembled or partially copied Drupal tree may not have the dependency structure Drush expects. - A supported PHP and Drupal combination: Drush support is tied to its major version. Check the current compatibility table on the official Drush installation documentation immediately before changing production dependencies.
- Write access for Composer: Composer must be able to update
composer.json,composer.lock, and the project’svendordirectory, or you must install dependencies in a build environment and deploy them. - Backups and a change window: Commands such as database updates, configuration imports, and synchronization can alter production data or code. Confirm a restorable database and files backup first.
For VPS selection, the practical requirements are SSH access, a supported PHP release, Composer, reliable backups, and a separate staging environment. A control panel that hides the project directory or prevents Composer execution makes Drush operations harder to audit and automate.
Choose a Drush major version that matches the site
Do not select a Drush release only because it is the newest package shown by Composer. Match the major version to the Drupal core and PHP versions in the project, then commit the resulting dependency files. The compatibility values below are the figures currently documented; support changes over time, so recheck the live table before installation.
| Drush major version | PHP requirement documented | Drupal compatibility documented | Installation model | Maintenance implication |
|---|---|---|---|---|
| Drush 13 | PHP 8.3 or newer | Drupal 10.2 and newer Drupal 10 releases, plus Drupal 11 | Composer dependency in the project; run vendor/bin/drush |
Use when the project’s PHP and Drupal core meet the current Drush 13 table; verify support status before upgrades. |
| Drush 12 | PHP 8.1 or newer | Older Drupal compatibility than Drush 13; consult the current table for the exact core range | Composer dependency in the project; run vendor/bin/drush |
Useful for projects that cannot yet move to the Drush 13 PHP or Drupal requirements. |
| Drush 8 | Not stated in the current installation guidance | Legacy Drupal versions | Historical workflows differ from current Composer guidance | Maintain only when a legacy site requires it; do not use Drush 8 instructions for a current Composer-based Drupal project. |
The table is a compatibility guide, not a promise that every patch release is interchangeable. If the project already constrains Drush in composer.json, preserve that constraint unless you have tested an intentional upgrade.
Install Drush on the VPS with Composer
The following procedure installs Drush locally for one Drupal project. Replace the path with the actual directory used by your deployment.
Recommended Free Tools
- Connect over SSH. Confirm that the account can run
php -vandcomposer --version, and can read the Drupal files. - Enter the Composer project root. This is the directory containing
composer.json, not necessarily the web server’s document root. - Check versions before changing dependencies. Run
php -v, inspect Drupal’s version, and compare both with the Drush compatibility table. If the project uses a deployment pipeline, perform the Composer change in the build workspace instead of directly on a live server. - Require Drush. Execute the project-local Composer command:
composer require drush/drushComposer resolves Drush and its dependencies, writes the selected requirement to composer.json, and records the exact dependency set in composer.lock. Review the proposed changes, especially if Composer wants to update unrelated Drupal packages. A controlled project may instead require an explicitly selected major-version constraint that is known to fit its compatibility matrix; use the constraint already established by the project’s dependency policy rather than blindly replacing it.
- Install the same dependency set everywhere. Commit the updated
composer.jsonandcomposer.lock. On another server or in deployment, use the project’s normal locked-dependency command (commonlycomposer install) so production receives the tested versions rather than a fresh resolution. - Run the site-local executable. From the same project root, execute:
vendor/bin/drush statusDo not assume installation succeeded merely because Composer completed. A usable status response should identify the Drupal root, site URI, database connection, Drupal version, and Drush version. It should also reveal whether the command bootstrapped Drupal successfully. The exact formatting varies by Drush release, so treat the fields—not a copied sample—as the test.
Why vendor/bin/drush is preferred to a bare drush
vendor/bin/drush is the executable installed by Composer for this project. It resolves the Drush version recorded in the project’s dependency tree, so two Drupal projects on one VPS can use different compatible Drush majors without interfering with each other.
A bare drush command depends on your shell’s PATH. It might be a launcher, a system package, or an old global installation, and therefore may dispatch to a different project—or fail to find the project at all. Always use the explicit path in scripts, cron jobs, deployment hooks, and incident runbooks unless you have deliberately standardized a launcher.
Make the command shorter from the project root
You can add the project’s vendor/bin directory to PATH for an interactive shell, then invoke drush while working in that project. The exact shell configuration depends on the account and shell, and the change should not silently affect unrelated projects.
An optional Drush Launcher can dispatch a bare drush command to the project-local binary. If you use it, verify which project it selects and keep the explicit vendor/bin/drush form in automation where unambiguous behavior matters. The launcher is convenience software; it is not a replacement for installing Drush in the Drupal project with Composer.
Verify bootstrapping and discover commands
After status, ask Drush what the installed release actually supports. Command names and aliases can change between Drush and Drupal versions.
vendor/bin/drush help
vendor/bin/drush list
vendor/bin/drush topichelpdisplays command usage and options. Add a command name, such asvendor/bin/drush help updatedb, for focused help.listshows commands available after the project’s modules are loaded. This is safer than copying a command from documentation for another major version.topicopens longer conceptual documentation about Drush usage and workflows.
The documented command shape is drush [options] <command> [argument1] [argument2]. With a site-local installation, substitute vendor/bin/drush for drush in that pattern.
Make Drush use the correct Drupal site
Drush normally discovers the site from the current project directory and Drupal settings. Discovery can become ambiguous when you run the command outside the project root, host several sites, or use a multisite layout. In those cases, identify both the Drupal code root and the site URI explicitly.
Run from the project root
cd /path/to/drupal-project
vendor/bin/drush statusThis is the simplest and most reliable form when the current directory contains the Composer project and the intended site is the project’s default site.
Specify the Drupal root and URI
vendor/bin/drush --root=/path/to/drupal-project/web --uri=https://example.com status--root points to the Drupal web root used by that installation; in many Composer layouts it is a subdirectory such as web, while the Composer root is one directory above it. Use the path that contains the Drupal index and core files on your server. --uri selects the site context and is important for multisite installations and commands that generate links.
Set a default URL for the session or environment
export DRUSH_OPTIONS_URL=https://example.com
vendor/bin/drush statusDRUSH_OPTIONS_URL supplies the URL Drush should use when a command needs site context. Keep environment files protected and avoid setting a production URL in a shared shell profile where it could accidentally affect a staging command. You can also pass --uri=https://example.com on an individual invocation when a one-off override is clearer.
Free tools Windows power users keep installed
One-click scans. No signup required.
Use a site alias
A Drush site alias gives an environment a stable name such as @staging and stores its root, URI, connection, and remote transport details in alias configuration. Once the alias is correctly reviewed, commands can target it without repeating long paths:
drush @staging updatedbAliases are configuration, not magic discovery. Test that an alias resolves to the intended host, Drupal root, URI, and account before using it. An incorrect alias can direct a harmless read command to the wrong site or direct a destructive command to production.
Core Drush workflows on a Drupal VPS
Use the installed release’s help output for complete options, and take a database and files backup before operations that change state.
Rebuild caches
vendor/bin/drush crcr is the commonly used cache-rebuild command. Run it after code, service, routing, or configuration changes when Drupal requires a rebuild. It does not substitute for checking PHP errors, permissions, or application logs if the site remains broken.
Check and apply database updates
vendor/bin/drush updatedb:status
vendor/bin/drush updatedbUse updatedb:status to see pending updates before applying them. Run updatedb only after deploying the corresponding module or core code and confirming that the backup and rollback plan work. Keep the command output with the deployment record.
Export and import configuration
vendor/bin/drush config:export
vendor/bin/drush config:importConfiguration export writes the active configuration to the project’s configured sync directory; the exact destination is defined by Drupal settings. Import applies configuration from that directory and can remove or alter active configuration depending on the project’s synchronization settings. Review the diff and run imports against the intended URI and environment.
Manage modules, themes, and generated code
The Drupal User Guide describes Drush as a way to install modules and themes, generate boilerplate code, clear cache, and create dummy content. The available command set depends on enabled modules and the installed Drush major version. Start with:
Quick wins for a faster PC:
Scan for outdated or missing drivers - takes under a minuteDriver Scan →Repair Windows errors before they cause bigger problemsFix Now →vendor/bin/drush list
vendor/bin/drush help <command>Use Composer—not an ad-hoc Drush download—to add contributed modules or themes to a Composer-managed project, then use Drush for the Drupal-side enablement and follow-up tasks appropriate to that project’s deployment process.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Remote synchronization with aliases
With correctly configured aliases, Drush can coordinate updates and data between VPS environments. The official usage examples include:
drush @staging updatedb
drush rsync @staging:%files/ @live:%files
drush sql:sync --structure-tables-key=custom @live @selfThe first runs pending database updates on the staging alias. The second synchronizes files from staging to live. The third synchronizes the live database to the local target while using a structure-tables key named custom so designated tables—often cache or other environment-specific tables—can be excluded according to the alias configuration.
- Inspect alias definitions before every cross-environment operation; confirm hostnames, SSH users, paths, URI values, and the direction of synchronization.
- Run a dry-run or listing mode when the installed command offers one, then read the output rather than assuming the target.
- Back up both source and destination databases and files before synchronization.
- Do not copy production secrets or environment-specific settings into staging unintentionally.
- Use the local binary on each project when aliases are invoked from scripts, or ensure the launcher resolves the expected project.
Common failures and how to diagnose them
| Symptom | Likely cause | Checks and corrective action |
|---|---|---|
vendor/bin/drush: No such file or directory |
You are not in the Composer project root, or dependencies were not installed. | Change to the directory containing composer.json; confirm vendor/bin/drush exists; run the project’s dependency installation command and check Composer errors. |
| Composer rejects the Drush requirement | PHP or Drupal core is outside the selected Drush major’s compatibility range, or another package imposes conflicting constraints. | Run php -v, inspect Drupal and Composer constraints, consult the current Drush compatibility table, and choose a compatible major or plan the required platform upgrade. |
| Status reports the wrong site | The command was run from an ambiguous directory, or a multisite URI was not supplied. | Use --root and --uri, set DRUSH_OPTIONS_URL, or correct and test the relevant alias. |
| Drupal does not bootstrap | Incorrect root, missing settings, unreadable files, unavailable database, or a PHP extension/runtime problem. | Run status with explicit targeting; verify the settings file and permissions, database credentials and reachability, PHP extensions, and the web/PHP CLI version difference. |
| Command is not listed | The command belongs to another Drush major, requires a module that is not enabled, or has been renamed. | Run vendor/bin/drush list and vendor/bin/drush help; check the installed release’s documentation instead of copying an older alias. |
Bare drush uses an unexpected version |
A global binary, launcher, or another project’s vendor/bin directory appears first in PATH. |
Use vendor/bin/drush explicitly, inspect command -v drush, and correct the shell or launcher configuration. |
| Permission denied during a command | The SSH account cannot read or write Drupal files, the files directory, configuration sync directory, or temporary paths. | Run as the account intended by the deployment model, verify ownership and group permissions, and avoid making broad world-writable changes. |
Keep Drush maintainable after installation
- Commit dependency files: Store
composer.jsonandcomposer.lockin version control. They define which Drush release every environment receives. - Upgrade deliberately: Review Drush and Drupal release notes, compatibility requirements, and package changes in staging before production.
- Use the same PHP CLI runtime in deployment: A VPS can have one PHP version for the web server and another for the shell. Check
php -vfrom the account that runs Composer and Drush. - Keep scripts version-aware: Prefer canonical command names and verify aliases with
drush list. Do not assume a short alias or option will remain unchanged across majors. - Record target context: In automation, include the project path, URI, and expected environment, or use a reviewed alias. Logging the exact command and Drush version makes recovery easier.
- Retire legacy instructions: Drush 8 documentation describes historical workflows. Current Composer-managed Drupal projects should follow the site-local installation model unless a legacy application specifically requires an older stack.
A safe first-session checklist
- SSH with the non-root account used for Drupal operations.
- Change to the directory containing the project’s
composer.json. - Run
php -vand confirm the PHP CLI version fits the selected Drush major. - Run
composer require drush/drushin the appropriate build or staging environment. - Commit and deploy the resulting
composer.json,composer.lock, andvendordependency set according to your process. - Run
vendor/bin/drush statusand confirm the Drupal root, URI, database, Drupal version, and Drush version. - Run
vendor/bin/drush listand inspect help for any command you plan to automate. - For multisite or remote work, test
--root,--uri, environment URL settings, or aliases with read-only commands before making changes. - Back up the destination before
updatedb,config:import,sql:sync,rsync, or other state-changing operations.
Bottom line
On a modern Drupal VPS, the dependable pattern is project-local Composer installation: enter the Drupal Composer root, run composer require drush/drush, and use vendor/bin/drush. Verify with status, target multisite or remote environments explicitly, and let the installed major version’s help and compatibility table—not legacy command snippets—define the commands you automate.
Outdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchPC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
