Using Drush safely in a managed Drupal environment

Drush is the most useful tool a Drupal team has. It clears caches, runs updates, imports configuration, manages users, and inspects almost anything about a site in seconds. It is also the quickest way to damage production: one command aimed at the wrong environment can overwrite a live database. The goal of a managed setup is not to take Drush away. It is to make the safe path the easy one.

Access by environment

On production, access runs through a controlled path such as a bastion host or session manager, with multi-factor authentication, and every session is logged. That protects the site and gives you an audit trail when something needs explaining.

Commands that deserve a pause

Habits that prevent accidents

• Use site aliases, such as @test and @prod, rather than working inside a shell on the server. The target is then visible in every command you type.
• Confirm where you are. drush @prod status shows the site, database, and Drupal version before you do anything else.
• Look before importing. drush config:status lists exactly what an import would change. If it lists deletions you did not expect, stop.
• Take a backup point before anything that changes data: drush sql:dump --gzip --result-file=... on non-production, or a managed snapshot on production.
• Never pass passwords on the command line. Use one-time login links (drush user:login) instead.
• Read the prompt. Destructive Drush commands ask for confirmation. Do not script around that on production.

Deploy with drush deploy

Deployments should follow the same steps every time, in the right order. Since Drush 10.3, a single command does that:

drush deploy

It runs database updates, imports configuration, rebuilds caches, and runs any deploy hooks. Running it from the pipeline, after the new code is in place, means every environment is updated identically and nothing depends on someone remembering the order at the end of a long day.

Everyday safe commands

These are read-only or low-risk and useful for troubleshooting:

• drush status: site and environment overview
• drush watchdog:show --count=50: recent log messages
• drush pm:list --status=enabled: enabled modules
• drush queue:list: queue backlogs
• drush config:get system.site: view a configuration value
• drush cache:rebuild on non-production, or on production outside peak hours when needed

Keeping Drush current

Drush versions follow Drupal versions. Current Drupal releases use Drush 13, installed per project through Composer so every environment runs the same version. A global Drush install on a server drifts from the project's version and causes confusing errors.

When something goes wrong

If a command did something unexpected on production, stop, do not try to reverse it with more commands, and report it straight away with the exact command and time. Session logs show precisely what ran, and a quick report usually means a quick, clean recovery from the backup point.

For recurring production tasks, such as regenerating a sitemap or running an import, ask for them to be added to the pipeline or a scheduled job instead of run by hand. Anything that has to be done repeatedly is safer automated, logged, and tested once.

How eWay manages Drush access

eWay provides Drush, Composer, and Git access appropriate to each environment. Development environments are open to your team. Production access runs through a controlled bastion with multi-factor authentication and full session logging, with read and routine commands available to named users and changes delivered through the deployment pipeline with drush deploy. When your team needs something done on production that the pipeline does not cover, eWay engineers carry it out with a backup point taken first.

What to include in a support ticket

• The severity you would assign, P1 to P4 (see severity levels and response times)
• The environment and what you are trying to do
• For an error: the exact command, the output, and the time
• For access: who needs it, on which environments, and for what purpose

eWay customers can open a ticket in the support portal or email support@ewaycorp.com at any time. See how to request support for all the options. Related reading: structuring Drupal environments and running Drupal cron reliably. More on our Drupal page.