Maintain WordPress at Scale on RunCloud with WP-CLI Aliases

How can you maintain WordPress at scale on RunCloud?
The RunCloud platform opens the doors for developers, designers, freelancers and all manner of web businesses to leverage the benefits of using Cloud hosting, without requiring the in-depth skills of a highly experienced sysadmin.
If you run a WordPress or Web Development business, The benefits of using RunCloud allow you to offer your clients access to high quality cloud hosting that you can manage for them as part of a complete service.
RunCloud makes it easy to:

  • Connect many servers from any Cloud hosting provider
  • Deploy and manage many Web Applications and Databases
  • Secure your website with compliant SSL certificates
  • Use the latest web server stack technologies
  • Secure your servers and applications with an advanced firewall

And much more.

Growing your WordPress business – WordPress at scale

Now that the power of the cloud has been unlocked and made available, you have a greater potential to grow your business.
In the world of WordPress development, this may mean growing your client business to include the management of many dozens of WordPress sites (or more) belonging to a multitude of different clients across multiples of servers in different datacenters.
Scaling up
Let’s look at an example of growing to not an unreasonable scale. Let us say you have developed and help manage 30 WordPress sites for different clients. With ongoing staging sites and their environments that need maintaining. Already we are looking at managing up to 60 sites in total.

A Time Consuming Process

When WordPress core updates, you need to manage this process.
If we take a rough estimate of 5 minutes for managing updates across staging and live, it suggests that the business in our example could be spending more than a few hours per month on this task. And as the business grows, this burden only increases!
The process of streamlining this process provides an opportunity for a major cost savings. We can achive this through services or through tools and automation.
(And remember, this isn’t even considering plugin updates.)
There are several GUI based platform solutions to this problem, but today we are going to learn how to use the amazing WP-CLI Aliases feature to efficiently manage this process. Saving your business time (and therefore money) that you can invest more wisely into expanding your client base.
Commands executed in this tutorial will be issued by a superuser using the sudo command for root privileges. If you don’t have a superuser, we have an easy to follow tutorial here.
This tutorial also assumes you have already installed WP-CLI on your RunCloud managed servers, if you haven’t then not to worry, we have another easy to follow tutorial here to do that.

Managing Multiple WordPress sites from within the Same Server

For this tutorial, to begin I will just use two websites on the same server. This will keep things simple, but the basic process can be scaled up to many dozens of sites or more.
Here you can see my two site and in my RunCloud Dashboard:

Example Sites to Manage in the RunCloud Dashboard
Example Sites to Manage in the RunCloud Dashboard

And here you can see them live in all their glory:

An Example WordPress Site
An Example WordPress Site

Another Example WordPress site
Another Example WordPress site

Issuing WP-CLI commands on a server without Aliases.

Initially, after I have installed WP-CLI on my server, if I want to issue a command to either of these WordPress sites I must do it from within that sites WordPress directory:
1 – Login to my server.

$ ssh superuser@server_ip_address

2 – Navigate to the specific WordPress application root folder (from my user folder).

$ cd webapps/an-example-domain/

3 – Execute a WP-CLI command, say update core.

$ wp core update

Not exactly speedy right?
Each command needs to be executed from within the root folder of the WordPress installation, and then I would need to change directory to the other WordPress site root directory and execute commands there.
This is hardly achieving the great efficiencies we require in order to manage many multiples of WordPress sites.

Configure WP-CLI Aliases on your RunCloud Servers

You may remember, in a previous tutorial introducing WP-CLI we created a WP-CLI configuration file config.yml on our RunCloud server.
If you didn’t complete that tutorial, then this is how to do it. First create the hidden .wp-cli directory, navigate into the directory, then create and open the configuration file for editing:

$ mkdir ~/.wp-cli && cd ~/.wp-cli
$ nano config.yml

Within our configuration file we are going to add our WP-CLI Aliases.
A WP-CLI Alias contains the Alias name used to issue the command preceded by an @ symbol, followed by the full path to that WordPress applications root folder on the server.
We can also create WP-CLI Alias Groups, using the same naming format, followed by the individual Aliases to include in the group.
In my case that is the following:

# Aliases
    path: /home/superuser/webapps/an-example-domain/
    path: /home/superuser/webapps/another-example-domain/
# Alias Groups
 - @example
 - @another

WP-CLI Configuration File on a Remote Server
WP-CLI Configuration File on a Remote Server

Save and close the configuration file. Now if we issue the wp – -info command we can see that the location of our config file is listed in the WP-CLI installation information next to WP-CLI Global Config:

WP-CLI Info showing our Configuration File Path

Issuing commands on a server using WP-CLI aliases

After everything has been configured we can use the aliases to issue commands on our WordPress sites from anywhere in the server.
For example, from my superuser’s home directory, I can check the status of the plugins on either of my sites with:

$ wp @example plugin list

List plugins on one site using an Alias
List plugins on one site using an Alias

Or check the plugins on the other site with:

$ wp @another plugin list

List plugins on the other site using an Alias
List plugins on the other site using an Alias

That’s better, no more needing to be within the WordPress site root directory to work on it.
Now, remember that Group Alias we added to the config? Let’s put that to work next.
We can check the plugins of both sites at the same time using the Group Alias, like so:

$wp @all-examples plugin list

List plugins on all sites using a Group Alias
List plugins on all sites using a Group Alias

In this example, our server only has two WordPress sites, but imagine the efficiencies involved in using Group Aliases to issue commands across 20 or 30 sites, or more. Using a WP-CLI Group Alias we can issue single commands to manage any number of WordPress sites on a server.
But it gets better still…

Managing Multiple WordPress sites across Multiple Remote Servers

Lets scale up a bit and add another server, it’s just enough to illustrate the principles. Rest assured though, the methods outlined here will scale massively.
So I have added another server to the mix:

Two servers with WordPress sites on them

I need to make a note of the IP addresses for each server, these will be needed later.
On this new server I have added another WordPress web application,

Yet Another WordPress Site in the Dashboard
Yet Another WordPress Site in the Dashboard

Yet Another WordPress Site Front End
Yet Another WordPress Site Front End

Now that we have several WordPress sites to manage across different servers we need to configure things a little differently.
We will manage them remotely from our local machine. This means we will issue WP-CLI commants locally, and it will connect to our servers and issue the commands by proxy.

Install WP-CLI on your Local Machine.

To manage remote WordPress sites using WP-CLI, we need to have it installed on our local machines as well as the remote servers.
Instructions to install WP-CLI on your Windows are here, MacOS instructions are here.

Configure Aliases on your Local Machine

On your local machine create a local config.yml inside the hidden .wp-cli directory in your user directory.
As I am using MacOS the commands are the same as Linux. Windows users will need to adjust these commands to fit that OS:

mkdir ~/.wp-cli && cd ~/.wp-cli
nano config.yml

Inside the WP-CLI configuration file you need to add Aliases with full SSH paths to each of your WordPress sites root directories on your various servers.
In my case that is something like the following:

# Aliases
    ssh: superuser@remote-server-ip/home/superuser/webapps/an-example-domain/
    ssh: superuser@remote-server-ip/home/superuser/webapps/another-example-domain/
    ssh: superuser@remote-server-ip/home/superuser/webapps/yet-another-example/
# Alias Groups
 - @example
 - @another
 - @yet-another

Configure Aliases on your Local machine with SSH paths
Configure Aliases on your Local machine with SSH paths

Add RunCloud PHP into PATH

If we were to try to issue commands from our local machine to our remote servers now it still wouldn’t work. For example, if we tried to update the plugins we would receive an error:

$ wp @yet-another plugin list

No PHP Error
No PHP Error

(If you didn’t receive this error, don’t worry it just means you have already made these configurations for some other reason previously)
One of the benefits of RunCloud is the granular configurability of the PHP stack afforded by the custom PHP configuration. But this means that to get WP-CLI remote aliases to work, we need to add the RunCloud PHP root into our PATH.
On each of your RunCloud managed servers, if you issue the wp –info command, you will be provided the path to your RunCloud PHP binary. Copy the path highlighted here:

$ wp --info

Copy the path to your PHP binary
Copy the path to your PHP binary

Now we need to symlink this into our PATH so that the remote WP-CLI connection from our local machine can use it.
Do that like so:

$ sudo ln -s /RunCloud/Packages/php72rc/bin/php /usr/bin/php

Symlink the RunCloud PHP binary into the PATH
Symlink the RunCloud PHP binary into the PATH

Issue WP-CLI commands locally to manage WordPress sites remotely

We can now use these Aliases and Group Aliases to control and manage WordPress sites on our remote servers by issuing commands locally.
Lets list all the plugins on one of our sites. From your local machine terminal execute the following command:

$ wp @yet-another plugin list

This time WP-CLI on your local machine should successfully log in to your remote server and issue the WP-CLI command on it, and return the output in your local terminal. All being well, the terminal on your local machine should look similar to this:

Now Local WP-CLI commands should execute remotely
Now Local WP-CLI commands should execute remotely

Using Alias Groups Remotely

Now let’s use the WP-CLI Alias Group we created earlier to explore this potential further.
List the plugins from all the sites on all the different servers:

$ wp @all-examples plugin list

Use a Local Group Alias to manage groups of WordPress sites across different servers
Use a Local Group Alias to list plugins on WordPress across different servers

WP-CLI lists the condition of all my different WordPress sites plugins.
From the terminal output, we can see that I have 5 inactive plugins across the 3 sites on the two different servers, and one of the sites has a plugin that needs updating.
I can update all the plugins on all the sites, and activate them all with the following single compound command:

$ wp @all-example plugin update --all && wp @all-example plugin activate --all

WP-CLI now connects with all the remote WordPress applications and issues my remote commands, updating and activating all plugins on all servers.

Update and Activate Plugins across all the sites
Update and Activate Plugins across all the sites


From this I am sure you understand how, using WP-CLI Aliases and Alias Groups, we can manage WordPress updates and maintenance at scale, across no matter how many servers we have provisioned, in a much more efficient manner.
I have illustrated this principle using just 2 servers with 3 WordPress sites between them. But with the availability of affordable cloud servers, this could just as easily have been across 10 servers with 200 sites.
With appropriately configured WP-CLI aliases and carefully constructed strings of WP-CLI commands we can automate the most repetitive and mundane WordPress management tasks. In turn this will lead to efficiency savings and increased productivity that will help us as we grow our Web Development Businesses, perhaps to agency scale and beyond.
You can read more about the WP-CLI Configuration File here, and about WP-CLI Aliases here.

Simplifying Server Management

We build RunCloud to help you manage your cloud servers with total controls, and host your WordPress, WooCommerce, Laravel, and PHP applications with fast and easy configuration.

Start Your Free Trial

5 days free trial no credit card required cancel anytime

5 thoughts on “Maintain WordPress at Scale on RunCloud with WP-CLI Aliases

  1. I prefer using MainWP, making it really autonomous. It has lots of useful features like bulk install/delete plugins, uptime monitor, updraftplus backups, etc. and best of all, it’s free with no limits on how many WordPress sites you can manage.

    1. MainWP is nice, as are the other GUI based tools, ManageWP etc. I did mention in the article GUI based options for this but didn’t want to go into naming them all. I do think this will make a great future article, a comparison of WordPress management platforms, what do you think?
      But you can do all of that with WP-CLI, all for free, all automated. Takes a little more time upfront learning, but that time pays back dividends as part of your process.
      You can combine WP-CLI commands with scripts and run them on cron jobs. Check sites for updates, update sites, backup sites, roll-back sites, check the database for errors, optimize the database. The depth of tooling from using something like WP-CLI is unparalleled once you get used to it, you can use it to debug queries and bad actor plugins, set rollback points, create staging, the list is endless.
      The main benefit I find for these basic tasks though is the speed. When something is automated then this doesn’t really matter, it just happens on its schedule. But as soon as you need to interact with the management system because something isn’t quite right, then wp-cli absolute slaughters every single GUI based tool.

  2. I follow your tutorial, but I’m stuck after setup config.yml, all the aliases list down completely.
    But when I try to call out, for example “wp @example plugin list”. It turns out message “Failed opening required ‘wp-salt.php'”.
    How to overcome it?

Leave a Comment

Your email address will not be published. Required fields are marked *