Drush for Pros: Drupal Management via Command Line (CLI)

Managing Drupal Efficiently from the Command Line

Drupal can be managed entirely through the administration interface. For many everyday tasks, the backend is also the right place: editing content, managing users, adjusting menus, or changing simple configuration settings. However, as soon as a Drupal website is operated professionally, updated regularly, or developed further, the command line is significantly faster and more reliable. This is exactly what Drush is for.

Drush stands for Drupal Shell and is a command-line tool specifically for Drupal. With Drush, administrators and developers can perform typical maintenance, development, and diagnostic tasks directly in the terminal. These include cache rebuilds, database updates, status checks, configuration exports, enabling or uninstalling modules, cron runs, user management, and many other tasks.

The major advantage: instead of clicking through several backend pages, you run a command and receive an immediate result. Especially for updates, troubleshooting, deployment processes, and recurring maintenance work, Drush saves a great deal of time. For agencies, developers, and advanced website operators, Drush is therefore one of the most important tools in the Drupal environment.

What is Drush?

Drush is not a normal Drupal module that you activate in the backend. It is a separate command-line tool that is installed within your Drupal project and executed via the terminal. Modern Drupal projects are usually managed with Composer. Drush is also installed as a Composer dependency in the project.

Once Drush is set up correctly, you can run commands such as:

Depending on the server configuration and path settings, the command may also be available directly as drush. In many hosting environments, however, project-specific execution via vendor/bin/drush is the cleaner and more traceable option.

When is Drush useful?

Drush is especially worthwhile when you do not merely edit a Drupal website occasionally, but maintain it technically. Drush is not necessary for simple content changes. For maintenance, development, and professional administration, however, it provides a major efficiency gain.

Typical use cases include:

• Clearing and rebuilding caches: Very useful after theme adjustments, module changes, or configuration changes.
• Running database updates: Important after updates to Drupal Core or modules.
• Checking system status: Quick check of Drupal version, database, PHP, site URI, and paths.
• Running cron: Start scheduled Drupal tasks manually.
• Enabling or uninstalling modules: Particularly practical in development and staging environments.
• Exporting and importing configuration: Important for deployment workflows between development, test, and live systems.
• Managing users: For example, resetting passwords or generating one-time login links.
• Automation: Drush commands can be used in scripts, deployment processes, or maintenance workflows.

Anyone who uses Drupal only as an editor usually does not need Drush. Anyone who installs, maintains, extends, or operates Drupal for customer projects should be familiar with Drush.

Requirements at CURIAWEB

To use Drush, you need access to the command line of your hosting package. At CURIAWEB, this is done via SSH access. SSH allows you to connect securely to the server and execute commands there.

For productive use of Drush, the following requirements should be met:

• active SSH access,
• a Drupal installation managed with Composer,
• a suitable PHP version according to Drupal and Drush requirements,
• Composer access in the project directory,
• sufficient user permissions for files, directories, and database access,
• knowledge of the project path of your Drupal installation.

In shared hosting environments, you must pay particular attention to using the correct PHP CLI binary. The PHP version in the web server and the PHP version on the command line may differ. If Drush produces unexpected errors, the PHP CLI version is therefore one of the first things that should be checked.

Installing Drush

For modern Drupal websites, Drush is usually installed directly in the project via Composer. To do this, connect via SSH and switch to the main directory of your Drupal project. This is the directory where the composer.json file is located.

After installation, Drush is normally located in the vendor/bin/ directory. You can check the installation with the following command:

If a Drush version is displayed, the tool is generally available. You can then use vendor/bin/drush status to check whether Drush correctly detects your Drupal installation.

Running Drush from the Correct Directory

Many Drush problems occur because the command is run from the wrong directory. Drush must be able to detect the Drupal installation. Therefore, first switch to the project directory where the composer.json file is located. In Composer-based Drupal installations, the public webroot is often located in a subdirectory such as web or docroot. The project directory is then one level above it.

A typical structure looks like this:

In this example, you run Drush from the directory /home/user/drupal-project/:

If you are in the wrong directory, Drush may not be able to fully bootstrap the website. Error messages may then appear even though Drush is installed correctly.

Overview of the Most Important Drush Commands

Drush has many commands. For everyday work, however, a few core commands are sufficient and should be used confidently. The following overview shows particularly frequently used commands.

Many Drush commands have short forms. For example, drush cr is the well-known short form for Cache Rebuild. Nevertheless, it is useful to know the long forms as well, because they are often more self-explanatory and are used more frequently in documentation.

Rebuilding the Cache with Drush

The most frequently used Drush command is probably the cache rebuild:

This command clears and rebuilds the Drupal caches. This is necessary or helpful when changes do not become visible, new configurations should take effect, or an inconsistent state occurs after module and theme adjustments.

A cache rebuild is generally a safe command, but it can temporarily increase server load because Drupal has to rebuild the caches afterwards. On heavily visited live websites, it should therefore be used deliberately, especially during peak traffic periods.

Running Database Updates with Drush

After updates to Drupal Core or installed modules, database updates may be required. These can be run through the backend using update.php or via Drush. The Drush command is:

Depending on the Drush version, the short form drush updb is also commonly used. Before running this command, you should always create a backup. Database updates change the structure or contents of the database and cannot always be easily reversed.

A safe process looks like this:

1. Create a complete backup of files and database.
2. Put the website into maintenance mode.
3. Perform code updates via Composer.
4. Run database updates with vendor/bin/drush updatedb.
5. Rebuild the cache with vendor/bin/drush cr.
6. Test the website.
7. Disable maintenance mode again.

Enabling and Disabling Maintenance Mode with Drush

During larger updates or critical maintenance work, visitors should not access a partially updated website. For this purpose, you use maintenance mode. With Drush, you can set this state quickly:

After completing the maintenance work, disable maintenance mode again:

The subsequent cache rebuild is important so that Drupal reliably takes the changed status into account. Afterwards, check the website in a browser window in which you are not logged in as an administrator.

Managing Modules with Drush

Drush can enable or uninstall modules. However, it is important to note that downloading and managing module code in modern Drupal projects is normally done via Composer. Drush does not replace Composer. It only activates extensions that are already present in the project.

A typical process for installing a new module looks like this:

The short form for enabling a module is often:

To uninstall a module, use:

Never uninstall modules blindly. First check whether other modules, configurations, or content depend on them. Especially on production websites, such changes should first be carried out in a test environment.

Checking Drupal Status

The status command is ideal for obtaining a quick technical overview:

Depending on the version and environment, Drush displays information such as the Drupal version, site URI, database connection, PHP version, configuration path, file paths, and Drush version. This information is especially helpful for troubleshooting, support cases, and migration work.

If Drush cannot display a valid status, check the following first:

• Are you in the correct project directory?
• Is Drush installed in the project under vendor/bin/drush?
• Is the Drupal installation fully set up?
• Does the settings.php file exist and is it correct?
• Is the PHP version on the command line correct?
• Can the database be reached?

Running Cron Manually with Drush

Drupal uses cron for recurring tasks. These include processing queues, updating certain data, cleaning up temporary information, or indexing content. Cron can be configured automatically, but it can also be started manually via Drush:

This command is useful if you want to test whether cron tasks are working correctly, or if certain background processes should be executed immediately. For larger websites, cron should be automated reliably so that maintenance tasks are not forgotten.

Exporting and Importing Configuration

One of the most important strengths of modern Drupal versions is configuration management. Settings for content types, fields, views, menus, roles, display formats, and many other structural elements can be exported and versioned. Drush is a central tool for this.

Export configuration:

Import configuration:

In short form, these commands are often used as drush cex and drush cim. They are particularly relevant when a website is operated in multiple environments, for example locally, on staging, and in production.

A typical workflow:

1. Change configuration locally or in a development environment.
2. Export the configuration with Drush.
3. Version the changes in Git.
4. Deploy code and configuration to the target environment.
5. Import the configuration there with Drush.
6. Run database updates and cache rebuild.

Configuration imports should be carried out on production websites with great care. An import can overwrite existing settings. Therefore, check beforehand which changes will be imported.

Restoring User Access with Drush

Drush is also helpful when administrator access no longer works. With the following command, you can generate a one-time login link for a user:

Depending on your needs, you can specify a particular user. The generated link should only be used via secure channels and should not be shared publicly. It grants direct access and is therefore security-critical.

For productive operation, the following is also recommended:

• use strong passwords,
• set up two-factor authentication for administrators,
• do not use shared admin accounts,
• disable unused user accounts,
• review roles and permissions regularly.

