A university is never one website. It's the main institutional site, plus separate sites for each faculty, department, research center, library, and often dozens of individual projects, labs, and events. A large university can easily run anywhere from 50 to several hundred distinct sites. The challenge isn't building any one of them — it's managing all of them together: keeping them secure, on-brand, and up to date without a separate team and a separate technology stack for each. This is the problem Drupal multisite is built to solve, and it's a large part of why so many of the world's leading universities run on Drupal.
This article explains how Drupal multisite works, why it fits the university use case so well, how it compares to the alternatives, and — just as importantly — when it's the wrong choice. The goal is a clear, honest picture that helps an institution decide whether multisite is the right architecture for its web estate.
The Multi-Site Problem Every University Faces
Universities are decentralized by nature. Each faculty wants control over its own site, each department has its own content and editors, and central IT is responsible for keeping the whole estate secure, accessible, and consistent. Left unmanaged, this tension produces a familiar mess: departments spin up their own unsanctioned sites on whatever platform is convenient, brand consistency collapses, security patches are applied unevenly or not at all, and no one has a full picture of what's running.
The platform decision, in other words, is really a governance decision in disguise. The question a university needs to answer isn't just "what CMS should we use" but "how do we let dozens of teams manage their own sites while central IT keeps the whole estate secure and coherent?" Drupal multisite is one of the strongest answers to exactly that question.
What Drupal Multisite Actually Is
Drupal is one of the few content management systems that supports multisite natively in core. A Drupal multisite is a single Drupal installation that runs multiple websites from one shared codebase. The important technical detail is what's shared and what isn't: the sites share the code — Drupal core, modules, and themes — but each site has its own separate database. That means content, configuration, users, and uploaded files are completely separate per site, even though they all run on the same underlying installation.
Mechanically, each site lives in its own subdirectory under the installation, with its own settings file pointing to its own database. When a request arrives, Drupal looks at the domain or URL and loads the correct site's database and configuration. The practical result is a set of sites that look and behave as entirely independent websites — each with its own branding, content, and editorial team — while sharing a single codebase and a single update process underneath. Update the code once, and every site runs the new version.
Why Universities Rely on Multisite
The multisite model maps almost perfectly onto how a university actually operates. Stanford, Yale, Harvard, and Duke all run their own large Drupal site platforms on this principle, and institutions like University College London manage 500 or more microsites from a single governance layer. The advantages that make this work are concrete:
- Update once, deploy everywhere: A security patch or a Drupal version upgrade is applied to the shared codebase once and takes effect across every site. Instead of patching 200 sites individually, central IT runs a single update — the single biggest operational saving multisite offers.
- Central governance with local autonomy: Central IT manages architecture, security, and the design system, while each faculty and department keeps full editorial control of its own content. Departments get their independence; the institution keeps its coherence.
- Brand consistency at scale: A shared design system and shared components mean every site can carry consistent branding and accessibility standards, rather than each one drifting in its own direction.
- Shared development: Custom functionality is built once and made available to every site. A module or feature developed for one faculty can be switched on for the others without rebuilding it.
- Efficient onboarding of new sites: When a new department or program needs a site, it can be provisioned from the shared platform quickly, starting from the same secure, accessible, on-brand baseline rather than from scratch.
For an institution running a large estate of sites, these efficiencies compound. This is exactly the pattern behind Drupal's dominance in higher education, and it connects directly to the platform's broader strengths in the sector, which we cover in our overview of Drupal in education.
Multisite Is Not the Only Option
Classic multisite is one way to run many sites from Drupal, but not the only one. Choosing the right architecture up front saves significant time and cost later, so it's worth understanding the main alternatives.
| Approach | How it works | Best fit |
|---|---|---|
| Classic multisite | One codebase, a separate database per site. Content fully isolated. | Many structurally similar sites needing strong content separation. |
| Domain Access | One codebase and one shared database; a module controls which content belongs to which domain. | Sites that share a lot of content and editors, managed centrally. |
| Separate installations | Each site is its own independent Drupal install, often managed with a shared Composer workflow. | Sites that differ significantly, or need full isolation and independent scaling. |
| Distribution / upstream | A standard Drupal build is packaged and used as the starting point for each new independent site. | Rolling out many sites from a common baseline while keeping them independent. |
The key distinction is content isolation versus content sharing. Multisite gives each site its own database and the strongest separation. Domain Access shares one database, which makes sharing content and editors easy but couples the sites tightly. Separate installations give the most isolation and independence at the cost of managing each one individually. The right answer depends on whether your sites are variations on a theme that should share, or genuinely independent estates that shouldn't.
The Honest Trade-offs: When Multisite Is the Wrong Choice
Multisite is powerful, but it isn't free of risk, and a responsible evaluation has to weigh the downsides as seriously as the benefits. The efficiency of a shared codebase is also its central weakness: it creates a single point of failure.
- Shared fate: Because all sites run on one codebase, a problem in that codebase affects every site at once. A traffic spike on one site can degrade performance for all the others, and a security compromise is harder to contain — if one site is breached through the shared code, the others may be exposed too.
- Limited isolation: There's no strong segmentation between sites at the code level, which is a genuine consideration for institutions with strict security or compliance requirements. Where sites must be fully isolated, separate installations are the safer model.
- Maintenance coupling: Some operations, such as certain upgrades, can require all sites to enter maintenance mode together, and separating one site out of a multisite later is not a trivial task.
- Divergence over time: If sites drift apart in their code or configuration needs, the shared upgrade path can fork, and the simplicity that justified multisite starts to erode.
Modern Drupal workflows have made the alternatives more attractive than they once were. A Composer-based workflow managing separate installations, or a platform that provisions isolated sites from a shared upstream, can deliver much of multisite's consistency without the shared-fate risk. Multisite remains an excellent fit for a large estate of similar, well-governed sites — but for sites that need genuine isolation, independent scaling, or significant divergence, it's often the wrong tool. The honest rule is to choose multisite because your sites are genuinely similar and centrally governed, not simply because it appears to reduce site count.
Governance: The Real Reason This Matters
Underneath the technical architecture, what a university is really buying with multisite is a governance model. The hardest problem in university web management isn't building sites — it's coordinating dozens of autonomous teams without either smothering their independence or losing central control.
A well-run multisite platform resolves that tension explicitly. Central IT owns the shared layer: the codebase, security updates, the design system, accessibility standards, and the overall architecture. Faculties and departments own their content: their own editors, their own publishing schedules, their own site-specific structure within the shared framework. Because roles and permissions are defined centrally, each team gets exactly the access it needs and no more. The result is autonomy where it helps — content — and consistency where it matters — security, branding, and compliance. That balance is the real product, and it's why the platform choice is ultimately a governance decision rather than a purely technical one.
Common Multisite Mistakes and How to Avoid Them
- Choosing multisite to cut site count: The reason to use multisite is genuine similarity and shared governance, not a smaller number on a server. Choose the architecture that fits how the sites actually relate, not the one that looks tidiest.
- Ignoring the single point of failure: A shared codebase means shared risk. Plan for it with strong security practices, performance headroom, and a clear understanding of what happens if one site has a bad day.
- Forcing very different sites together: Sites with significantly divergent code or configuration needs strain the shared model. If the divergence is real, separate installations serve better than a forced multisite.
- Underestimating the exit cost: Separating a site out of a multisite later is difficult. Plan the architecture with future separation in mind rather than assuming sites will stay together forever.
- Neglecting governance: The technology alone doesn't create order. Without a clear model of who owns the shared layer and who owns each site's content, even a well-built multisite drifts into confusion.
- Letting sites diverge unmanaged: Allowing each site to accumulate its own bespoke code erodes the shared-codebase advantage. Keep customizations disciplined and, where possible, shared.
Managed well, Drupal multisite lets a university run a large, coherent web estate from a single platform — central IT keeping everything secure and on-brand, while every faculty and department retains control of its own site. It's one of the clearest reasons Drupal has become the default choice in higher education, and it pairs naturally with the platform's strengths in multilingual content, accessibility, and integration with academic systems.
Frequently Asked Questions About Drupal Multisite
Do multisite sites share content with each other?
Not in a classic multisite. Each site has its own separate database, so content, users, and configuration are isolated — the sites share only the underlying code. If sharing content across sites is a requirement, that's a case for a different architecture, such as Domain Access, which uses a single shared database and lets you control which content appears on which site. The choice between them comes down to whether your sites should be isolated or should share.
How many sites can one Drupal multisite run?
There's no fixed limit, and large institutions run substantial numbers — universities like University College London manage 500 or more sites, and some deployments run into the hundreds or beyond. The practical ceiling is determined less by Drupal itself than by infrastructure, governance discipline, and how similar the sites are. The more sites you run on one codebase, the more important strong operational practices and performance planning become, because they all share that codebase's fate.
Is Drupal multisite being deprecated?
No. Multisite is a valued core feature and is not being removed. There have been community discussions about improving how it works with modern tooling like Composer, and those improvements have progressed, but the feature itself remains supported. That said, the ecosystem now offers strong alternatives — Composer-managed separate installations and platform-based upstreams among them — so the modern question is less "is multisite available" and more "is multisite the right fit for this particular estate."
Multisite or separate installations — which should a university choose?
It depends on how similar and how isolated the sites need to be. Multisite fits a large estate of structurally similar sites that share a design system and should be updated together, with central governance — the classic university department-sites scenario. Separate installations fit sites that differ significantly, need full isolation for security or compliance, or must scale independently. Many universities land on multisite for the bulk of their department sites and separate installations for anything with genuinely distinct requirements. The decision should follow the real relationship between the sites, not just a preference for fewer moving parts.