One year ago I decided to invest on Gridpane, and one year after, I want to use this post to evaluate my experience and also to share my notes with any other user that might find them useful.
But we must start a little before that year, almost 2 years ago, in February 2019 I discover Gridpane on a blog post somewhere and decided to give it a test for their free account. At the end of 2018 Serverpilot decided to change their pricing model so I was just testing all the alternatives around, as this is part of what we do on WPHercules, to make sure we have the best of the best for our clients.
I remember my first impression. It was not ready for production. The idea was good but there were so many missing standard features and the price was high so I didn´t jump into the paid plans at the time. But I liked (a lot) how Patrick was. He was direct (maybe too much for some people, but I like that, I am the same), he was sincere and he explained everything that was going on behind the scenes, and also what he had in mind for the future of the project.
Some more later, they launched their huge Black Friday offer, and I did another test. It was still not ready for production, but I saw potential on it. So I jump into it.
Some more months later, more or less around this date last year, they started to launch updates into the platform, and the basic functionality was improving slowly but firmly.
From January until march, Covid included, I started to see a good fundation, so I also started to plan the movement of some clients from Serverpilot into Gridpane.
Fast forward until now, I have been testing Gridpane for more than one year and using it for clients and productions systems since March-April this year.
I want to share here some of the things I learned, the things I like more, the things I like less, and some notes and tips for other users that are using the platform, in case it helps them to get the best from Gridpane.
So this post will be mainly about Gridpane, and sometimes I will comparte some functionality to Runcloud and Serverpilot, as they are the ones I have been testing alongside with them. I still use all of them and I will keep using them for different projects.
Overall view:
Gridpane is now solid and it is ready for production. It should be considered a solid competitor with any other similar tool or business. They offer a premium platform and they have some features that no other one have.
Their CEO, Patrick, is someone you can trust, and that is something not so many SaaS companies can say. They are fully transparent. You can also reach him anytime and he will make time to talk to you, even if he does not know you at all. They do not have investors, so that also allow them to make their own decisitions base on what they want, not on third party investors requeriments.
For big projects and when you need a premium solution, it is a great package, probable the best you can find on this format.
What I like more
They are innovating, they are pushing their own limits and creating something big. As I said above, they offer some nice tools out of the box. Some of them are not present on any other competitor, and that is because, building them is a huge investment, on time and resources. They keep adding new stuff and new features to the mix. Other add new features and funcionalities… how to say it, just after Gridpane launchs them… you know what I mean. But that is how the Saas world works.
What I like less
It is related to the main point above. They want to push their limits, they want to keep growing and to update often. That also generate some issues and bugs. The platform still have some issues, some of them (imho) are essential ones. All thouse changes and updates that are deployed, they do this without notification in advance, so this affect their clients like me and their procedures.
They want to run, and sometimes I feel they are running before walking on some areas. Their platform is great for some configurations, but it fails hard on others. They are still missing some key functionalities, even if they have other functionality that no other competitor is using.
The main thing I miss with Gridpane is just that: Stability.
I have found that, sometimes, the new changes to the platform affect my servers and my scripts I built on top of them. Sometimes their changes generate bugs or uncover bugs that were fixed in the past. Sometimes you just need to do things in other ways because that functionality is no longer there. And sometimes their autoupdates at 2am in the morning will break a backup or even a client working late on the website.
But this is how it is, you cannot have development without bugs, and innovation without issues. I just would like them to have more real life internal testing before any deployment and to have a “stable” branch or version so we can avoid changes on machines of clients that are more critical.
Note to myself: As a client, there is not so much to say, this type of issues are what you get when you use a Saas, you do not control the development and the platform and you need to trust the team developing that for you. It saves you a lot of money that they are investing so you, the client can have all that. I sometimes need to remember that, as i have failed to do in the past. This whole post and this specific paragraph is here on my personal blog as a reminder to myself. Nobody forces me or anyone to use them, so if I do not understand how a SaaS work, it is me to blame, never them.
Notes and tips
Here are some specific tips and notes about gridpane. I hope they can help others to get the best from Gridpane and maybe to solve some issues they are having.
Everything on this list has been already reported to Gridpane support in the past. Some things may been fixed already (I tested for a while, reported and have not seen them on the logs, but have not tested them again). Other notes have been planned to fix and some other maybe will never be fixed. So far, at the moment of this writing (3rd of December 2020) these are my notes:
Mysql vs Percona
During my tests of MYSQL, I found some bugs and differences, and it seems to me that Gridpane test more frecuently their Percona DB that the MYSQL builds, so it is recommended to use Percona when building a site with Gridpane.
Some of the bugs were related to change some MySQL configuration. Also this guide generate an error when you use MySQL and it works when using Percona. Nothing big, but makes me wonder and then I decided to use Percona by default.
Nginx Version not updated
Nginx version has not been updated for a long time. The servers are still packing Nginx version nginx/1.16.1 from 13 Aug 2019. The latest one is 1.19.5 from 24 Nov 2020
That means we are missing some nice improvements and fixes. I had found one of the bugs myself on one of my installations. Nginx version is stable, but more than one year is too much.
WordPress recommends 1.18 or 1.19 in the hosting handbook.
You cannot use custom SSL on Gridpane
With LetsEncrypt that is no longer a big issue, and they have fixed the problems they had in the past generating the certificates, but it is always nice to have that option.
Their new installs had Object Redis activated by default
I was told that was never going to be changed and I saw people still suffering this. I have not tested it since I reported it. It generated problems when doing migrations into blank installations if Redis is not flushed before. The issue is: you create a blank new site, then you remove the database, the content and migrate your site. Redis object cache is still there showing the old blank site and confusing you. Just remember to clear the cache completely and the redis object cache too (login into the server as root and run “redis-cli flushall” and you are good to go).
Clear Redis Object Cache
Their server clear cache CLI command (gp fix cache) does not clear the Redis Object database for the whole server. This was to prevent issues when having more than one site on the same server. In my case it generated other issues. I have not tested this anymore as all my scripts now include a redis flushall command.
Cache Off cannot be overrided
When you deactivate any of their server page cache options (fastCGI and Redis Page Cache), the constant “WP_CACHE” is set to false on wp-config. If you decide to install a cache plugin, it is important to change this manually on their default wp-config file. Any changes you do in the gui related to the Cache, will change this again, so make sure you check it often. You cannot use their recommended user-configs.php file becasue it is a constant, so it cannot be modified after it has been set.
Backup system
It should be considered an extra and in their current status (for both v1 and v2), so another external backup system should be used. This is what they recommend too. (I removed some comments on this section to short a little bit the already long post)
Hourly backups by default
Most websites do not need hourly backups and even with incremental backups, the database backup is always a full backup and it can take a lot of resources from your server. It is easy to change on the v2 but I think the default on GP should not be hourly, as most people will trust Gridpane defaults. Jordan shared a script on the facebook group so you can check the status of the backups on your server.
Suspend sites not 503
Their suspend sites system is a clever and great idea, but I think it is not completed. It does not return an error 503 or even a 307, but a 200 which should not be on a temporary maintenance page. I am sure this will be improved soon.
Redis Cache Bug
On the Redis Cache include file for sites (located on /etc/nginx/common/{site.url}-wp-redis.conf), there is an include for this file: ” include /etc/nginx/extra.d/*-skip-cache-context.conf;” and it should read “include /etc/nginx/extra.d/*-skip-redis-cache-context.conf;” so it matches the KB and it is consistent with the fastCgi skip filename.
Nginx FastCGI
Nginx FastCGI microcache has 7d cache expiration for inactive content. This could affect some configurations but it is difficult to modify, as gridpane worker will restore the changes.
FastCGI cache use /run/ as cache storage.
This makes it limited in space to the run folder. It cannot be changed without editing the server configs.
Redis memory notification
It is a little anoying as it is suppose to be used for the cache to work best, so you expect it to be full, but then it notifies you every X minutes when is working as it should.
You are suppose to use root for everything
Well, you can decide not to use root, but most commands and setup are defined on their stack to be managed using the root user. Not a root user, but the user named “root”. You will read on so many places that this is not a good idea (sometimes is not that clear). It is not that bad if you know what you are doing, but I would prefer that some other configurations allow us to use a sudo user instead. As an example, to connect to a MYSQL database with an external tool using SSH, you are told to use root and the only way to connect to the database with another user is to modify their sshd_config, and then we have this issue:
Changes to users override your files.
Any changes you make into the sshd_config file to an user (for example to allow port forwarding to use an external MySQL tool), will be reverted if you change any data from that user on the gridpane gui (like changing their password).
Phpmyadmin
It is installed by default on all servers. I prefer my servers not to have anything extra installed on them. It is easy to remove though.
Performance Issues
This is my last discover from yesterday (2nd of december 2020), which worried me a little more and I will need to maybe write another blog post just about it.
Gridpane stack is really powerful and allow you to create amazing websites that scale really well. The problem is that all these configurations and options come with a cost.
I have talked about the backups and phpmyadmin above, but this issue I am going to talk now is more complicated to deactivate or remove, because it is part of the core of gridpane: the gpworker and their monit services.
Monit runs every minute and it is a nice feature that alerts you if something is wrong. The problem is that it makes too many checks and some of them are related to the disks.
On top of that we have the gpworker.
The gpworker runs every 15 minutes (:00,:15,:30 and :45) and it does a series of checks and syncs all around the server. At :00 it runs an special gpworker that executes also a sync and other stuff (too long to write here) that takes a lot of resources to run.
For big machines with multiple CPUs, this is not a problem, you may see spikes on your processor, but it won´t affect that much the performance of the site (I would prefer not to have it if you ask me).
For small machines with 1 or 2 CPUs, mainly for 1 CPUs, this is a lot of resources to lose. And it makes no sense to use a bigger server just because the stack requires it. Also, most websites that are on those small machines do not need all that extra that GP offers.
This graph is a 2GB RAM 1 CPU server with 2 sites on a gridpane stack monitoring the root user. It has been created using netdata. You can see the spikes on the server.
The red line is when I deactivate the MOnit services related to the hard disk and backups checks. The blue line is with monit disabled completely.
The big spikes are the gpworker every 15 minutes.
This is just one graph but I have done extra tests and I can confirm this happening with any server with GP stack, even without any websites installed on it, and with no traffic. I am writing another blog post with all the information with my tests on this and how to replicate it. I will publish it here too.
The bad news are that currently there is no way to stop this. This is part of GP stack.
So at the moment, if your plan is to use small servers with 1CPU, Gridpane is not the best solution (I am sure they will fix it eventually).
If you have a lot of traffic on a website, or if your plan is to use a big server for multiples sites, gridpane is a fantastic solution, just make sure to tweak it a little bit and you will be good to go.
Conclusion:
Gridpane has amazing features you won´t find on any other provider.
Gridpane keeps adding more and more amazing stuff, which is great, but this also means their stack is less stable than others.
If you need a big server to take huge ammount of traffic, Gridpane will deliver a fantastic solution.
Make sure you do extra backups and disable hourly backups (unless you need them for other reasons).
Best solution out of the box is Percona, Nginx server and Redis Page Cache ON.
For small servers (1CPU) Gridpane stack will take a lot of resources and it won´t perform as well as other solutions.
Do not trust anything you read online (even this post). Test yourself, test often and please let me know if something here is wrong. I would love to hear your comments about it on @Twitter.
