Moving away from Runcloud

Published 5 minute read

For the last 7 years, I’ve hosted all my sites on a VPS. When I started, DigitalOcean had just hit in a big way, and it was a lot of fun learning nginx and MySQL (later MariaDB) configuration.

However, my stack got unmaintainable pretty quickly, and running updates broke config files and caused tons of issues. So in 2018, I moved over to Vultr and Runcloud to host my WordPress sites.

Vultr is an alternative to DigitalOcean and has a datacenter closer to me (Dallas). Their VPSs are also faster than DigitalOcean’s offerings. Runcloud sets up and manages your VPS for you so you don’t have to worry as much about your web stack and can focus on running your sites. It’s an alternative to Server Pilot and Cloudways, which are some other big players in this category.

For a while everything was great, the setup worked well and I was happy to pay a monthly fee to Runcloud so I wouldn’t have to pull my hair out while diagnosing stack configuration issues. However, these last few months have been really bumpy, and I finally decided to pull the plug for the reasons outlined below:

Runcloud’s stack is slow and unreliable

It was very fast two years ago, however over time it’s gotten increasingly slow and unreliable. I’m not sure what got changed, simple things like adding a new page or post on WordPress would bring things to a screeching halt while the server was pegged at 100% CPU usage. RAM usage would also jump up to insane levels, and I had to add a swap file to help solve frequent crashes from running out of memory. I only had 5 low-traffic WordPress sites on a VPS with 1 GB of RAM, which is more than sufficient.

On top of that, most likely related to the memory usage issues, the MySQL server would crash randomly every few days, and I’d have to ssh in and manually restart it.

SSL failures

Runcloud uses Let’s Encrypt to issue SSL certs. It worked great in the beginning and I moved all my sites to SSL because of it, however it started throwing renewal errors for all sites and the solution ended up being just issuing a new cert from CloudFlare. Granted, this is a minor issue.

Billing issues

The final straw happened on the weekend before December 14th. Apparently Runcloud changed their billing platform, which is fine, however they did not notify anyone of this change, which blows my mind. Why would you not send an email out to customers to let them to know to re-add their credit card info before their subscription expires?

As a result, my subscription expired on a weekend and when I checked my emails on Monday, I found that they had downgraded my account and deleted all my backups. And perhaps coincidentally, my server was down. Again.

When I confronted support about this, they insisted that posting such a major change on their changelog page buried on their website was sufficient:

The new stack

Fed up with Runcloud’s flawed stack and their poor handling of the billing platform transition, I’ve moved to a new setup and completely cut out Runcloud. This time I’m not going to rely on a service to manage my server for me.

The new setup is really fast, I’m using a High-Frequency Compute instance with 1 GB of RAM from Vultr, and WordOps to make managing the stack easier. WordOps is a fork of EasyEngine with a more active development team. It’s really easy to add new sites, run stack updates, and even add SSL. I’ve also got nginx fastcgi_cache configured and it’s super fast, I don’t need caching plugins for WordPress anymore.

Vultr has a really great firewall too, I was able to disable UFW on my VPS and save some resources. Vultr’s firewall makes it easy to only allow traffic that is routed through CloudFlare, and also update my IP address for restricted SSH access.

And the excellent WP CloudFlare Super Page Cache added support for caching on CloudFlare Workers, which is like CloudFlare’s APO for WordPress offering, only cheaper/free. I currently pay the very low fee of $5/m for Workers.

The best part: Adding a new page or post to WordPress doesn’t cause the VPS to crash and burn.

The next stack

Eventually, I want to completely migrate away from WordPress altogether, starting with this site. I’ve had a lot of fun lately using Eleventy and Tailwind CSS to quickly build extremely fast static sites, and CloudFlare Workers is excellent. It’s cheaper and faster than Netlify, and CloudFlare isn’t a startup anymore, so I have more faith their future.

CloudFlare also recently announced their direct competitor to Netlify, CloudFlare Pages, the main benefit compared to Workers is the easier automated GitHub deployment.

For some of my client sites, the serverless CMS problem still remains to be solved though - I prefer a git-based, self-hosted CMS, and right now the only option is Netlify CMS, which is currently unreliable for me. I suppose a good compromise would be headless WordPress via the Rest API.

WordPress is easy until you get into the hosting problem, and serverless is easy until you get into the collaboration problem.