Web hosting has been getting better and cheaper over the years. More CPU, RAM, disk space, and bandwidth at more or less the same prices. Those who don’t use their hosting instances to full capacity can add additional domains to host. Control panels like cPanel remove the burden of learning command line configuration, allowing users to quickly deploy additional domains as they see fit. This is a sound strategy for personal projects, test environments and even low-traffic static websites. But for our clients whom we host and manage, it is a strategy that puts too much emphasis on cost savings. We’ve learnt that putting all our sites in one box is a poor choice. Here’s why:
We typically develop websites that run on the same stack like LAMP (Linux, Apache, MySQL and PHP) or LEMP (nginx instead of Apache). This simplification encourages hosting multiple sites. However, we’ve seen and considered how configuration needs change over time for individual websites. One site may require a config change, a new library or even a change to the solution stack. Minor changes may be trivial, but major changes could require additional planning and testing.
Fighting for resources
At normal loads, all websites may run fine without hiccups. Now consider what happens when one site sees a surge in traffic? It’s going to eat up more than it’s fair share and cause the other websites to slow to crawl even if they’re barely seeing any activity themselves. Worse if when all connections are full and the other sites are unreachable. Bandwidth and processing are not the only shared resources, disk space can quickly be filled too.
One bad egg can ruin the batch
Most multi-website setups typically share a single IP address as dedicated IP addresses are an additional cost. Consider this scenario, one of the websites is blacklisted (whether justified or accidental) for sending spam. The email is traced back to a shared IP address. That IP address is subsequently blocked. The consequence is that email sent from the other websites sharing that IP are automatically blocked as well. The same can apply to content if the IP address is blocked by a service provider.
When problems do occur, each additional website hosted only adds additional complexity to the recovery process. Pinpointing the source across an instance with multiple websites can be tricky. Making system configuration changes or applying a patch may require taking the other sites into consideration. Should a catastrophic failure occur, it’s not just one website that needs to be restored. A single website offline is already a headache when the client calls.
There are many reasons why hosting multiple websites on a single web host instance makes perfect sense. Small projects and test environments fit this bill nicely. But when you’re responsible for the hosting and management of various websites, an issue on one website is further compounded by each additional website on that instance. Running separate instances allows us to quickly isolate, troubleshoot and even restore if something wrong happens.