As we move into 2024 we are continuing to evolve and ensure we provide the best level of service we can. With that being said we are making several updates to our current line of services and solutions to unify and simplify our platform.
Our hardware stack will be 100% dedicated and isolated. Let’s take a quick look at the evolution of our hardware stack.
Version 1.0
We started with a shared LAMP stack capable of hosting up to 50 sites per server. Each site had its own directory, its own PHP FPM pool, and its own user account but shared the server’s memory, CPU, and hard drive space. This stack worked well, It was a tried and true stack that most web hosting companies have used since the existence of web hosting, in fact, it’s still the most popular hosting stack you will find in 95% of all hosting platforms. This worked well for us for most low-traffic, low-resource websites. At this point, we didn’t have any true limits on the number of sites we allowed each client to host with us, we also managed to keep client hosting costs low because of this shared environment it didn’t cost us a bunch to host several of these clusters we called “pods”.
Version 2.0
As we grew and began to onboard more clients it was clear to us that having shared memory, storage, and CPU resources wasn’t going to provide the level of performance we wanted to provide so we moved away from large shared LAMP stacks to smaller individual LAMP stacks per client. This was great, we built out a smaller 1-2CPU, 1-4GB RAM servers that for most clients provided more than enough resources for their needs. This provided complete client isolation again we didn’t have any true limits on the number of sites you could host per subscription. You were only limited by the amount of free resources your server had, sometimes that was 1 large site on a server and sometimes that was 100 small sites on a server.
Version 3.0
We saw a huge spike in new sites, and redeveloped sites being created with Elementor. It is without question the most user-friendly design and development tool for making WordPress sites. The issue with Elementor is that it is very resource-intensive. The smaller LAMP stacks just couldn’t keep up anymore. Servers that could hold 10-20 sites in the past struggled to hold 3-4 Elementor sites. We went back to the drawing board and went with a containerized solution called LXD. Instead of thousands of small servers per client we created several large servers and and created what’s known as LXD host servers. On each server, we hosted up to 50 LXD containers. Unlike V1, these containers were 100% isolated, each container hosted 1 site and had its own dedicated OS, software packages, CPU, RAM, and storage space based on the client’s plan with the ability to burst above the set limits if needed. Along with this new containerized solution, we also dropped the Apache2 website server in favor of Nginx with native caching. Speeds were amazing, load times were low, and we didn’t need to past any additional cost to clients. While most things were great there was still one thing that kept us up at night. For the containers to receive traffic each cluster utilized what is known as a reverse proxy, this was a single point of failure for each cluster. If it fails any site on that cluster becomes unreachable. Due to the design of LXD, you are only allowed one reverse proxy per cluster. We have had 6 instances of reverse proxies failing, each requiring us to failover to our DR environment, each costing thousands of dollars and hours of downtime.
Version 4.0
Quality over cost. It’s now time to take a little bit from V1-V3 to make V4 as performant, reliable, and secure as possible. We have moved to a 1 site per server approach. Each server uses our optimized and tuned LEMP stack, with a minimum of 2CPU, and 4GB of RAM for our entry plan. We have tested this new setup with several beta clients over the past 6 months and have seen a 200% increase in performance across the board.