I think many of us are on a constant search for a decent hosting provider. Personally I have used GoDaddy, BlueHost, a few random ones and most recently SiteGround. As times change so has site traffic use cases, and my needs. SiteGround was actually really goo initially and their initial sign up cost was pretty decent. Where they get you is the renewals and mine was coming due. In recent weeks I’ve had to spin up copies of sites for STK promotions to host inventory stores, along with their normal “shared” pop-up shops. I’ve needed to restore from backups and perform other operations and the issue was I was exceeding the SiteGround 24 hour CPU and inode usage even on their GoGeek plan. I started to look into their cloud plans but they start at $80 a month which seemed high. I started looking around and decided to give Cloudways a shot based on their platform. I will say it’s not all roses, but if you can get through some of the quirks, it’s got some decent features.
Cloudways is NOT Shared Hosting
First and foremost Cloudways is not shared hosting, it’s cloud hosted servers individually deployed for you. What makes them unique is they “broker” servers from various provider options into a single platform. So you get your choice of provider, cost, and sizing for what works for you. You can also mix and match providers from their single platform. This is a nice feature actually without having to go to each provider. Being that this is not shared, the resources are all yours so only you can push the limit of your server. From a cost perspective it’s a fraction of SiteGround’s starting price of $80 to get started and you can scale up your server in place. So you can start small, and with a free trial, and grow as you need to. There is also ideas I have about running more smaller servers for different use cases but the overall cost could be the same, but provide virtual server separation.
You can easily compare the side by side cost of each provider in one place.
Cloudways Server vs “Applications”
So this is an interesting approach to the hosting model. You deploy a server, but then you add applications to that server. Each application is deployed with its own database, php settings, cache settings, and can have separate SFTP users created. While you have server level settings for some of this, you can individually control them per application. This provides some interesting use cases but also has some drawbacks. While you can clone an application NONE of the application specific settings get cloned. This seemed odd to me and would be a great feature add. Afterall, if you customize php, varnish, and other things then clone it for testing or staging nothing will work right until you reset all those settings. I like the per app isolation idea though, it has some merit.
Cloudways WordPress Migration
I will say this their migration tool works near perfect. Outside of the additional application level settings you may have to tweak the data moved easily and quickly. I’ve tried other tools and this one just worked. Not much more to say about it. They do a nice job with the domain name change to the site from it’s default as well as Let’s Encrypt SSL.
Cloudways Caching Tools (Varnish and Breeze)
Okay these two things ran me down a rabbit hole. First of all BOTH are installed and enabled when you add a new application. Varnish is server level and app level enabled by default. Breeze is their WordPress plugin and on new apps and migrations it’s installed. That’s fine and dandy, but my issue is they “say” a lot of common things are excluded in both tools for URLs and cookies for applications like WooCommerce. I can tell you it’s simply not true. If it were I would not have had to fix, fight, and troubleshoot my way through very specific exclusions for some of the more common cookies and URLs as see below at the Varnish Level. The breeze plugin can only exclude URLs but in most cases a URL excluded in Varnish needs to be excluded in Breeze. one HUGE issue I found was if you are using the built in custom CSS function in WordPress it HAS to be excluded. It simply doesn’t work. Below is a list of exclusions I have running mainly on WooCommerce Sites. Please comment and add to it.
URLs /wp-cron.php* /wp-admin/ /wc-api* /?wc-api* /?custom-css* cart checkout Add-to-cart \?add-to-cart= ^/(cart|my-account/*|checkout|wc-api/*|addons|logout|lost-password|product/*|wp-admin|wp-login) Cookies wp-resetpass-.? wp-postpass_ woocommerce_cart_hash wp_woocommerce_session_ woocommerce_items_in_cart
/wp-cron.php* /wc-api* /?wc-api* /wp-admin/* /product-category/* /?custom-css* /cart/* /checkout/* /Add-to-cart/* /my-account/*
My suggestion is if you run into issue first thing you do is disable varnish on the application and see if things seem to work right, re-enable it and start excluding. The other thing to be aware of is there is no Object Cache by default. You will need to install Redis on the server side of things and also the Redis plugin. This is VERY specific if you have multiple applications and well documented so pay attention to the wp-config file entries.
All in all their support is responsive, the cloud server hosting seems to perform, but you need to get past the tweaks on the Varnish and per application settings. You may need to take some time and do some testing but the cool thing is you can get a free trial to play with for a couple days to see just what works and what doesn’t. If you are up for renewal at SiteGround especially and on the GoGeek level product you can probably save money or spend the same and get into your own cloud server and get off shared hosting.