I get a lot of questions in my role as an architect about Drupal multisite configuration. Why is this so challenging? Why don’t products support it better? Why can’t we have the flexibility that we want? All good questions, and reasonable answers can be found to all of them (and more). But the bottom line is that Drupal multisite is one of the most challenging and complex ways of building in Drupal and just because it’s ultimately “easier to maintain” in the long run (thanks to the single codebase) that doesn’t mean it’s not still really complicated.
Some products like Acquia’s Site Factory do help with the orchestration and deployment of the sites. BUT I cannot stress enough that Site Factory (and its competitors) don’t magically make multisite work. You still have to plan what you want your platform to do. And then you have to build it.
What is Drupal Multisite?
Drupal has a feature that allows separate, independent sites to be served from a single codebase. Each site has its own database, configuration, files and base domain or URL.
Drupal Multisite is a technique of building "more than one” Drupal site but utilizing the same underlying codebase. There are significant pros (particularly in the management of hosting) sites using a multisite configuration, and more than a few cons (particularly in how you structure and organize the sites, their configuration, etc.). Multisite is particularly appealing to organizations that need true platforms with a large number of sites. Acquia has customers running thousands of Drupal sites on multisite platforms. If you’re at an organization that needs more than one site, multisite “might” be an appealing way to handle it.
Early in my Drupal career I worked at an organization where we accumulated a portfolio of 40-50 Drupal 7 sites. Looking back, there have been many discussions about the path we took (of 40-50 single sites) and if we should have gone the multisite route. The answer we came to was… well multisite would have helped us “some” of the time (and hurt us in other cases). Let’s dig into each.
Where Multisite Helps
Multisite is great if you have a lot of sites that generally look and feel the same. This doesn’t mean you have to build 100 identical sites, far from it. BUT if you’re planning on building a lot of sites that mostly have the same features, that mostly publish the same sort of content, and mostly target the same type of audience, then a multisite platform might be really nice.
Some of the best applications of multisite I’ve seen over the past several years come from organizations (such as universities and larger enterprises) that have many smaller units within the larger whole (like university colleges / departments and brands within the larger company portfolio). Why is this case so appealing? Let’s look at the university example!
If you’re a university and you have a bunch of sites that you need to spin up and manage… colleges within the broader university should “theoretically” be similar in terms of their needs. For instance:
common branding (based on the university)
similar content model (given the types of content being hosted)
consistent audience (types of users accessing the sites).
Each site would have its own users, content, logos, etc. to differentiate and individualize. But the core of what makes a site would be largely the same in this scenario. This makes it a great use case for multisite!
Where Multisite Hurts
Let’s imagine a scenario where Facebook, Google, and Twitter are all built on Drupal. These sites have drastically different uses. Even Twitter and Facebook which are both designated social media platforms have quite different use cases and approaches to the concept. Could you build three applications like these on a Drupal multisite? YES you could. But I think you’d spend a lot of time fighting against Drupal to make it work.
Multisite is not a great solution where you have vastly different features and configuration. Will it work? Yes. Will it work “easily”? No.
Remember too that multisite does offer some hard constraints. For instance:
you physically “cannot” update only “some” of the sites. You have to do them all because it’s a single codebase.
you cannot run different versions of the same module simultaneously. so if you want to bump versions or one site requires a particular version of a module the entire platform has to run that version
Back to my 40-50 Sites
So let’s go back to those 40-50 sites my team built years ago.
SOME of those sites would definitely benefit from a multisite platform. They had common features, branding, and content architecture.
SOME of those sites would definitely not have benefitted from a multisite platform because they were built for different customers with different branding, architecture, and overall requirements.
Let’s dig a bit deeper into the configuration aspect of this and talk about why multisite isn’t always the best fit.
How does Configuration Work on a Multisite Platform?
In Drupal 9 (and Drupal 8) configuration management is a critical component of your architecture. Even more so on multisite!
On one end of the spectrum we have the “easiest” multisite platform to manage. In this scenario, we have basically the exact same configuration on all the sites and the only variation is content.
On the other end of the spectrum we have the “hardest” multisite platform to manage. In this scenario, each site has its own disparate config and may not have a true config strategy at all.
The most realistic scenario is obviously going to be somewhere in the middle, but let’s talk about these two extremes.
When all of your config is exactly the same, you can do an update / build a new feature and it goes everywhere and works exactly the same way everywhere it goes. This is a good thing. Why? Well let’s imagine a critical security update coming out. You want to get that updated, tested, and deployed ASAP. If you have a thousand sites you can’t physically take the time to fully regression test a thousand sites. If all the sites are “more or less” the same, if you make a change and it’s “ok” in the couple of places you test it, it should be ok everywhere (because everything is the same).
Let’s look at the other end of the spectrum. If you have a thousand sites that are all different… how do you know if the change you’re making is ok everywhere without testing it everywhere? You don’t! You can’t! And I’ve seen many customers get into this exact scenario. They make a change that is fine on this one site over here, but they deploy it and suddenly one of those other sites over there has a problem. You fix that problem and get that site working, and yet another site starts to experience a problem.
My recommendation is to try and find a “happy medium” between the two scenarios. It’s not at all realistic to think you’d build a platform with exactly the same configuration. But if you can share at least 85-90% of the config (if not more) you’ll be in the best shape possible. What does that look like?
Try to deploy the same basic features to all your sites — this means the same content types, blocks, views, etc.
Build a base profile and base theme that has most of your standard capabilities — this means that all sites essentially have the same baseline capabilities to begin
Limit the “one off” configurations as much as possible — something like a site name? that’s pretty benign. Adding an entirely different content type or drastically changing a content type opens the possibility for hardships
Remember that “per site” configuration should be limited as much as possible — imagine having a thousand sites each with their own individual config. That’s a LOT of config to keep track of and manage (and why having as much shared config as possible is so important).
I talk in more detail about configuration management strategies in another post.
How to get Started with Drupal 9 Multisite
Challenges aside, multisite is a really compelling model for many organizations. My strong recommendation is to start as far back from the technology as possible.
Pull together stakeholders from your organization and do a discovery to determine what features you will need on the platform.
Work with your design team to establish component based design principles for your organization (this means instead of building a bunch of one off content types for your landing pages, build a generic landing page and a bunch of custom block types to let your content team build up those pages).
Put a governance team in place to help make decisions for your organization (and your platform) so that whatever you all decide persists long-term and doesn’t go off the rails because one part of the organization is louder / more forceful than the rest.
Once you have some of the basics in place, then you can start figuring out your configuration management and development strategy. Remember, multisite may be a great fit for your organization but not all of your sites!
I recently had a customer tell me that they wanted to put an internally facing product development website full of unreleased intellectual property on the same multisite platform as their public facing customer sites. I mean, can you do that? Will Drupal work in that situation? Of course it will! BUT remember if you have drastically different config and audiences, the platform is that much harder to maintain, test, deploy, etc. and in this scenario introducing a site with such a different audience and security posture into what is otherwise a public facing platform is highly risky.
So here I would suggest a multisite platform for the public facing part of the company and a different application for the internally facing one. Which itself could be a multisite platform (if there are multiple sites needed for the intranet).
The take away here is that multisite isn’t a magic bullet that just lets you shove all the things into a single big application. I mean sure you can try to build it that way, but just like anything built on a poor foundation sooner or later you’ll put too much weight on and it will start to collapse.
If you build it right though, you’ll have an incredibly powerful platform that can scale and grow as far as your resources for hosting capacity will allow.
Related Content
I hit a couple of issues updating to Drupal 9.3, so I wanted to share my experience. Config changes incoming!