Nexcess vs Cloudways? Which Magento 2 host?

My Brief

I’m going work on setting up a server on DO, however I have a feeling that I will end up with a more managed solution so I can sleep a little better at night knowing that everything is being somewhat looked after with a solution like cloudways or nexcess. As i’ve mentioned in my other post, security and optimization are extremely important for the performance and stability of things.

I’ve been reading through a lot of the articles and watching videos on the DS site. I have noticed previous mentions of Nexcess being the suggested option, however those suggestions were also prior to the undercover review of cloudways.

I’m wondering what are the opinions of one vs the other? I currently just opened an account with Nexcess cloud hosting and had opened an account with cloudways for testing. Price would not be a deciding factor between the two.

One thing that I notice is that Cloudways is based out of Malta and Nexcess is based out of the US.


There’s not a lot to say here, than I already talked about in Cloudways Review: 30 days undercover as a customer (Magento 2 Managed Hosting). Obviously, I had problems - I made sure to keep the “issues” in the video. For example:

  • Some automated tasks that I actioned from the Cloudways Portal didn’t work correctly and I had to ask their Support Team to fix an issue
  • Live Chat wasn’t as good as Ticket Support (If you can get past the annoying Chat Bot)


I’ve not used Nexcess for a couple of years now, plus they’ve changed their plans. However, I still have positive memories of their support. The only real “issues” (although not really) that I remember were:

  • They setup the server manually, so they require 24 hours to setup the server
  • Their Portal isn’t as shiny and fancy as the Cloudways Portal

It’s not really fair for me to point out any other differences though, as I said things may have changed since I last tried Nexcess.

What I can say though is that when I was considering Nexcess as a Dedicated Web Host back in 2017, I had a very positive conversation with one of their Sales Reps at the time. The only reason I didn’t pick them up is because I decided to stick with a host I’d already been using for years.

I’d be interested to get your input on how your experiences compare as you’re trialling both in tandem.

My Experience So Far

I’m more than happy to share my experience thus far. I’ve had nothing but a good experience with Nexcess over the last 8 years. I’ve even been running on a shared server and it has been decently well. I think it was a good option when we opened this particular store then, however the times and the store/business have grown a lot since then.

Nexcess is pushing their cloud infrastructure. One of their reps told me their cloud setup would beat the socks off their SIP-200 plan. I have no other data to back that up since I don’t have installations on both.

Nexcess’ support is still great IMO. I’m getting more experience with it right now as I’m dealing with a couple issues on the cloud service. It’s nothing major, but they’re working on it. I do have a full blown subscription to both nexcess and cloudways right now.

Cloudways has also been helpful as I’ve run in to a couple permission issues on their setup as I’m trying to install a pwa. So far their support has been great. Cloudways performance has been great as well. I have pitted both hosting services against each other on a base install on pingdom and the load times were .5-1.0s (no sample data though).

At this point, both are very comparable. Cloudways does offer more for the price, I think. Nexcess somewhat hides the available resources for your cloud infrastructure, so it is hard to compare apples to apples as far as system specs. Cloudways does include elasticsearch, redis and varnish in the default plan. The good thing is that with Nexcess these are options that can be added on with a “container” that’ll cost you an extra $20 a month each. Nexcess does have redis included though. Redis and Varnish are often both required for a PWA.

I will provide additional details on my experience with them both as I move further along. I’m sure at some point I will exhaust their support (either from small issues from their setups or permission issues) or run in to a limitation that they won’t allow me by, thus forcing me one direction or the other.

I look forward to an update in the future :slight_smile:

Thank you, @live4soccer7

I think I’ll be installing sample data this evening or tomorrow on both installations. From there, if I can’t get the PWA installation functional then I’ll likely move to Porto for the time being. I think with sample data and a full featured theme such as porto, it will provide some insight on real performance comparisons between the two. They should both be adequate, however it will interesting to see.

I used the restore feature on cloudways and it worked flawlessly as far as I can tell so far. I had an issue with the nexcess cloud restore. They are currently looking in to it. A restore feature absolutely has to be reliable. There is no compromise on that.

Nexcess vs Cloudways (Test 1)

Here is some additional information on both. I ran the tests multiple times with the numbers not changing significantly.

Cloudways install - 4GB 2 Core Plan ($42/month, varnish functional, redis not activated)
Debian 9.11
Out of the box default mode
406ms, 75 Grade, 190 requests, 930KB Pingdom (home page)
Sample data installed, .489s, 83 grade, 208 requests, 1.3MB (home page) Pingdom
Sample Data Installed, 3.2s, As across board, .358TTFB, webpagestest

Nexcess Cloud XS Install ($49.99, no varnish, redis preconfigured)
CentOS 7
Production out of the box
1.07s, 77 grade, 190 requests, 815kb Pingdom (home page)
Sample Data Installed, 1.03s, 77 grade, 208 requests, 1.2MB Pingdom
Sample Data Installed, 3.7s, TTFB=C, .938TTFB, webpagetest

I was able to install sample data without issues on cloudways.

I had issues with installing sample data on nexcess. There was a patch they said that wasn’t successfully applied that had to be removed??? They increased php_mem, which I had already done on cloudways. I wasn’t able to make it far enough in the nexcess install to find that an issue. They proceeded to install the sample data while I was sleeping.

At this point, I have found cloudways to have less issues and the particular plan I’m on is faster on a server with no load. I’m going to create an additional backup over at cloudways and have my hand at installing PWA again. I started with both of these at the same time and I am naturally making quicker progress on cloudways. Both customer supports have been helpful and responsive. I am still waiting on a resolution from nexcess regarding the restore/backup problem. It has been about 36 hours.

Edit: I think I’d like to do some sort of security audit at this point. Any recommendations on sites/modules/etc… that would be good to get some insight on both of these setups in regards to security/vulnerabilities?

I am also open to running other tests upon suggestion at this point. I can check whatever anyone would like. Just let me know what you think would be good or what you would like to see.

1 Like

Nexcess vs Cloudways (Test 2)

I just ran the free security scan from magento on both sites.

Again, these are both stock/base setups that I have done nothing too besides install sample data at this point.

Failed ReCaptcha

Failed ReCaptcha
Brute Force - Admin panel was discovered at a common URL
Magento /pub/ - Your Web server is configured to run Magento from %MAGENTO_ROOT% directory.It is recommended to set %MAGENTO_ROOT%/pub as a Web server root directory.
SSL / TLS - Your server supports TLSv1.0. Please update your configuration to discontinue TLSv1.0 support.

These all seem like easy things to fix. I’m not sure how to change the directory setup on the Magento /pub/ error. I did notice that Nexcess had their files configured slightly different on the server and this would explain that. What other security checks/audits would you guys suggest?

1 Like

I contacted Clouways in regards to this report to bring this to their attention so that perhaps they could build this in to their deployment since it is basic configuration and not add ons. They replied with the following:

Thanks for your kind update. The recommendations from the security report you have shared are all possible. I will share the details and the solutions one by one:

1- For Recaptcha, It’s definitely a tool that protects the server from any spamming and other main vulnerabilities and for this you can install a Magento extension to validate your Contact form. Sharing an extension link which you can use:

2- The Brute force is specifically mentioned for the /admin page which is usually common for a Magento website. You can definitely update the /admin to some other random name so that it could be saved from any brute force attacks. Sharing a link for your reference:

3- For Magento to use /pub as a webroot. This is also possible and easy to set up for the Magento store. Sharing a link for your reference: - Before this, you might need some configurations to be done from the perspective of the application, this has to be updated in the config file:

4- To restrict application to use a higher TLS version. You can follow this guide:

Let us know if you have any further concerns in this case.

Kind Regards,
Shahzaib Khan

They replied with this information within hours of providing the .pdf with the report. That is very good to know that their response time on something slightly more serious and likely less inquired upon is good.

Just a matter of minutes and I changed admin url and the TLS versions. Rescanned and those are gone. I don’t want to install any modules right now, so I’ll leave the recaptca alone and I’m not too concerned about the webroot thing right now. If I end up going with couldways then I’ll resolve both of those issues.


Absolutely awesome reporting so far!!

Just a point of reference for the response:

  1. reCaptcha modules are kind of obsolete after 2.3.x released the overhauled reCaptcha options under Stores > Configuration > Security > Google reCaptcha. No need to reCaptcha for Backend if you’re using 2FA. When using reCaptcha on Frontend use “Invisible reCaptcha” as it only challenges suspicious users and doesn’t annoy/hassle the legit users.
  2. Interesting fact: When installing M2 from scratch, it automatically assigns a random /admin URL now. I guess their custom installation script doesn’t account for that
  3. Super simple just to follow the Official Magento Documentation.
  4. Great to see an easy way to update this from the Portal. It saves the hassle of messing with the actual configuration file via SSH for inexperienced users.

With reference to your security checks, other than bringing on a accredited security agency, the only tool I currently use it the Magento Security Scan. It’s kinda limited but it’s great to gauge issues. I’ve been anticipating their release of the SSH scanner that they’ve been promising for a while now. That will be super useful.

Did you play with the Staging Tool on the Cloudways Portal yet (I apologies if you already mentioned this). When I was doing my review, I had permissions issues every time I update Staging of tried to push Staging to Production.

After you’ve finished your testing (if you don’t mind), I’d like to tidy and re-edit this under a single formatted post for others to use. What you’re doing right now is invaluable to new users. Thank you so much.

Thank you very much for the input. Oddly enough, I don’t have that option in my cloudways account. I saw that in your video and I wanted to inquire about it because that is a huge help when working on the store, updates, etc…

Today, I created a new magento instance on cloudways as I think I do have some artifacts from an attempted install of a pwa from the very beginning. I’ll be walking through all the same steps I’ve done in this thread up until this point.

Feel free to format/reformat however you like. The more I work with these solutions, the more I want to attempt to setup something directly on DO as well. I’m having a hard time finding time right now though as it is very busy with end of year business related activities. Something I don’t enjoy participating in.

BTW, still no resolution on the backup/restore function on Nexcess. That’s a bit disappointing.

I was able to get redis activated and functional on Cloudways. They have an article that explains how, however there is tiny comma that has to be added or the code fails. It took me a few minutes to find that. I put it all in phpstorm to help follow all the bracketry.

I do have a question though. Is there really any benefits from using Ubuntu vs debian, vs centos, etc…? What do you recommend for a setup on DO (version included)?

I know that feeling. I drove over 400 miles (Wed-Thu) to attend meetings etc. Got back this afternoon. Not sure how I’m still awake :slight_smile:

I agree as I’ve been praising them for years :confused:

Nope. Go with what you know and stick with it. I started with Ubuntu and stuck with it for consistency/continuity reasons. There’s no security benefits over one than the other. Like I’m a Microsoft/Android guy and know zero about Mac products.

Testing Digital Ocean

Wow, i’m not sure how I’d be functional either after driving that much and then going through meeting. Driving exhausts me.

I went through your DO video. It was fantastic. I followed it exactly and learned a bit about setting up the server.

Digital Ocean Fresh Install with Sample Data, no varnish, no redis, no nginx (home page)
Pingdom: 75 Grade, 1.2MB, 1.95s, 200 requests
Webpagetest: As F on static content, 3.36s, TTFB .309s, 200 requests, 1.03MB

I installed on Ubuntu 16.x.x(LTS), Magento 2.3.3

I have done zero optimization, obviously.

An update on Cloudways. I deleted my current M2 install and created a new one at cloudways. I wanted to go back through the setup on 100% fresh install and do the sample data etc… I ran in to issues even installing sample data. I think they have some sort of weird permission issue over there, honestly. I’ve seen chmod() not permitted while using composer. There has also been a cache issue when trying to run an install through composer. I needed to add a cache directory to magento’s composer.json file. The other problem that I have ran in to several times now on cloudways is that I will do some composer actions involved in sample data installation and the server will peg at 100% CPU usage and will not come off that usage 80-100%. Of course, this absolutely destroys usability of frontend and backend. Luckily, their restore option actually works so I can resort back to the “vanilla” install.

