This page is out of date and needs reviewing.

We use Drush a lot.

Drush Aliases

Drush 9+ (used on Drupal 8+ projects only) allows for the storage and use of drush aliases within the repository which allows us to configure and store aliases and distribute them easily to other team members, just by checking out the project repository.

One-time configuration

This step only needs to be done just once on your host machine. You will need to create a global config file for Lando, called ~/.lando/config.yml:

touch ~/.lando/config.yml

Edit ~/.lando/config.yml and add the following if it doesn't already exist:

  USER: tanc

Change the value for the USER key to whatever your username is on the remote servers. This may well be your local username.

Set up on a new or existing projects

If there is no [project root]/drush directory then one needs to be created. Aliases will be defined in [project root]/drush/sites. From the gitoot, make the directories needed:

mkdir -p drush/sites

You will need two alias files stored in [project root]/drush/sites/:

  1. A remote.site.yml file
  2. A server.site.yml file

File: remote.site.yml

The remote.site.yml file will contain the configuration for drush to understand how to connect to the sites on a remote server. This will look like the following boilerplate code:

  host: stage.projectname.com
  root: /var/www/stage.projectname.com/gitroot/web/
  uri: default
  user: ${env.USER}

  host: production.projectname.com
  root: /var/www/production.projectname.com/gitroot/web/
  uri: default
  user: ${env.USER}

Change the host and root directives to suit the server and site you are working with.

The value for the user key is making use of the global Lando environment variable called USER which we previously set in ~/.lando/config.yml. Without this ssh based commands run from within a container are unaware of the host's user name and therefore cannot correctly access a remote server.

File: server.site.yml

The server.site.yml file is used for any commands that need to be issues on the server. For example, if you are ssh'd in to the remote server and want to clone the prod database to the stage site you can use this alias to do it.

Add the following boilerplate to the gitroot/sites/server.site.yml file:

  root: /var/www/stage.projectname.com/gitroot/web/
  uri: default

  root: /var/www/production.projectname.com/gitroot/web/
  uri: default

Change the root directive to the correct path on the server.


With these two site aliases in place you can do various things. Some examples are:

  1. Clone production database to your local Lando dev site:
lando drush sql-sync @remote.prod @self
  1. Whilst on the server, clone the production database to the stage site:
cd /var/www/stage.projectname.com/gitroot/web
drush sql-sync @server.prod @self
  1. Whilst on your local development machine and within a Lando project, clone the production database to the stage site on the remote server:
lando drush @remote.prod sql-sync @server.prod @server.stage
  1. Whilst on your local development machine and within a Lando project, clone the production files to the stage site:
lando drush @remote.prod ssh "sudo drush rsync @server.prod:sites/default/files/ @server.stage:sites/default/files/"

Examples 3 & 4 are quite advanced use of drush aliases and may require some explanation:

3: We are asking lando to issue a drush command within the appserver container (lando drush) and this command is to remotely execute (@remote.prod) the drush sql-sync command, syncing the production (@server.prod) database to the stage (@server.stage) site.

4: Even more complex as we are issuing a remote command using ssh. First we ask lando to execute the drush command on the appserver (lando drush) but we pass it the remote alias (@remote.prod) and the drush ssh command so it actually executes the quoted string over ssh on the remote server. This ssh command executes drush rsync as the root user (root is needed as www-data user owns the files) and syncs the production site's public files directory (@server.prod:sites/default/files/) to the stage site (@server.stage:sites/default/files/).

Last updated: