Drupal Shared Hosting: Deciding if shared hosting is right for your Drupal site

By shane
Mon, 2014-12-01 12:36

Share with Others

Over the summer I was able to attend three different Drupal Camps (Drupal Corn Camp, Twin Cities Drupal Camp, and Drupal Camp Atlanta). While talking to other attendees or during my sessions, I made it a point to ask about hosting providers and what other Drupal developers, designers, and site builders were using.

These are rough numbers, however I would guess that overall about 50% of the people I asked mentioned that they were using some type of Shared Hosting service. This was a number that surprised me. I have used a number of different shared hosting services in the past to host Drupal websites, however I usually use other hosting solutions for most of my Drupal websites.

I wanted to use this as an opportunity to discuss Drupal shared hosting in more detail. To go over some of the situations in which it works, and some of the limitations that you will likely run into. I also plan on discussing figuring out how to install Drush on shared hosting, as well as how to use Git on shared hosting.

When to use Drupal shared hosting

There are two primary reasons to use shared hosting. The first is cost, and the second is for ease of setup. Setting up a Drupal 7 website on shared hosting (especially those using CPanel) is a straightforward and easy process (I have some videos on setting up a Drupal site on Bluehost). It is something that someone with basic Drupal knowledge can do in 10 to 15 minutes. A few years ago, getting a live Drupal website up and running in 10 to 15 minutes was a pretty awesome reason to use it. Now however, there are some other hosting options that are more Drupal specific that are even easier and quicker to launch a Drupal site than shared hosting.

This brings us to the number one reason most Drupal developers choose shared hosting... cost. Shared hosting is the cheapest alternative for hosting a live Drupal website. You can find shared hosting providers to host your Drupal website for less than $5 per month. With that price tag however, you do run into some limitations.

Limitations of shared hosting

In the following few paragraphs I am going to go over some limitations that you may run into when hosting a Drupal website using shared hosting providers. These are not necessarily meant to deter you from using shared hosting, however they are things you need to consider when deciding where to host your Drupal website. There are many people that will try to convince you to always use one way to host your Drupal website, I have found depending on the project, the budget, and the requirements, different situations may call for different hosting options.

Drupal Shared Hosting Performance

The number one complaint I hear about shared hosting is about the performance. When considering the performance, you have to consider why you may run into problems. There may be many other websites running on a single instance of your shared hosting server. This means spikes in traffic on other websites has the possibility to slow down your website. Shared hosting providers put in limitations to try to keep this from happening, so this also means if your Drupal website receives a lot of traffic, there is a good chance that your website will not have the necessary resources to keep up with the load.

If you are expecting spikes in traffic or expecting even a moderate amount of traffic on your Drupal website, shared hosting might not be the best option.

Drupal Shared Hosting Memory Limits

If you have ever installed a modest amount of modules on your Drupal website, you may have ran into PHP memory issues. These issues are typically resolved by either uninstalling modules or increasing your PHP memory limit. The later of the two is often difficult to do on shared hosting providers. I can recall many times trying to increase the PHP memory limit on various shared hosting providers and it never turned out to be an easy process. Typically you can do it, however the process is often convoluted, the changes do not immediately take effect, and you are still restricted in the amount of PHP memory you can allocate to your Drupal website.

If you need to install a significant amount of Drupal modules, shared hosting might not be the best option.

Drupal Shared Hosting Reliability

The reliability of shared hosting is another concern. I have had dozens of questions asking if this or that shared hosting provider was more reliable than this or that other shared hosting provider. I have heard it so many times that I have come to the conclusion that you will have some reliability issues when dealing with shared hosting. It may not happen often, and it may be a long time before you have an issue, but if you use a provider long enough, you will likely run into some type of downtime issue. Certain shared hosting providers are probably more reliable than others. I don't know enough about the various providers to be able to say with certainty which I think to be more reliable. I just know that typically you are going to have more reliability issues with a shared hosting provider than with other types of hosting options.