I have yet to play around more with nexcess at this point because I’m still waiting a resolution on the restore/backup issue and I don’t really want to experiment much without being able to easily revert back to my base install with the sample data.

Honestly, my best experience thus far has been hands down what I just did on Digital Ocean. Now to move on to the more uncharted territories for me. I may try and set it up with Nginx, Varnish, and Redis. I believe Nginx uses MariaDB, so I may have to go back through the video with setting up apache etc… and then install MariaDB instead of the traditional Mysql. That is all for another day though.

Digital Ocean Fresh Install with Sample Data, no varnish, no redis, no nginx (home page)
Pingdom: 75 Grade, 1.2MB, 1.95s, 200 requests
Webpagetest: As F on static content, 3.36s, TTFB .309s, 200 requests, 1.03MB

Varnish Install:

Install went flawlessly and the speed increase is very obvious when using the store.

DO Install After Successful Varnish Implementation (no redis, no nginx) DO 4GB,2CPU Plan Standard
Pingdom: 75 Grade, 1.2MB, 468ms, 200 requests
Webpagetest: As F on cache static, 3.556s, .219s TTFB, 200 requests, 1.03MB

I’m not certain on how/why webpage test is so much different, but the frontend definitely feels more snappy and quick. More along the lines of what pingdom shows. Are there any other speeds site anyone would suggest? I’ll throw one more in there, but don’t want to go too crazy with testing on too many sites as that’ll just take forever.

Thoughts at this point. Again, the DO setup has been flawless with no issues. Granted, I am basically following step by step guides. Even with the managed servers, I can follow magento documentation for something and it still seems that I can never get things to work smoothly the majority of the time. So far, the DO install is fantastic. We will see how the implementation of redis goes next. If that goes well then I will go back and start the build over on MariaDB/Nginx. Assuming all of that goes well then I will be left with a very tough choice on what to choose “Managed Cloud” or unmanaged DO. Again, security and having a little assistance to fall back on are very important to me. Stability and functionality are very important too. I will not compromise on the security aspect.

Well, I just can’t stay away from DO and magento. I’m back at it this evening for one last round of work before having to move to something else for the majority of the weekend.

Redis Install:

DO After varnish and redis install (no nginx) (homepage)
Pingdom: 75 Grade, 1.2MB, 513ms, 200 requests
Webpagetest: As fon on cache static, 3.52s, .208TTFB, 200 requests 1.03MB

I didn’t notice as much of a performance difference with the redis install, however this may be much more apparent with the server loaded from traffic. The install went flawlessy. Thank you for the great tutorial. I did not see if you had one on varnish. I should have looked first. I will when I go back through. I’m going to destroy this server and start over with nginx/mariadb. I also need to generate some better passwords for everything if the end game is possibly utilizing this setup for a production store.

I can safely say that the DO restore/snapshot feature works really well. I’m trying to install something with composer that I’ve been fighting with and the install, if gone wrong, seems to mess up my module list for M2. I don’t know how to resolve that problem, so I end up having to restore. It’s an arduous process to try and toubleshoot given this result. It has nothing to do with DO or the installation up to this point. It is my inability or the package’s inability to correctly setup some params, likely mine though.

One thing to note on backups in the magento backend: As of 2.3.0 it is deprecated. I think finding a better solution for this is needed. Next to security, this is the most important thing IMO.

The Audit tool found in the Google Chrome Inspect Element is pretty good. However, you should not try to get 100% for each item as it simply isn’t possible. You’ll just chase your own tale for months on end and not get any benefit out of it.

You’ll probably only notice if your daily traffic exceeds more than a few thousands unique sessions per day. In fact, most optimisation techniques and tools only shine if you’re store sees heavy traffic.

I’m a huge fan of this tool.

It’s not something I rely on. Before I push an update of any kind, I:

  1. Run a mysqldump as YYYY-MM-DD.sql
  2. Rsync the entire folder contents of /var/www/html/ to /var/www/month.backup/