Drush and Composer: Clear Separation of Responsibilities

Drush and Composer are often used together, but they perform different tasks. Composer manages PHP packages, Drupal Core, modules, themes, and libraries. Drush executes Drupal-specific commands on an existing installation.

This separation is important for stable Drupal projects. Use Composer for dependencies and code. Use Drush for Drupal-internal operations.

Safe Update Process with Composer and Drush

A professional Drupal update process combines Composer, Drush, backups, and tests. The exact procedure depends on the project. A typical process may look like this:

1. Create a backup: Fully back up files and database.
2. Plan a maintenance window: Larger updates should not be performed during peak times.
3. Enable maintenance mode: Visitors see a maintenance page instead of possible error messages.
4. Update code: Update Drupal Core and modules via Composer.
5. Run database updates: With vendor/bin/drush updatedb.
6. Rebuild cache: With vendor/bin/drush cr.
7. Test the website: Check backend, frontend, forms, login, important content types, and critical functions.
8. Disable maintenance mode: Make the website available again.
9. Perform monitoring: Check log messages and error reports.

On production websites, this process should first be tested in a staging environment. This makes it possible to detect module conflicts, changed dependencies, or database problems before visitors are affected.

Drush in Staging and Deployment Workflows

Drush shows its full strength in professional workflows. When working with development, staging, and production environments, Drush commands can standardize recurring steps. This reduces the risk of manual errors.

Typical deployment steps can include:

The -y parameter automatically confirms prompts. It is practical for automated deployments, but should only be used if the process has been tested and understood. On production systems, automatic confirmation can otherwise trigger unwanted changes.

Common Errors and Their Causes

At first glance, Drush errors can sometimes seem complicated. However, many problems have typical causes. The following overview helps with initial diagnostics.

When troubleshooting, vendor/bin/drush status is often the best first command. It shows whether Drush correctly detects the website at all.

Security Rules for Drush

Drush is powerful. That is precisely why commands should be executed with care. Some commands change the database, configuration, users, or enabled extensions. Errors can immediately affect the live website.

Therefore, observe these security rules:

• Run production commands only if you understand their effect.
• Always create backups before updates and database operations.
• For larger changes, work in a staging environment first.
• Do not use shared SSH accounts.
• Restrict SSH access to people who truly need it.
• Do not store passwords in shell history or insecure scripts.
• Use secure SSH keys and strong passphrases.
• Check the Drupal logs after maintenance work.

Commands with automatic confirmation such as -y should only be used in controlled workflows. For manual work, it is often safer to consciously confirm prompts.

Drush and Performance

Drush itself does not automatically make your website faster. However, it helps you carry out performance-related maintenance work more efficiently. This includes cache rebuilds, cron runs, updates, configuration imports, and deployment processes. Especially for complex Drupal websites with many modules, views, and content types, fast CLI management can significantly reduce administrative effort.

For very large projects or development environments with frequent Composer and Drush workflows, more powerful hosting may be worthwhile. More CPU power, memory, and faster I/O performance have a positive impact especially on Composer operations, cache building, and database operations.

For demanding Drupal projects, staging environments, or custom development workflows, a VPS Cloud Server from CURIAWEB can be a suitable option. It provides more resources and more technical flexibility than traditional shared hosting environments.

Short Checklist for Using Drush

• SSH access is enabled and securely configured.
• The Drupal website is managed with Composer.
• Drush is installed project-specifically via Composer.
• You run Drush from the correct project directory.
• vendor/bin/drush status correctly detects the website.
• A current backup exists before updates.
• Maintenance mode is used for larger tasks.
• Database updates are executed after code updates.
• The cache is rebuilt after changes.
• Production commands are tested first in staging when there is a risk.

FAQ About Drush

Conclusion: Drush is Essential Knowledge for Professional Drupal Management

Drush is one of the most important tools for professional Drupal administration. It significantly speeds up maintenance, updates, diagnostics, development, and deployment. Anyone who technically manages Drupal projects should be confident with the basic Drush commands and know when Composer, Drush, or the backend is the right tool.

Drush is especially valuable for recurring tasks: rebuilding caches, running database updates, starting cron, exporting configuration, or managing modules. In combination with SSH access, Composer, backups, and a staging environment, it creates a clean workflow for reliable Drupal websites.