If near perfect uptime is absolutely critical to your Drupal website, shared hosting might not be the best option.

More difficult to upgrade Drupal

Shared hosting with a Drupal website is typically more cumbersome to upgrade. I am not going to spend too much time on this one as there are more tools available to make this process easier. However, just keep in mind and do some research to see how easy the upgrade process will be for your Drupal website on your shared hosting provider of choice.

Shared hosting is a viable option for Drupal

Despite all those limitations, I still think shared hosting has a place with Drupal websites. In fact, I think shared hosting has a place for more Drupal websites than most developers will probably care to admit. Think of it this way, for every large scale, high traffic Drupal website live on the Internet, there are a lot more, small scale, low traffic Drupal websites that still need hosting. If you are a plumbing company or painting company and have created a simple brochure business website and are only expecting a few hundred people a month to come to your site, shared hosting will probably work great. This is especially true if you don't want to spend $30+ a month just to keep a site up and running. You probably don't mind the occasional hiccup in reliability or slight performance problem.

The only thing to keep in mind is that although you are saving money, you are more than likely losing time and losing peace of mind. The entire hosting game is a fine balance of budget, time, performance, and peace of mind. Typically budget, performance, and peace of mind are directly related. The more you can spend on your hosting, the better performance and the more peace of mind you will get. Budget and time are usually inversely related. The more you spend the less time will likely be required, the less you have to spend, the more time you will likely have to spend with setup, issues, and the like.

Just evaluate your options, and after you do, take a look at my Hosting options blog post where I go over a few common Drupal website hosting providers.

Other Drupal Shared Hosting Considerations

There are other considerations for using shared hosting with Drupal. If you are familiar with my 5 Secrets to Becoming a Drupal Ninja ebook, you will know that I discuss building and streamlining a Drupal development process. This is often more difficult to do with shared hosting. If you want to follow some other Drupal best practices, you will need to figure out things such as how to install Drush on shared hosting and how to use Git with shared hosting providers. In the near future I will be posting some follow up articles/videos on these topics to help those of you that are either going through the hosting decision making process, or are already using shared hosting for your Drupal sites.


A very helpful post. And I'd agree with your broad conclusion that plenty of Drupal sites have outgrown shared hosting, while others will be fine with it. (The same could, of course, be said of non-Drupal sites - they're just often less hungry for things like PHP memory).