This way, I know I can quickly rename the folder names to retrieve the backup files and quickly replace the database. Much quicker that a Server Restore. I may touch on this process in a video in the future. But would require a lot of preparation.

That is great! I am absolutely loving the DO setup. It could just be the “feeling of freedom”. I still feel overwhelmed though as there are so many things that aren’t setup and configured.

Control Panel?? Nexcess uses Sitworx
Additional Security Hardening

Your suggestions on backups are great.

My updates on the servers will probably be on hold until I can figure out this redis thing. I may start a new server on DO and build it up with Nginx, but that’s about all I have to do until I can resolve this redis thing. I’m stuck on the same error on both Cloudways and DO. It is clearly just a configuration of some sort. I have followed all available documentation from ScandiPWA and I am in their slack channel as well. I try not to lean too much on the slack channel as it is not really a place for “help” unless you’re developing something. I want to be respectful.

Nexcess vs Cloudways (Test 3)

Well, I’ve been progressing on the PWA install and while I’ve been doing so I’ve had install node.js which also comes with npm. The theme as to be “built”, so these are requirements.

Both Nexcess and Cloudways have this dependency, however cloudways is a bit outdated and nexcess is plenty up to date.

Here is just kind of an update of some of the information I’ve been taking notes on as I progress through this long arduous process of choosing a webhost. I am very close to getting the PWA functional on DO. I THINK I could replicate this on nexcess if they could fix their darn backup system.

Cloudways install
Debian 9.11
Out of the box default mode
406ms, 75 Grade, 190 requests, 930KB Pingdom (home page)
Sample data installed, .489s, 83 grade, 208 requests, 1.3MB (home page) Pingdom
Sample Data Installed, 3.2s, As across board, .358TTFB,
Redis Activated, SampleData - Pingdom, 532ms, 84 grade, 208 requests, 1.3MB (home page)
Redis Activated, Sample Data - Webpagetest, 3.05s, As, .380TTFB
Node.js 6.17.1
Npm 3.10.10
Yarn - not installed
PHP 7.1

Nexcess Install
CentOS 7
Production out of the box
1.07s, 77 grade, 190 requests, 815kb Pingdom (home page)
Sample Data Installed, 1.03s, 77 grade, 208 requests, 1.2MB Pingdom
Sample Data Installed, 3.7s, TTFB=C, .938TTFB,
Mail Round Cube
Node.js 10.10.0
Npm 6.4.1
Yarn 1.17.3
PHP 7.2

Looking at some of the new information regarding versions, it seems that nexcess is keeping up to date and cloudways is a bit behind. Node.js 6??? The latest node.js version with LTS is 12, so that’s a far cry off. This, I think, is perhaps a bit of an eye opener. IMO nexcess is staying more up to date and comes more setup right out of the box. I’ve ran in to a few things on cloudways where they simply say, “we have it that way, so you can set it up yourself”. A lot of people using these hosting services, IMO, want something that is ready to go and doesn’t require digging around to make sure things are secure and optimized for performance. What I can’t understand is why in the world nexcess doesn’t include varnish out of the box. Even magento says, “It is highly recommended to use varnish for production”.

I destroyed my server over at DO and built a new one with the stack that I think is ideal for magento from reading and seeing other setups.

DO - Nginx, MariaDB, M2 2.3.4 $20 plan
Mode: developer
Pingdom: 487ms, 77 grade, 950kb, 193 requests
Webpagetest: 3.249s, A’s across board, .276TTFB, 770KB

I got a bit frustrated installing this. It is as expected following different tutorials online, however the one thing that hung me up here was that I couldn’t figure a way to install M2 in var/www/html, it needed to be in another folder within html for the symlinks and nginx to like it. I ran in to some weird error with nginx not starting if m2 root was html. I know the default config is the html for nginx, however it I couldn’t get the configuration to work like that. I ended up creating another directory. example: var/www/html/M2

Once I did this it worked great. I know it was likely something i was doing or not doing that caused this, but something worth making mention of since it was really the only hangup I ran in to. I probably built the server setup 3 times, that last which I took many snapshots along the way to see where the issue was being created.

