WordPress Deployment Workflow: Amazon LightSail, Github, and Revisr

This route which make living the WordPress life much easier, and much faster than with FTP.

So main idea:

• LightSail has SSH terminal which can be used to deploy code from Github
• Github is a version-control code storage platform that also can be used as a backup option
• A remote database (using AWS’s RDS or Google Cloud Platform) so that database can be sync from localhost and staging site
• A remote storage for files / images for easy access
• Revisr for auto-pull new codes from GitHub into the staging live site

In this post, there will be the idea. To look for useful instructions on how to do exactly each step, please refer to the documentation.

1. Amazon LightSail as a WordPress hosting

Amazon LightSail is one of the Amazon Web Services (AWS) which is quite cheap compared to other hosting service I tried before. With $3.50 / month you can run a small website smoothly.

LightSail runs with instances. A website can be created by making a new instance in LightSail. To upgrade the hosting plan or restoring from backup, just simply create a new instance from the snapshot of old one. So it is like “remove and create new”, kind of.

I like LightSail because it gives you access to an SSH terminal so that you are free to run commands and config. It also has automatic backup feature.

However, you will need to install SSL (https) for your website manually. If you run several website instances under a load balancer (which cost an extra $18 a month), SSL will be handled by the load balancer.

2. Github: A version-control platform to manage your code

If you only use WordPress as a blog and don’t need to customize the theme or change any code, you don’t need GitHub. Because it creates the hell much of code change for each commit when you need to upgrade a plugin or install a new one.

But, GitHub makes WordPress migration much much easy which LightSail, when you can just access SSH terminal and run the magic “git push”. Bam! All files uploaded in a second. Better than any FTP client.

The bad thing is, GitHub does not store MySQL database. So you would need a plugin to migrate the old database to a new one, which also can be done quite easily with WP Migrate DB Pro or WP Synchro. Without GitHub, you can try MigrateGuru, but it only works for some hosting.

You would need to purchase the Pro versions of those two plugins mentioned above if you want to migrate files also alongside with database.

3. A remote database to sync between local server and staging site

With a remote database (for example AWS’s RDS or Google Cloud Platform), you will have an URL of the database that can be pasted into wp-config.php. So when running a local host instance or visit the staging site, you can have one unique database source. So no need to duplicate all the changes into the live site when everything is ready!

I don’t like so much this remote database because:

• It is not easy to visualize the database tables. You would need to know about WP CLI to draw it on your terminal. But, if you don’t need to see the database then it is not a problem
• It is slowwww to run on local site (I am running LocalbyFlywheel). Other WordPress sites which has the database on the same local machine runs very fast, so I will just blame the remote database for now

But it makes development easier without extra step.

4. A remote storage for media files

Similar to the remote database, the remote storage is for easy development of WordPress sites on local machine.

Currently we are using S3 buckets (Google Cloud Storage Bucket works the same). So images will be uploaded to this cloud service and return an universal URL that can be displayed anywhere.

So the benefits of outsourcing the files is that the migration phase will be easier. Because images are separated from the WordPress instance, you don’t need to make the migration for them.

And if you accidentally delete an image from the WordPress dashboard, it will still stay somewhere else on the cloud.

Bad things:

• It is impossible to visualize the images as easy as in a Windows explorer. So I guess creating meaningful image names will be helpful.
• AWS CLI is needed for bulk-download. Or, you can go to each image, open it in a new tab and download from there :((

5. Revisr for auto-pull code from Github into WordPress instances

I haven’t thought about Revisr or any automatic deployment until we started to run several instances for the main website under a load balancer.

So each time pulling new code, I will need to access the SSH terminal and run the same code several time.

Revisr took me a lot of time to try and fail. And finally it runs. I think it worth trying because it would save you a lot of deploying time then.

Revisr is a plugin you will need to install on both live sites and local host. It watches your GitHub repo. When an action is made, for example Git Push (default), it automatically pulls new codes to your staging site (or production site).

To use this Revisr, some configs must be done on the server. With Amazon LightSail, I failed to install Revisr with SSH authentication, so I use HTTPS, which will reveal the username and password in the WordPress dashboard.

A way to hide your real password, you can create a GitHub Personal Access Token that serve as the password in the HTTPS link.

Check this post to know how to install Revisr on WordPress instances deployed with GitHub into LightSail.

To sum up, here is what you can do with the setup:

• Use GitHub to store all of your codes for the WordPress site
• Use a remote database to store your database and include the db URL in the wp-config.php file
• Use a remote storage to store all your images for WordPress

Deployment steps

In your live server:

• Setup Revisr to watch the same branch than your local machine

In your local machine:

• Pull codes from GitHub
• The wp-config.php file already contains information about database so no need to setup a local database
• Make changes, push code to GitHub and the code will be auto deploy to your live site with Revisr. Database no need to make change because they are the same in local host or live site => super fast!