Drupal Multisite - When, How and Why. The Ultimate Guide to Managing Multiple Drupal Websites

Drupal can be configured to serve multiple websites from one codebase. Such a Drupal installation is called a multisite. The ability to use one Drupal to run multiple websites is great, but on the other hand, requires some considerations. In this article, I will discuss Drupal multisite in detail to give you an in-depth, complete understanding of how multisite works, why it is used, when it makes sense and when to avoid it.

What is a Drupal multisite and how it works

A Drupal multisite installation is an installation which supports more than one Drupal website on a single codebase. 

A multisite is achieved by creating a separate folder for each website in the /sites/ folder of the Drupal system. For example:

1. /sites/website-one.com/ 
2. /sites/website-two.com/

Each of the website folders contains its own settings.php file and connects to a separate database. It also contains its own binary files (images, uploads etc). 

When a request comes to the server, Drupal can map the request depending on which domain it comes from a particular folder and load the correct database and configuration (enabled modules, themes, content etc) serving us with a completely separate website.

Additionally, we can control which website can use which modules and themes placing them in correct folders accessible only for particular websites.

For a very in-depth article on all the technicalities please refer to a blog post about how drupal works under the hood.

This is a fairly simple concept, which gives us massive power to build a robust platform which can successfully serve even hundreds of websites from one codebase.

Drupal multisite vs drupal multi-domain (disambiguation)

Before we discuss Drupal multisite any further, we first have to clearly differentiate between two different approaches in which a Drupal installation can serve multiple websites: a Drupal multisite compared to Drupal multidomain.

In the multisite approach, described above (and in this article), we are using the single code base and creating separate websites on it. Each website has its own database and content and in essence, all websites are completely separate. They could even be hosted on separate servers.

In a multidomain approach, we do not use the multisite functionality as described above. Rather than that, we use the Domain Access module to introduce variability on what our website does, depending on which (domain) the request comes from. 

In a multidomain approach, there is just one database, but there are additional settings depending on the domain. We can control many things, like:

• what content can be accessed, 
• what users can log in, 
• which theme is enabled or,
• which blocks are placed in regions. 
• We can also have separate menus and various other things. 

We can create websites which to the end-user seem completely separate, but in multidomain they are in essence one system which is inseparable.

I will not explain here in detail how multidomain works and what are its pros and cons. As a rule of thumb:

• If your goal is to reuse functionality, standardize code and features, reduce maintenance of multiple websites and launch many websites fast (e.g. per brand websites, per country websites, etc.) -> use the multisite approach
• If you want to share users, content, data etc between a few websites, which are very similar in nature and somehow relate to each other -> use the multidomain approach

What are the benefits of a multisite setup?

A Drupal multisite can help build a standardized system which will help launch and manage a fleet of websites effectively. 

Multisite allows for re-using the work done for one website

Build a feature once and deploy to all websites. This is the holy grail of the multisite. You actually do re-use code. 

You could do that of course without a multisite, but in practice, if websites are not on one platform it is really difficult. Thanks to a multisite, a feature built for one website works with other websites out of the box.

It is not only feature re-use, however. Thanks to a multisite you can capitalize on Drupal’s theme inheritance mechanism. You can build a base theme and then create additional themes which inherit the basics but add additional accents.

This saves massive amounts of time on frontend work. You make sure the base theme works on all devices and then all child themes do so out of the box.

Multisite reduces the amount of code and maintenance

Less code is less trouble. If you have one system, you have much less code to manage than if you have multiple systems. It makes it easier to manage the code.

• Make sure it is up to date
• Review it
• Maintain a high standard

If you fix a bug that affects something (e.g. a security issue or how a menu works on a mobile device) you can deploy it to all websites at once.

A multisite (typically) reduces technological debt

Technical debt arises when the development team, to deliver results fast, makes compromises, which later might create problems in case of updates or usage. 

Working in a Drupal Agency for over 10 years, I have seen many websites built by various teams working at bigger and smaller agencies. Typically some compromises are taken to meet the aggressive deadlines a website typically has. 

Overall technical debt is not a bad thing, but rather a business decision - lets ship fast and refactor later. It gets the job done, but there may be a knock-on effect down the line. 

The problem of many websites however is that this debt is never paid. There are no budgets to return and refactor, fix and improve, once the website is live. The team moves over to the next website, where the deadlines are similar and then the next one. On each assignment, some debt is acquired. Eventually, the company has a lot of code (separate code for each website) and each code has some debt. 

This debt then comes calling when updates have to be made or change to the website (e.g. rebranding, etc.). Suddenly it turns out that more time has to be spent updating and changing than anticipated because the system is not as flexible as we would like it to be or some things do not work as they should. And this occurs a bit on each website and on each of them in a bit different form. 

A multisite approach removes this problem quite often.

Firstly, the fact that you have less code already reduces your technological debt. 

Secondly, multisite systems are typically delivered in higher quality than “many single separate websites”. There are a few factors which cause it:

• The company can take time to choose the right vendor for all its websites when it might be a too expensive and complex process to go through on a pre-website basis
• The development teams take greater care to create. flexible and long-lasting solutions if they know that it will not be just one website but many and any debt incurred will come back to bite them quite quickly.
• It is also easier to sell the need for a refactor to the management if it will be used on many websites rather than on one. 

To learn more about multisite and technical debt, please refer to my blog post about reducing technological debt by building a Drupal multisite.

A multisite lets the company launch websites quickly

What many companies look for when they decide for a multisite is the ability to launch websites quicker and with reduced cost. 