edit: I will be adding varnish and redis as well to this server. This is just as far as I’ve gotten with it over the last couple days. I have a functional frontend/backend and that was my milestone.

Got sample data installed on the nginx/mariadb setup.

DO - Nginx, MariaDB, M2 2.3.4 $20 plan
Mode: developer
Pingdom: 487ms, 77 grade, 950kb, 193 requests
Webpagetest: 3.249s, A’s across board, .276TTFB, 770KB

Sample Data Installed
Mode: devloper
Pingdom: 559ms, 77 grade, 1.3MB, 211 requests
Webpagetest: 3.7s, As, .265TTFB, 1.1MB

I ran in to some weird permission issues. I think that I may have buggered up setting the preinstallation permission/ownership. I have changed them now, however just doesn’t quite seem the same. I must also note that this install is now on M2.3.4

I think everything is down to Nexcess and running the server myself on DO. The reservation I have on nexcess right now is their TTFB is awful compared to DO or Cloudways. I just ran the test again and it was 1.0s TTFB as compared to .2-.3sTTFB on cloudways and DO setups. It isn’t about price even though I could get WAY more for the money at DO. The reservation I have about cloudways is the fact that it seems a lot of their software is not really updated from what I can see. This lack of attention, IMO, must also spill over to other aspects of their setup and that is a large concern. This is especially so when you can’t update certain things yourself. Nexcess seems like a more streamlined/secure setup that is running up to date software/packages from the time you start. This fits more in to the model of a managed server IMO.

DO on the other hand is great if I can get something going that I feel comfortable with as far as security goes. I’ve been researching until my eyes go crossed. The thing is, I never will be a software security professional so that’s what leads me to believe I should leave it to those that know what they’re doing, Nexcess. I have never had a security issue over there. On the other hand, it would be amazing to have the performance and freedom that an unmanaged solution at DO gives you. Those are just my current thoughts on the situation. As usual, I will update this as I do more work.

What are the recommendations for mail server, cpanel management (or similar), and SFTP installation packages for Ubuntu?

Web Hosts will have their “in-house” repositories setup, which is why your typical “sudo apt-get update” command can have varying results. If you ever need the latest version of something you should refer to the developers site and following their instructions on how to add a dedicated repository or build the package from scratch. Again, out of scope for this forum.

I hate Varnish with a passion. The reverse proxy is an incredibly annoying workaround just to make it work with SSL. Plus, I don’t like how Varnish is perceived as a “set and forget” solution for caching. You literally have to micro-managed and “hole-punch” part of your Frontend so that:

  1. It full caches what it needs to
  2. It doesn’t cache things like Prices and Basket contents

You see this now on some Magento stores where you’ll visit a site and be like “I don’t remember adding anything to my basket?”. And in actual fact you’re seeing the Basket contents for someone else that happened to get cached.

Right now, I’m sticking with a LAMP stack unless my site traffic becomes exponential. But that’s my personal preference based on my experiences, not advice.

  • I haven’t done a video on setting up SMTP on a server yet, as this is something I’ve never needed to do. But it’s on my list of things to research and do.
  • Just use SFTP (Port 22) for File Transferring. Don’t bother setting up FTP (Port 20) as it’s less secure. Plus, SFTP just works out the box without any configuration.
  • I’ll never install any “bloatware” like Control Panels. They just complicate things.
  • Security Hardening other than what I’ve covered in the past is kind of out of my scope in this forum as you’re going into territory at this point.
  • SSL/TLS is kind of covered here (How to setup Let’s Encrypt Free SSL Certificate with Magento 2), but again any Apache/Nginx tweaking you should refer to the link above - Plus any best practices on the latest TLS versions vs browser compatibility.

Thank you very much for the replies. As always, your input is highly valued. Cloudways and Nexcess refuse you any kind of sudo power, so I don’t think it’s possible to update/manage packages unless they do it.

I’ll certainly take the varnish concern into consideration as I didn’t know of the problem you’ve talked about.

I’ll certainly be looking in to the Let’s Encrypt link you have there.