Implementing a Modern WordPress Workflow on Alibaba Cloud — Part 1

By Jeff Cleverley, Alibaba Cloud Tech Share Author. Tech Share is Alibaba Cloud’s incentive program to encourage the sharing of technical knowledge and best practices within the cloud community.

In this series of tutorials we will implement a modern development and deployment workflow for WordPress on an Alibaba Cloud Elastic Compute Service (ECS) instance with LEMP (Linux, Nginx, MariaDB, PHP) installed. This workflow will create and utilize staging and local development environments, alongside the live production site. It will use the <>Git version control system to push changes to the staging environment for testing before updating the live site. In Part 1, we will create and secure a staging site subdomain.

We will create the staging site on the same server as the production site. Although, with minor adjustments, the steps in this guide could be used to configure a staging site to deploy to on a different server.

This tutorial follows on from the previous series of 5 tutorials that instructed you how to set up WordPress on a LEMP stack. These are:

  1. Part 1 — Provision and Secure an Ubuntu 16.04 server
  2. Part 2 — Completing the LEMP stack
  3. Part 3 — Configuring your Domain and Let’s Encrypt SSL
  4. Part 4 — Installing WordPress
  5. Part 5 — Using DirectMail for Transactional Email

The live site used in the present tutorials does differ from the above tutorials, in that is has been created in its own directory within the /var/www directory, and uses its own Nginx configuration file located within /etc/nginx/sites-available/ directory (symlinked into the /etc/nginx/sites-enabled/ directory). In the previous tutorials the WordPress site files were located within the /var/www/ directory and used the /etc/nginx/sites-available/default configuration file appropriate for that directory.

That being said, this step by step guide and the methodology in this tutorial will work on any LEMP stack for WordPress, assuming that all the required components are installed. There may be slight differences in configuration files, which may require alterations on the reader’s part, but these should not hinder completion.

All instructions in this tutorial will be issued by my superuser, ‘new_user', using the sudo command where necessary. Please replace my superuser with your own when issuing the tutorial's commands yourself.

The tutorial examples will also be using ‘' as my main site domain, and '' as my staging site domain, remember to replace these with your own site domains and staging site domains in the relevant files and commands.

Step 1. Create Your Staging Site Database

$ ssh

Login to your MySQL database as your superuser.

$ sudo mysql -u root -p

These tutorials are using MariaDB as a drop-in replacement for MySQL, so we will receive the welcome from the MariaDB monitor, and the command prompt will change to the MariaDB prompt.

Create the database required for your WordPress staging site, in my case I will call this ‘staging'.

Do so with the following MySQL command:


You should receive a ‘Query OK' response from the MariaDB monitor, indicating the rows affected and the time for processing your query. This indicates that the 'staging' database has been created successfully.

Now create a database user and password, and then grant the user all access to the ‘staging' database:

GRANT ALL ON staging.* TO 'new_user'@'localhost' IDENTIFIED BY 'new_users_password';

Of course you should replace my simple password with a very secure password of your own. Now flush privileges:


And exit MariaDB:


Your terminal should now look something like this:

Step 2. Configure Your Staging Site Subdomain and DNS

You will see your websites main domain in the list. Click configure:

Click ‘Add Record’ to add the new DNS record for your staging domain:

Add a new ‘A' record for the 'staging' host, with your server IP as the value:

Step 3. Configure NGINX to Serve Your Staging Site Subdomain

$ sudo cp /etc/nginx/sites-available/ /etc/nginx/sites-available/

Create a symlink for your staging sites newly created Nginx configuration file in the /etc/nginx/site-available/ directory to the /etc/nginx/sites-enabled/ directory:

$ sudo ln -s /etc/nginx/sites-available/ /etc/nginx/sites-enabled/

If you cd into your /etc/nginx/sites-enabled/ directory and list all contained files with the ls command, your terminal should now look like this:

Open your newly created configuration file for editing with root privileges:

$ sudo nano /etc/nginx/

As this file is a direct copy of your main site’s Nginx configuration file, it will contain settings for that domain’s ‘root' folder and for its 'server_name'. These will need changing.


root /var/www/;


root /var/www/;

The configuration file will also contain several directives for your main sites Let’s Encrypt SSL certificate and HTTPS implementation, as configured by Certbot — these will be marked with ‘# managed by certbot'. Remove them all, later we will use Certbot to issue a separate SSL certificate for our staging site, and it will re-add the correct directives itself.

Your Nginx configuration file for your staging site subdomain should now look something like this:

Whenever you edit your Nginx configuration files, remember to check the syntax for errors with the following command:

$ sudo nginx -t

Assuming all is well, reload Nginx:

$ sudo systemctl reload nginx

Step 4. Issue Let’s Encrypt SSL Certificate for Your Staging Site Subdomain

If you haven’t already installed Certbot, you will need to install a package that is required to add external repositories to the ‘apt' package manager. Do that with the following command:

$ sudo apt-get install -y software-properties-common

Now we can install ‘certbot', do that with the following commands.

Add the ‘certbot' repository:

$ sudo add-apt-repository ppa:certbot/certbot

Update your ‘apt' package list to pick up the new repository's package information:

$ sudo apt-get update

And finally, install ‘certbot':

$ sudo apt-get install python-certbot-nginx

After completing these commands, you will be able to continue on to the next section and issue SSL certificates using ‘certbot'.

However I advise you to follow the following commands and issue an SSL certificate for your main site. It would be good to go through the process in this tutorial.

If you have already installed Certbot

To issue an SSL certificate for your staging site subdomain issue the following command:

$ sudo certbot --nginx -d

Certbot will ask you for an email address to register the certificate to, and ask if you would like to enable HTTPS redirect.

Assuming everything has been configured properly, your certificate will be created and certbot will add the necessary directives to your staging site's subdomain Nginx configuration file. These will allow Nginx to serve your site over HTTPS, alongside a directive for the HTTPS redirect if you enabled it.

Even though the domain is now protected by an SSL and can/will be served by HTTPS, it is still using weak Diffie-Hellman parameters, meaning the initial key exchange is still more vulnerable than it should be.

To fix this, we will create a new ‘dhparem.pem' file and replace the certbot managed 'ssl_dhparam' directive in the NGINX configuration file with our own.

Create the new file using ‘openssl':

$ sudo openssl dhparam -out /etc/ssl/certs/dhparam.pem 2048

This may take some time. We could increase security by adjusting the bits from 2048 to 4096, and the time taken would increase accordingly.

Open your staging sites Nginx configuration file with root privileges:

$ sudo nano /etc/nginx/sites-available/

Locate and remove the ‘ssl_dhparam' directive that is '# managed by certbot', and add the following directive in its place:

ssl_dhparam /etc/ssl/certs/dhparam.pem;

Now your configuration file it should now look something like this:

Remember to check your Nginx configuration files for syntax errors, and reload them if they are okay:

$ sudo nginx -t
$ sudo systemctl reload nginx

Step 5. Create Your WordPress Staging Site Directory

We have a choice to make, we can create the staging site two ways. Tutorials Part2 and Part 3 will each explore a different way:

  1. Part 2 — Create the Staging & Local sites Using Duplicator and SFTP
  2. Part 3 — Create the Staging & Local sites Using the Terminal and WPCLI

After completing both of these processes in the next two tutorials, we will move on to creating a version control deployment workflow using Git, in the final tutorial.


Follow me to keep abreast with the latest technology news, industry insights, and developer trends.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store