Oftentimes projects need a way to serve multiple domains from the same installation or from the same codebase. In Drupal we have several ways to accomplish this, and this post will describe some architecture options that make this possible, as well as the relevant factors that can help you decide which option provides the best ‘fit’ for the implementation.
We’ll be looking at four distinct implementation choices: Classic Drupal Multisite, Domain Access or Mega Site, Distribution Profile, and an offshoot of the distribution profile called Custom Upstream.
Classic Drupal Multisite
In a classic Drupal multisite architecture, the individual websites share code (the Drupal core, modules, and themes), but each website has its own database so they do not share content, configuration, or settings. Each website can also have some extra modules / themes under its own subdirectory in the same codebase.
Advantages
- Single codebase:
- Onboarding developers and administrative tasks are easier with a single codebase.
- Code and library updates only need to be done once.
- Some degree of customization is possible, because each site has its own configuration, and it can have it’s own custom theme and modules.
- Shared features can be accomplished by using Feature modules: features modules can be shared across the sites, and then individual sites can import the configuration from it. Another option would be to use the Config Split module to segment what configuration is shared across sites and what should be overridden per site.
- Less hosting costs: a single hosting plan that supports all of the traffic from all of the sites might be cheaper than hosting per individual site.
Disadvantages
- If a site decides to customize functionality provided by a Features module, then it would lose any further updates to the module, as they have deviated from it. This is one of the greatest risks of a multisite setup, because if sites start diverging in functionality, it makes no sense to keep maintaining a single codebase.
- All developers working in the team have access to the codebase that affects all of the sites. This implies a high level of trust in the whole team, and does not allow for separation of concerns, meaning that while team members could be assigned to work only in a particular site, the codebase architecture implies it cannot be enforced on a code level.
- Heavy maintenance:
- Configuration and updates still need to be run once per site and saved back into code configuration (in each site’s config folder).
- Deployments in this architecture need to happen “all at once” for all the sites, which can potentially be chaotic (there is no simple “revert” a commit for a single site, for example).
- Scripts are a frequent solution that comes up to automate maintenance tasks across the sites, which means more devops time.
- Single point of failure:
- Since there is a single server hosting all of the sites, a traffic spike can affect all of the other sites. This is mitigated if most of the content is static (for anonymous users), because it can be cached by a CDN which can deliver the (cached) pages even if the server is down.
- A code error has the potential to affect all of the sites.
- As a note, this setup is not supported by Pantheon, because they don’t allow multiple databases per hosting plan.
Conclusion
A shared codebase setup would be most beneficial if all of the sites are using similar modules and settings. “Snowflake sites”, i.e. sites that need lots of special customization to code or config, can rapidly increase the risk of technical debt in an architecture that was meant to maintain similar sites.
Mega Site (Domain Access)
This architecture consists of a single codebase and single database/installation. The Domain Access suite of modules provide functionality that allows serving multiple sites (domains) from this setup, and specifying which pieces of content belong to a particular site, or are shared across some or all of the sites.
Advantages
- Maintaining a single Drupal installation.
- Updating a single site is faster and easier to test (vs once per site in a multisite setup).
- Maintaining configuration and functionality is straightforward (no need for Feature modules).
- Admin users can effortlessly manage all content from one platform.
- Content and users can be shared across multiple sites (if needed).
- Allows sharing the same features and functionality to all affiliate sites.
Disadvantages
- Single point of failure. A single hosting plan for all of the sites. This is mitigated if most of the content is static (for anonymous users), because it can be cached by a CDN which can deliver the (cached) pages even if the server is down.
- Some contrib modules, and custom or complex functionality might need custom development to make sure they are compatible with the Domain Access module. We call this “glue code”, and a lot might be needed depending on the complexity of the project.
- If a site needs to be “taken away” into its own hosting plan, it’s not straightforward. (note: here we're referring to scenarios where a site might be spun off to another owner because it needs to pay for its own hosting for funding or other organizational reasons.)
- Requires strict governance enforcing a policy of no-exceptions (or extremely few). An exception would be a functionality or config on a site that doesn’t follow the rest. Each “exception” adds complexity to the site, and if left unchecked, can quickly become a maintenance nightmare.
Conclusion
A mega-site setup makes sense if sites will share content and/or users, and if all of the sites will have the same functionality, content types/data structures, and will only differ in limited configurations or theme variations, as in a family of affiliated sites.
Distribution Profile
A Drupal distribution can also be created and maintained. A distribution typically contains a declaration of the required modules and libraries, custom theme and custom modules, and configuration that gets imported during install, maybe even default content. Updates to configuration can also be provided via Features modules as described in the multisite section. Under this use case, each site has its own codebase that includes the distribution profile, and is hosted under separate hosting accounts.
Some well-known distributions are Commerce Kickstart, Lightning, Open Social, etc. While these are large projects that aim to provide a generic starting point for projects, a custom distribution profile can also be created to address the needs of a collection of sites with similar functionality, passing the main burden of development to a centralized team of devs in charge of providing updates and new features.
Advantages
- Sites are independent: Code errors or traffic spikes on one site don’t affect other sites.
- Flexibility: They can be customized more easily (as long as they don’t override configuration provided by the base distribution, so they could still receive functionality updates).
Disadvantages
- Again, sites overriding features provided by the distribution means they won’t be able to update to the latest bug fixes or new functionality provided in the profile.
- This architecture involves maintaining the distribution codebase, plus each of the sites.
- Maintaining a distribution is also hard work. Even more work and attention need to be dedicated if the distribution will be published on drupal.org, as aspects of dealing with security updates and bug reports are more relevant.
Conclusion
A distribution profile works well if the sites are all starting out the same, but they are expected to grow in different directions. Maintenance work is expected and independent for each of the sites. A typical scenario is a university distribution profile, where each department can have its own independent site.
Custom Upstream
This involves maintaining what is essentially a distribution profile directly from a code repository, instead of making it available in drupal.org. Advantages and disadvantages are similar to the distribution profile as well.
Conclusion
A custom upstream can be useful for companies that maintain a base installation profile, and expect to do bespoke development work on each site in order to accommodate different user requirements, transactions or other scenarios from site to site.
