Nexcess vs Cloudways? Which Magento 2 host?

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:
Magento 2 Google reCaptcha - Invisible reCAPTCHA for Magento 2 – Mageplaza

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:
How to Change a Default Base Magento 2 Admin URL | Get Base Admin URL | Magento Administration | Store Url Not Working

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:
How to Change the Web Root of an Application | Cloudways Help Center - 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:
magento2 - Setting the webroot to the pub/ - Magento Stack Exchange

4- To restrict application to use a higher TLS version. You can follow this guide:
How to Update the TLS Version | Cloudways Help Center

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.

2 Likes

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: https://www.plumrocket.com/blog/2019/07/how-to-configure-magento-2-varnish-in-a-few-clicks/

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: Redirecting… 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.

Email
FTP
Control Panel?? Nexcess uses Sitworx
Additional Security Hardening
SSL/TLS

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, webpagestest.org
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, webpagetest.org
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 https://unix.stackexchange.com/ 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.

Nexcess vs Cloudways (Test 5)

Some additional testing with the porto theme installed.

All tested on the category sample page for Training–>Video Download

Cloudways: varnish, redis not active
Mode: Developer with Porto theme and sample data
Pingdom: 782ms, 80 grade, 1.3MB, 255 requests
Webpagetest: 3.17s, As/b compression, .385TTFB, 1MB 251 requests

Nexcess: redis, no varnish
Mode: Developer with Porto Theme and Sample Data
Pingdom: 73grade, 1.24s, 1.2mb, 255 requests
Webpagetest: As bcompress image, 3.42s, .618TTFB, 251 requests, 1MB

Do Direct installation, no varnish, no redis
Mode: Developer
Pingdom: 656ms, 73 grade, 1.4MB, 259 requests (category page)
Webpage test: A’s b on compress image, 3.864s, .242TTFB, 1MB, 254 requests

All sites were tested on the same test locations and at the same time of day. I tested a couple times each and they stayed consistent. It’s interesting to see the TTFB on DO win by a decent margin, however the overall load time was more. I would imagine that is probably comes to some optimization settings or possibly caching since both nexcess and cloudways either have redis or varnish functional. I have an issue with the porto theme on all the installs and they are looking at the problem. So far they are responsive to this, however I did just buy the theme. Their install and patch system is a bit wonky IMO, but I’m also not in to the development arena, so perhaps what they are doing is standard. Regardless, something isn’t quite right. I get the same issues on 2.3.3 and 2.3.4.

Nexcess is still working on the backup issue. I was hoping they would have had it fixed prior to the weekend so I could do some work. I contacted them in regards to the TTFB on their site as it typically seemed to be around 1s on the stock theme and sample data. They said it was due to DB queries from everyone that was hitting the DB on that specific cloud configuration. IMO, that seems a bit too many people pulling from a single DB instance. He said he would configure a redis setting that should help, however we are holding off on that until they get the backups resolved as I would inevitably just revert the change. Updates to come as I make more progress.

Just a thought, but you might get a more “realistic” values by switching to Production Mode. Only cause Developer Mode doesn’t take advantage of many caching tools. Therefore, you might get wildly different results.

Also, the Frontend and Backend work much differently in that Frontend relies on pulling from a pre-compiled cache and the backend actually processes a lot of real time requests and data - Especially, when it comes to product management.

Thanks for the heads up. I’ll switch over to production and rerun the latest tests once smartwave/porto gets back to me with the fix. They fixed one site, however I’m still waiting for them to tell me what they adjusted on their theme files to fix the error so I can replicate it on the other two M2 installs.

All of the below are the same configuration as the previous test, however production mode has been enabled on each instance. It is the same category page.

DO
Pingdom: 73 grade, 1.4MB, 654ms, 260 requests
Webpagetest: As / b image compression, 4.04s, TTFB .238s, 256 requests 1MB

Cloudways
Pingdom: 80 Grade, 677ms, 1.3MB, 255 requests
Webpagetest: As / b image comression, 3.13s, .367s TTFB, 251 requests, 1MB

Nexcess
Pingdom: 73 grade, 1.29s, 255 requests, 1.2MB
Webpagetest: F-TTFB, b compress image, As rest, 3.85s, .941TTFB, 251 requests, 1MB

It’s interesting to see the difference. I would expect that DO under performance on total load time may be due to a lack of redis/varnish among other possible speed/compression tweaks. The TTFB winds hands down, but the overall speed of the DO setup needs improved.

My Conclusion

Well… After looking at just about every single hosting option out there and done as many tests as I possibly can come up with, this is my conclusion.

I think I will be moving to cloudways. They are basically a properly setup direct DO installation with customer support, and many many features already setup. This includes a staging environment as well. They have allowed me some flexibility on the server and will update packaged on the server upon request. I will run a WAF I think just to be extra safe. This is one step closer to an unmanaged server as you’re allowed more control and flexibility than at nexcess. I do not think cloudways is perfect. I still believe they have some permission issues on the application user level.

Nexcess TTFB is way too slow and they said enabling redis would fix this. It was exactly the same after they made their adjustments. They blamed it on too many people making DB queries on a given server. Nexcess’ backup features simply don’t work as one would want. You can’t restore them from the CP nor portal. They confirmed this and suggested I run everything manually, download, restore, etc…

I looked at other hosting companies that have good features and pricing for VPS managed servers with root access, however they don’t specialize at all in magento. I think that is important to have with a host so that they can know and be familiar with the M2 system should an issue arise that is related. I can’t tell you how many 8 hours days I have had in this process with setting things up, reading, researching, etc… I think from a perspective of managing an emcommerce store the following would hold true for freedom and experience needed on a specific host.

SaaS < Nexcess < Cloudways < Managed VPS w/root < Unmanaged Server (Direct DO Install)

Perhaps on my next adventure for this store it will be on an unmanaged server, however I hope that is at least 5-8 years because I do not enjoy migrating platforms one bit. There is only one proper way to do it. That is it has to be done EXACTLY RIGHT.

I hope this information is of some help to those out there in a similar situation. What fits this project and my needs may be different. Companies and setups change, so take everything in this post with a grain of salt. If my opinion changes then I will update this.

1 Like

@live4soccer7, you’ve done an incredible job here. I just want to say a huge thank you for sharing your journey along with what you learned along the way. In the near future, I’ll tidy some of this up a bit and lock it.

Thank you

Feel free to do as you please. In these types of scenarios where a bunch of research and experience w/something is needed I like to use forums. I have my own local notes as well, however putting it up online in a forum helps others, keeps me sane, and also provides an opportunity for positive criticism. I found your forum to be the best out there, honestly. It isn’t the largest, but you’re active and helping people. Your videos are fantastic and I refer to them and your documentation a lot.

I hope that many more discover your site because it deserves to be discovered.

1 Like