A Drupal multisite with a built-in installation profile can allow for a new website boilerplate to be launched in hours (if not minutes) fully ready for content entry and with limited support from IT.

Drupal installation profile is a way to capture a lot of functionality and configuration that was once built in an installable package which can then be launched again and again. Companies which require many websites to be built fast can gain massive benefits by using the multisite approach.

Read more about installation profiles in a multisite.

A multisite reduces maintenance costs

If we have one codebase, it is cheaper to maintain it. In the mentioned above post about reducing technological debt I did a short calculation that if a company has 50 websites and each requires 20 hours a month, this quickly adds up to 1000 hours a month of work just to maintain. A multisite can reduce this dramatically since many of the operations done for one website are automatically propagated to all the others.

What are the drawbacks of the multisite approach?

As with each solution, a multisite also has a few things that have to be taken into consideration.

It is more technologically advanced

Building and maintaining a successful multisite installation requires more technical aptitude than building multiple, completely separate, Drupal websites. There are more things that have to be taken into account and more settings which have to be managed. Overall the system is more complex. 

An insufficiently experienced team might get bogged down with issues and problems which will slow the development down and the benefits of a multisite might never be obtained. Choosing the right Drupal development team is critical to the success of the project. It would be best if the company had previous Drupal multisite experience.

More planning is required

If you build one website, it is much easier to iterate quickly, change and adapt. If you are building a multisite, change requests might require a bigger refactors. 

1. You are planning for many websites. Whenever you change something, you have to consider how it will impact all the other websites. You have to think about how you want all the websites to work overall, rather than how you want this particular banner or form to work on one website.
2. Changes in a multisite require more refactoring and are more expensive. If you need something new or a change for one website, typically you might have to alter the installation profile and write updates for the already created and live websites. This is a more difficult process than just changing one website.

Websites should adhere to a standard

Multisite is great because it allows you to reuse components built previously. This, however, is a double-edged sword. These components work as they do. To be able to use the already existing components, you will have to conform to some standards you-ve set previously. For example, if you create one publishing workflow, it would be great if all the websites followed it.

Luckily in Drupal, you can almost always alter stuff on a per-website basis, but the more you do, the fewer benefits you will have of a multisite. 

When to use a multisite

We now know how multisite works and what are the benefits. So when should you use a multisite approach?

When you have to build many similar websites

Organizations quite often have a need to build many websites which differ mostly in content but overall have the same or very similar functionality and appearance: a website per country, per brand, the same type of website every year for an event or a website per department of a university.

When there are 2 websites or more

Obviously, you cannot have a multisite with just 1 website. What I want to say though is that it makes sense to create a multisite for just 2 websites. And the bigger they are, the more it makes sense to do it.

If they are not on a multisite, their codes will differ more and more and it will be more difficult for one team to maintain them. 

Your team will have a much better focus if they just have one codebase to worry about.

When not to use a multisite

A multisite is a great way to build high-quality systems which can then run multiple websites. That said, it is not always a good idea to create a multisite. The strength of a multisite is the reusability of things - create once, use everywhere. Also, it is the shared maintenance - fix a bug once - deploy to all websites. If we cannot achieve these benefits a multisite might not be the right approach.

If the websites are to differ a lot

If you have to build websites which have nothing in common, building them on one multisite will not give you any benefits. For example, if you have to build an e-commerce website, a marketing website site, an intranet and a social networking website which all work and look differently, you would be most likely better off building them separately. 

You could perhaps re-use some components but probably not many and the additional technical complexity would most likely not payback.

If separate teams are to build the websites

A multisite requires good planning and technical coordination to make sure that what is built will work on all websites. This is best achieved if there is one tech lead who can validate plans and accept deliverables. If separate teams are building websites in parallel, it might be difficult to coordinate to achieve a good result.

That said, it is quite popular among companies which have hundreds of websites, to build a multisite platform with installation profiles and then invite separate teams to adapt the websites to various requirements (e.g. local markets). 

The team then cannot change the multisite itself. It can only work within a limited scope - typically only adding a subtheme and modules for a particular website. This approach might be a good compromise if local insights are important and if really hundreds of websites are required and one team would not be able to deliver within a reasonable timeframe.

Other multisite considerations for a multisite

Make sure your hosting supports it

Because a multisite requires a mechanism for managing multiple domains pointing to exactly where you want them to point and the deployment mechanism to be exactly as you require, you have to make sure that your hosting provider will allow for it. Most bigger hosting providers do, but not all, so check before choosing.

Automate deployment

If you are serious about building a robust multisite, you have to ensure you have good DevOps processes which will support it.
Because deploying changes to a multisite means deploying changes to many websites at the same time, automating the process is a very good approach to ensure predictability and avoid errors.

Automate tests

Because each change you will deploy will by default have to be deployed to all the websites, you will have to make sure that you did not break anything on any of the live websites. If there are many websites you manage, doing it manually might be very tedious and time-consuming. 

The best way to validate that new changes do not break the functionality of any of the websites is by testing them automatically. Many tools are now available which can help you test functionality and the appearance of the websites even on many browsers and devices. Automating will ensure high quality over long periods of time. 

Summary

A Drupal multisite allows companies to build many websites on the same codebase. It is a great way to reduce the amount of code and time it takes to maintain it. It can help organizations to build websites faster and with higher quality thanks to installation profiles and re-use of the same functionality on many websites. It can save time and money. On the other hand, it requires greater planning and more technical ability of the implementing team. 

If you have to build and maintain multiple websites, you should definitely consider a multisite approach.