Choosing a Multisite Approach in Drupal

Organizations usually begin considering a multisite approach (the ability to manage multiple distinct websites from one single Drupal instance) when they are scaling their digital presence. This scaling is not only about traffic, but also about organizational structure.

Common drivers include:

• the need to support many related brands, locations, or programs that require their own websites
• pressure to reduce long-term maintenance costs and duplicated effort
• desire to balance central governance with local autonomy, while maintaining shared design systems or functionality across multiple properties.

A multisite architecture is not always the right answer. It often introduces additional complexity and is rarely justified when sites have fundamentally different goals or audiences, when editorial teams require complete independence, or when there is insufficient technical capacity to support shared infrastructure.

When a multisite approach does make sense, there are several established patterns in Drupal. Each pattern solves a different organizational problem and comes with meaningful tradeoffs.

Single Codebase, Multiple Sites

This category includes approaches where many independent Drupal sites share a common codebase while maintaining separate databases, configuration, and content.

Two common implementations of this pattern are custom upstreams (commonly used on Pantheon) and Acquia Site Factory. These approaches are often discussed together, but they differ in important and practical ways.

Custom Upstreams

What it is

Custom upstreams allow multiple Drupal sites to inherit from a shared upstream Git repository. Each site is a fully independent Drupal installation. The upstream defines only the shared code, and perhaps a starting point for the site configuration.

Sites choose when to pull updates and can diverge when necessary.

Best fit when

• You have many similar sites such as offices, chapters, or locations.
• Central engineering teams manage releases.
• Site autonomy and failure isolation are important.
• Governance can be handled through process rather than tooling.

Pros

• Clear separation between sites, including content, configuration, and databases.
• Centralized feature and security updates.
• Predictable deployments and rollbacks.
• Site-specific issues are easier to debug and reason about.
• Strong failure isolation between sites.

Cons

• Cross-site content sharing is difficult.
• Mass content updates require custom tooling or workflows.
• Site-level customization can lead to long-term divergence.
• Consistency depends on discipline rather than enforcement.

Summary

Custom upstreams optimize for operational clarity and independence. They scale well when sites are intentionally similar but not tightly coupled.

Acquia Site Factory

What it is

Acquia Site Factory is a managed multisite platform layered on top of Drupal and Acquia’s hosting infrastructure. In addition to sharing code, Acquia Site Factory provides a central control plane for provisioning, governance, and operations across a large portfolio of sites.

The platform is designed as a true site factory, with templated site creation and centralized management.

Best fit when

• You manage very large site portfolios, often numbering in the hundreds.
• Governance, compliance, and standardization are primary concerns.
• Non-technical users need to create new sites.
• Central control is valued over flexibility.

Pros

• Centralized site creation and lifecycle management.
• Built-in governance, roles, and permission models.
• Templated site provisioning at scale.
• Integrated security, monitoring, and platform support.
• Reduced operational burden for large programs.

Cons

• Higher platform dependency and lock-in.
• More opinionated workflows and constraints.
• Less transparency into the underlying architecture.
• Cost and complexity may be excessive for smaller portfolios.
• Failure domains may be broader depending on platform configuration.

Summary

Acquia Site Factory optimizes for governance and scale. It trades architectural flexibility for centralized control and operational efficiency.

A critical distinction

While both approaches support a single codebase with multiple sites, they emphasize different priorities.

• Pantheon Custom Upstreams emphasize site autonomy.
• Acquia Site Factory emphasizes centralized governance.

This distinction affects deployment workflows, debugging, onboarding new sites, and the long-term evolution of the platform.

Traditional Drupal Multisite

What it is

Traditional Drupal multisite allows multiple websites to run from a single Drupal codebase using separate directories under /sites. Each site typically has its own database and configuration. All sites share the same runtime, deployment process, and underlying infrastructure.

This approach is built into Drupal core and remains fully supported.

Best fit when

• You manage a small number of closely related sites.
• Infrastructure simplicity is a priority.
• Centralized deployments are acceptable.
• Failure isolation is not critical.

Pros

• Native to Drupal with no additional platform requirements.
• Shared codebase with minimal tooling.
• Lower hosting and infrastructure costs.
• Familiar pattern for long-time Drupal teams.

Cons

• All sites share the same runtime and infrastructure.
• A deployment issue, performance problem, or outage can affect every site.
• Limited isolation between sites.
• CI/CD and rollback workflows are more complex.
• Risk increases significantly as the number of sites grows.

Summary

Traditional multisite optimizes for simplicity and cost reduction at small scale. Shared runtime risk becomes a significant drawback as complexity increases.

Drupal Domain module

What it is

The Domain module allows a single Drupal site and database to serve multiple domains or subdomains. Content is explicitly assigned to one or more domains at publish time.

Out of the box, content is not automatically shared across domains. Editors must intentionally choose which domain or domains the content belongs to.

Best fit when

• Domains represent closely related organizations, programs, or campaigns.
• Editorial teams overlap significantly.
• Content reuse is intentional and controlled.
• Centralized user management is important.

Pros

• A single codebase, database, and user system.
• Explicit control over where content appears.
• Content can be assigned to multiple domains when needed.
• Shared media libraries and assets.
• Centralized editorial workflows and permissions.

Cons

• Content sharing is manual and intentional rather than implicit.
• Editorial complexity increases as the number of domains grows.
• Menus, blocks, and layouts often require domain-specific configuration.
• Configuration management becomes significantly more complex.
• All domains share the same runtime and infrastructure.
• A failure or deployment issue affects every domain.

Summary

The Domain module shifts complexity away from infrastructure and into editorial experience and configuration management. Clear domain boundaries and editor training are essential.

Decoupled or Composable Multisite

What it is

In a decoupled approach, multiple sites share front-end applications, design systems, or component libraries. Each site maintains its own Drupal backend or content management system.

This pattern is typically part of a broader composable architecture strategy.

Best fit when

• Front-end engineering maturity is high.
• User experiences vary significantly.
• Design systems are a long-term investment.
• Teams already operate across multiple platforms.

Pros

• Maximum flexibility in frontend experiences.
• Clear separation of concerns.
• Independent evolution of design systems.
• Reduced coupling at the Drupal layer.

Cons

• Significantly higher technical complexity.
• Increased infrastructure and operational overhead.
• Slower initial development timelines.
• Strong DevOps and frontend discipline are required.
• Shared frontend infrastructure can introduce shared failure domains.

Summary

Decoupled multisite architectures prioritize strategic flexibility rather than cost savings.

Fully Separate Sites

In some cases, the best multisite decision is not to use a multisite approach at all and maintain separate websites.

Pros

• Maximum autonomy.
• The simplest editorial model.
• Complete isolation of failures.

Cons

• Duplicated effort and higher long-term cost.
• Difficulty enforcing standards.
• Feature parity becomes expensive over time.

Comparison Table

Final Thoughts

There is no universally perfect Drupal multisite solution.

The real question is what are you optimizing your site for? Autonomy, consistency, speed, and shared content lead to different architectural decisions.

Most multisite challenges are organizational first and technical second. The right architecture reflects how teams work today and how they expect to scale in the future.

Get in touch with us to talk about the best multisite options for your organization.