I have been running my blog out of my house since forever. While at VMware, in addition to my WordPress VM I was running many other VMs in my home lab. Given my job change, I have less of a need for my home lab. In fact, the only VM I had left was my WordPress VM. Given this, I decided to move my blog to my Synology box. Read on to learn more!
Before I begin, let me explain why I decided to run my blog on my Synology. First, I use Synology for a variety of purposes including to host CloudStation, which I use instead of free, public cloud alternatives. Given I am happy with this set up, the Synology is going to stick around. Synology also offers a variety of additional packages that can be installed and WordPress is one of them.
Some people have asked me why I did not just run my blog on a public cloud. The primary answers are cost and operation. I am already running Synology at home. I already pay for Internet access at home. All running WordPress at home introduces is some additional CPU and memory utilization. Compare this to a public cloud, which may be free to start, but will eventually cost money. In addition, you need to secure and monitor what you deploy — something already addressed in the home lab as well. Finally, we have consistency. If I can reduce the number of touch points and operate everything consistently then it makes it a single thing to worry about.
I started by attempting to install and configure the stock packages available. As mentioned, Synology offers a WordPress package, which installs Apache, PHP, and MariaDB. This was trivial to install, but had an interesting caveat — it only worked with Apache 2.2 and PHP 5.0. I really wanted Apache 2.4 and PHP 7.0 and while these packages were available, the WordPress package did not allow their use. Now, installing WordPress is trivial, but I suspected the WordPress package on Synology was specifically customized for WordPress. How could I get the best of both worlds?
The workaround I came up with is that I installed the stock WordPress package with its dependencies and manually made some changes. After installation, I manually stopped WordPress, Apache, PHP, and MariaDB. I then opened File Station and navigated to the “web” directory. I copied the WordPress directory to retain everything it contained. Next, I uninstalled WordPress and all of its dependencies. I manually installed the Apache 2.4, PHP 7.0 and MariaDB packages. Finally, I opened Web Station and manually configured a virtual host to point to my copied WordPress directory (I also used this as an opportunity to enable HSTS) and ensure the proper PHP extensions were enabled. Viola! Well, short of… Opening a browser to the newly configured site resulted in a 500 error. It turns out the custom WordPress package does have some Synology specific dependencies. The solution was to simply edit the wp-config.php file and comment out the Synology specific configuration file.
I did experience a few issues post migration. First, I could see in the error logs that a couple of my tables in MariaDB were not happy. They were related to a plugin and I was able to manually fix them. The error logs also indicated that I did not have enough PHP processes running. This can be increased from the Web Station PHP section. When I increased I began to run into memory issues on my Synology (it is a much older model). I ordered 4GB of memory and installed it in the Synology, but then ran into a constant CPU peg issue that resulted in an unusable Synology box. After a lot of troubleshooting, I learned the memory stick we not compatible and was causing issues.
I have been running my blog on Synology for several months now and have not had any issues. Performance has been comparable to running standalone and my homely footprint has been significantly reduced. At some point, I need to upgrade the Synology, which will give me more resources, but at this point everything is working as intended.
© 2018, Steve Flanders. All rights reserved.