Cloudways Auto Scale Review

Recently, Cloudways announced the new release of their Autoscale solution for WordPress. Naturally as a Cloudways fan, I wanted to try it out so I signed up for the public beta. The idea behind such a solution for WordPress honestly is the first I have seen. Most folks have been used to running WordPress on a single or shared server, and I have been using Cloudways servers for hosting for a few years now. The blog and other sites have never performed so consistently well since I moved over. That being said I decided to fire up an application and migrate The Peacemaker Project 703 Store over to it. This site is the perfect candidate for this solution being it has spikes during sales and promotions. The following will be some interesting findings as I performed the migration and subsequent tweaks to the site’s configuration.

The Cloudways Autoscale Architecture

Cloudways has done a great job with the online materials so I will not cover this in depth. The diagram below pretty much explains the Kubernetes deployment they are using. Your individual applications will run within this architecture, providing load balancing and redundancy. Those two things have long been a challenge for WordPress sites due to the static nature of the web files. The database could always be shared on a highly available cluster, but they seem to have figured out some secret sauce for the web pods. At the end of the day, this is all abstracted from you with the exception of the SSH access and limited control panel functions.

Cloudways Autoscale Pricing

This is where things for me get a little strange to be honest. The initial pricing for one application is $35/month, which includes CloudFlare Enterprise integration and the autoscaling capability. This price is actually VERY good when you compare to a production server with them on their new pricing with Vultr which is what I was using. That same server is $60/month plus $4.99 to add the CloudFlare Enterprise add-on. The difference is you can run a couple applications on that one server if you choose. The Autoscale offering is PER APPLICATION only.

The tiers then go up from there, and sadly there is no single application at a time add on, up to certain price breaks. So if you need four applications you have to pay for ten. This is something I told them needs to be fixed. Charge me $35/month per app up to three, then let me add individual apps at the three tier price ($30/month per application) until I get to ten, and so on. That only makes sense for people to have flexible options. We will see what they do, but I think there is massive room for improvement they can make here.

Migrating To Cloudways Autoscale

Creating the new app is pretty simple and straight forward. Give it a name and select a region, which currently there is only one.It takes a few minutes to spin up but then you will be presented with some basic information, but it’s lacking some key things to migrate. You will see these fields

• SSH/SFTP
• Domain Management
• Database

SSH/FTP is pretty straight forward and can be used for your migration tools, as well as direct access to the files. I also used this for the VaultPress configuration in order to do any restores. You can add other users to the list as you need.

The Domain Management is used to actually re-write the site from the default domain. You can do this before or after the migration of course to “Go Live”. This will also invoke all the steps to setup CloudFlare Enterprise, which means a validation TXT file and then a CNAME update.

NOTE: If you are moving a site already on Cloudways with a domain and CloudFlare Enterprise Add-On you need to remove all the settings first!

Finally the MySQL information is available for your migration tools, except one crucial part.

You will notice there is NO Server Address which is needed with most migration tools. The issue is on most hosts MySQL is on LOCALHOST, but here it is in fact remote. I’ve asked that they include this vital information in the UI in the future. However, in the case of the only available region in South Carolina the database server information is

• mysql.databases.svc.cluster.local

As you can see this is a local FQDN, so even in other regions, it may remain exactly the same, that is yet to be determined.

IMPORTANT NOTE: The last and most important part of the migration you need to do BEFORE you start. You will need to download/save a copy of the wp-config.php file the new app is using. This is required to re-use since it has some very specific things to the architecture. When you migrate your app your previous config file will be copied, but you CAN NOT use it. You will need to replace it with the original one and copy and custom information you had over. This would also be important to note for a migration back off Autoscale as some of that custom info for the architecture will not apply.

I have told them this is a very important thing they need to tell people migrating over or some things like Object Cache Pro (if it was previously configured) won’t work right.

Cloudways Bot Protection Note: Additionally it is important if you are migrating from another Cloudways server if you have Bot Protection enabled to disable and remove the plugin as well as the malcare-waf.php file. It seemed maybe this was possibly messing with connections and WooCommerce Scheduled actions. I had to clear those out to check, and will inspect ongoing.

Other Missing Things In Cloudways Autoscale

Two big things started to stand out as I was configuring the site post migration. The lack of the ability to do staging, which I think is coming soon. However this could be a big issue if not released very soon. To me the lack of this would prevent Cloudways Autoscale from every being “production ready” and out of BETA.

The other missing information that is pretty key for most people is the external IP’s that your applications will use to communicate. For example I use external SMTP Relay services from Google Workspace configured via a mail plugin. The relay has always used a source IP whitelist to relay mail. I could not locate these public IP addresses anywhere to whitelist. After going back and forth with support they seemed to locate those for the South Carolina region.

Again I told them this should be available in the dashboard by region as it would be the same for all apps in that region according to them. So simply show the information for those that need it.

The other noticeable missing item is the lack of any PHPmySQL access or other Database inspection tool. It is CLI only currently.

Lastly, I have seen some odd issues with WooCommerce Zaps not sending to their webhooks and I am not entirely sure why. I have not opened a case with Cloudways yet because I was told everything should function the same as when it was on a flexible server, but I need more time. Also I use Duplicator Pro, and I may share a post specific to that plugins settings that needed to be oddly specific to work in this new environment.

Cloudways Autoscale Review Summary

I was and I am still super excited about this offering. The concept around paying for a WordPress application to scale automatically UP AND DOWN with load is a nut I think a lot of hosting providers have yet to crack. While this is still in Public Beta, based on some of my findings, issues, and feedback above I do not think I agree with one support person’s assessment that while it’s ;labeled beta it’s “Production Ready”. I think it is what we call in the software business MVP (Minimum Viable Product), but it needs work. Specifically on these areas.

1. Per Application Pricing Model vs “buckets” of applications for lump monthly cost
2. Proper and Complete migration tools that account for the custom wp-config.php file
3. Database server settings visibility
4. Staging Management
5. Server IP information visibility for whitelisting needs on external apps like SMTP relays

I will continue to let the application I moved over run, but if I still see issues with Zapier triggers not firing or other odd issues I may need to move it back to a flexible server instead, even though that actually costs more money, it just worked. I am not sure those Zapier issues are a result of the new architecture or not it’s too early to tell until more orders come into that site and we see if triggers continue to fail. That would be a huge issue for sure as there are a lot of WooCommerce triggers to fire off multiple automations.

Otherwise I am curious to hear what others running on the platform have found, especially if they agree with some of my findings or are seeing some odd issues like I am.

Cloudways Autoscale Updates 5/11/23

After much testing, unfortunately I had to move back to a Cloudways flexible server. There were some clear issues with both the load balancing of the WordPress Pods as well as the database cluster. I’ve logged all this with Cloudways and they even have a copy of the site running at zero cost to me for further investigation. The key issues and plugins with database problems were:

• Woocommerce Bulk Editor (Pimwick Plugins): DB Issue
• WP-Mail SMTP: Load balancing and DB issue
• Duplicator Pro: DB and Pod resource issue
• Generally poor performance on backend operations (navigation, plugin updates, etc)

I still think folks should run their own tests and provide more feedback as the concept has a great deal of potential.