What struck me though was how many of the potential problems you highlight are equally true of a more dedicated environment. (I'm thinking mainly VPS here, which will have limited resources, will share the parent node with other containers, and so on. Yes, someone could go for an actual dedicated server, but that will either be a budget model with no RAID etc, or it will cost an arm and a leg).

So, let's take the 3 areas you mentioned:

>> if your Drupal website receives a lot of traffic, there is a good chance that your website will not have the necessary resources to keep up with the load

The resources on a VPS / Dedi are also finite. Indeed, quite a bit of the RAM / CPU goes to running the kernel and your own private instance of MySQL, so you often don't have loads of RAM for your actual sites.

>> I can recall many times trying to increase the PHP memory limit on various shared hosting providers and it never turned out to be an easy process. Typically you can do it, however the process is often convoluted, the changes do not immediately take effect, and you are still restricted in the amount of PHP memory you can allocate to your Drupal website

You can do it on a dedicated server - but you have to know where to go to change such settings. It all depends on whether the site owner is also happy tuning their LAMP stack. By contrast, any shared host who runs Cloud Linux will have control panel access to settings like these - tools that are often beyond the budget or need of a one-site dedicated box.

>> It may not happen often, and it may be a long time before you have an issue, but if you use a provider long enough, you will likely run into some type of downtime issue

Your own server can go down too. In fact, if it happens at 2am, who's watching it to see the problem happen and nurse it back to life. A good hosting provider will have round-the-clock staff who will monitor such things. Many people who move from shared hosting to a VPS often find their uptime goes down, and that they have to work a whole lot harder to keep everything running.

So, yes: Find the right hosting environment for your own site. But the arguments against Shared Hosting aren't always as persuasive as they're made out.

IMO, a Dedicated Server or VPS is more about the ability to control the hosting environment yourself, installing custom software and so on. Then, when resource needs get much larger, a high-end VPS or Dedi also has benefits in how well they scale - but you need to be at the high-end to start to reap those benefits. So it often comes down to budget.

None of the shared hosts that I've used provide an opcode cache. I suspect that might be because of memory constraints and the potential extra support hassles of running something like APC. I wonder if things will change now that Zend OPcache is built-in to PHP. That should at least remove any support issues.

I think an opcode cache is going to be pretty much essential for Drupal 8 to get reasonable performance. You really don't want that much code being compiled on every request.

Brilliant. You're exactly right - that is one thing that I too have not found a shared provider that would enable. Now this blog post is much sharper.

Some providers give you the ability to enable the PHP extensions necessary for it on a per-account basis, but the ability to fine-tune beyond that is absent. Also, for security between accounts, su_php is still the go-to PHP handler for most shared hosts. That doesn't perform badly in itself, but the main problem with creating a new process for each request is that you can't cache the opcode layer.

SO - I'm not going to try to sound too self-promoting here, but in fact there can be a world of shared hosting that works pretty well for Drupal. There are other hosting providers doing the same, but our shared plans all include Drush, git, ssh logins to the server, APC, and a one-click installer that just works AND lets you upgrade easily. We also have fairly fat PHP memory limitations, and on our higher-end plans let you set your PHP memory limit (though I have to admit that if you then start chewing up the server like crazy we will probably suggest moving to a VPS). Thing is, for a lot of our clients being able to have a reasonably fat shared implementation works better for them than a really constrained VPS that will cost more. Yes, there's some art to being sure we don't over-subscribe a particular server, and there's ALWAYS something to be said for having your very own resources. But shared hosting really CAN work - but a plan that actually works for people is going to cost more than the normal $4/month commodity hosting plan.

I agree that shared hosting has its place. I've created and still support a few small Drupal sites as a part time moonlighting job. It might sound weird but, even though I'm quite capable of setting up and managing a VPS, the reason I chose shared hosting for sites at the low end of the price market is if they want POP or IMAP mailboxes. I have a somewhat technically aware client who already had a low cost shared hosting account with cPanel and a few mailboxes. He wanted to keep those features. I would much prefer to run my own VPS but I absolutely did not want to deal with mailboxes. Mailboxes are painful when you consider passwords, disk space with IMAP or when people "leave messages on server" with POP, spam filtering and support issues when "Outlook Express is messed up". Then it's another whole world of pain if you ever want to move to a different host or server.

I signed up for a low cost reseller account at BlueHost and put sites there, each with its own account under me as a reseller. That worked pretty good. They allow SSH so I was able to use GIT to push updates to the server and the client had all the features he wanted. It was good to simply let BlueHost handle it all.

Since then I convinced that client to simply forward to Gmail (much better spam filtering). My other clients were doing that anyway. I've had some frustrations with BlueHost so recently I've moved everything to a $10 VPS at Linode which runs superbly well with a recent version PHP with the built-in OPcode cache. I'm much happier now.

Mail forwarding from a VPS is easy enough and doesn't involved the pain of mailboxes. You still need to know what you're doing to do it right with SPF, DKIM, reverse DNS etc.

I realize of course that web hosting and mail can be at different places but ... I was dealing with clients and friends where every dollar counts.

Wow, thanks for the long and detailed comment about your experience. I think you opened up an entirely new discussion about how email mailboxes and hosting are related. I have set up a few VPS's and agree that Linode provides a pretty great service. However, many people do not have the skills necessary to get this set up on their own. Having a shared hosting provider with POP or IMAP mailboxes is probably another reason many of these people go with a shared hosting provider. They provide a lot of the features they need (even if they do sometimes come with a few headaches or less reliability).

Post new comment