Drupal multisite architecture

When Drupal multisite architecture fits a multi-site estate

If your organization runs several Drupal sites that share branding, governance or platform staff, Drupal multisite architecture is the core multisite feature that serves them from one codebase, with a separate database and file directory for each site. The sites share code, modules and themes, but each keeps its own content and configuration. Whether that fits depends less on how many sites you have than on how independent they must be. Sites that must change at different speeds, carry different contributed modules or follow different release approvals will strain a shared codebase quickly.

The shared codebase also sets the upgrade clock for every site. The Drupal core release schedule fixes when bugfix, security and major releases arrive, and one core upgrade or one contributed module update touches every site in the estate at once. Before committing, list each site's owner, traffic, compliance obligations and tolerance for downtime, then ask which sites could pause for a week without business harm. Those answers tell you whether a single upgrade window is workable or whether some sites need their own codebase.

Confirm the decision with your own estate inventory before any build starts. Count the contributed modules each site depends on, note any site that uses a different theme framework or PHP setting, and record which teams can approve a release. Ask a partner to estimate the upgrade test effort for the whole estate, not one site, and ask how they would isolate a site that cannot follow the common schedule. Where sites must be fully independent, a separate codebase per site, or a shared-platform approach such as Domain Access, may fit better, and that choice should be made before the shared codebase hardens around assumptions that do not hold.

Which multisite approach fits which estate

This table compares core multisite, Domain Access and separate codebases across upgrade effort, data and file isolation, module and theme freedom, operational overhead and fit. Read each row against your estate: the more sites that must differ in design, modules or release timing, the more the right column moves away from shared-codebase options.

Factor	Core multisite	Domain Access	Separate codebases per site
Shared upgrade effort	One codebase, so a core or contributed update is applied once, but every site must pass testing before the shared release goes out	One site installation, so upgrades touch a single system and content model	Each codebase is upgraded on its own schedule, so effort repeats for every site and drifts over time
Data and file isolation	Separate database and files directory per site, sharing only the code	Content is shared inside one database, so isolation depends on access control and content roles	Full isolation of database, files and infrastructure, which suits differing data residency rules
Module and theme freedom	Modules are shared across sites, though themes and some settings can differ per site	Limited to one module set and one theme stack for the whole estate	Each site chooses its own modules, themes and core version, within its own governance
Release coupling	A bad shared release can affect every site at once, so staged rollout and strong test coverage matter	Coupling is total because all domains share one site	Releases are decoupled, but coordination and security patching must be tracked per codebase
Operational overhead	Moderate: one pipeline and one codebase, plus per-site configuration, backups and cron checks	Lowest for content sharing, with editorial governance as the main ongoing cost	Highest: multiple pipelines, hosts, monitoring setups and patch cycles to staff
When it fits	Many sites sharing a design system, module set and release calendar, such as a family of brand or regional sites	Several domains that present one content set in different languages, regions or audiences	Sites with divergent functional needs, separate owners, or regulatory boundaries that a shared codebase cannot meet

Where coupled release cycles hurt multisite estates

Core multisite shares one codebase, so every release decision made for one site is made for all of them. The risks below follow from that coupling and from the release cadence published in the core release schedule. Each one is something to check in your own estate before you commit to a single codebase.

One module update reaches every site

A single core or contributed module update is deployed to the shared codebase, so it lands on every site at the same moment. A minor change to a shared field type, a theme dependency or a payment or search module can alter behavior on sites whose owners never asked for it. Ask which sites use each contributed module, and whether a staging copy of each site can be tested before the shared code moves.

Shared test coverage gaps

Most multisite estates have automated tests for the flagship site and little or none for the smaller ones. A passing suite can hide a broken checkout, form or login on a site nobody tested. Confirm which sites have test coverage, who owns the regression checklist for each one, and whether a failed check on one site blocks the release for all of them.

One site blocks the release for others

A custom module written for one site, or a site-specific configuration that has drifted, can fail a database update or a configuration import that every other site must pass. The whole estate then waits on that one site's fix. Ask who owns custom code, whether custom modules are kept in a separate repository per site, and what the rollback path is when one site fails after the others have updated.

Security releases fall on a fixed day

Security releases arrive on the third Wednesday of the month, while bugfix releases arrive on the first Wednesday. Because every site shares the code, one advisory forces patching across the whole estate on a schedule the owners of each site did not choose. Confirm that your change process can approve and deploy an emergency patch within a day, and that each site owner has agreed in advance to a window.

Major version moves hit the whole estate

New major versions are typically released about every three years, and the core release schedule sets end-of-life dates for each line. When the estate runs one core version, the upgrade for the largest or most complex site sets the date for every other site. Ask whether the estate can keep sites on different core versions in separate codebases, and how long the current major line remains supported for each site.

Ownership and approvals are shared

When one codebase serves many business owners, no single team controls its release calendar. Requests for freezes, feature launches and emergency fixes compete for the same deployment pipeline. Confirm who approves a shared release, how site owners are notified, and whether a site can be excluded from a release without forking the code.

How to plan and build a multisite Drupal estate

This sequence moves a group of sites from an informal list into one shared Drupal codebase with separate data, settings and release checks for each site. Each step closes with a check that proves the estate can be updated and restored one site at a time.

Inventory sites and independence needs
Start by listing every site, its owner, its audience, its launch and retirement plans, and its data rules. Record which sites must be able to pause, roll back or upgrade on their own schedule, and which sites can share themes, modules and content types. Ask each owner to confirm their regulatory, accessibility and hosting constraints in writing. This step is done when every site has a row in the inventory with an agreed independence requirement, and the owners have signed off on it.
Decide the multisite architecture
Compare core multisite (one codebase, one installation per site, each with its own database and files directory) against Domain Access (one site with shared content across domains) and separate codebases. Use the inventory to decide which pattern fits each group of sites, and document why. Include who approves exceptions, because a single site that needs its own release cycle often breaks the model. This step is done when a written decision record names the pattern, the reasons and the sites it excludes.
Define the shared codebase and per-site settings
Set up one Composer-managed repository with core, shared contributed modules and a shared theme. Decide what each site may configure on its own, such as site name, content and some blocks, and what must stay identical, such as core and security modules. Keep secrets and environment values out of the repository and load them per site. This step is done when a clean build from the repository produces the same code for every site, and the list of per-site settings is written down.
Set up databases and file storage per site
Create a separate database, database user and database credentials for each site, and give each site its own private and public files location. Decide whether the database engine is shared or dedicated for each site, and confirm the engine version your Drupal release requires. Confirm that one site cannot read another site's files or tables through the web server or database user. This step is done when a test request to each site reaches only its own database and files path.
Configure the sites directory and trusted host patterns
Map each domain to its site directory in the sites folder, using a sites.php file where domains and directories differ. Set trusted_host_patterns in each site's settings so that requests with unexpected host headers are rejected. Check the web server configuration so that each virtual host passes the right host header and file paths. This step is done when each domain loads only its own site, and a request with an unlisted host header is refused.
Establish a shared update and test pipeline
Build one pipeline that runs for all sites: Composer update in a branch, automated tests, database updates and configuration import on a staging copy of each site, then promotion. Decide the order in which sites are updated, and whether a failing site blocks the rest or is held back alone. Plan how security releases, which Drupal.org publishes on Wednesdays, reach every site quickly. This step is done when one change has passed through staging for every site and the result is recorded per site.
Verify each site with backup and restore checks
Take a backup of each site's database and files, then restore each one to a separate environment and check that it loads, logs in and passes the site's key pages. Confirm that restoring one site does not touch the others. Ask your hosting or platform team to confirm the restore time and the retention they can meet in your environment. This step is done when every site has a restore record that names the backup, the date and the person who checked it.

When Domain Access or separate codebases fit better

When one organization runs several domains for the same brand and wants editors to share content across them, the Domain Access contributed module is usually the closer fit than separate installs. Domain Access keeps one database and one codebase, then lets content be assigned to one or more domains and published selectively, so a regional site can reuse a global article without copying it. The trade-off is that every domain shares the same content model, roles and release cycle, so a change that suits one brand audience can affect all of them.

Content sharing: Nodes can be published to several domains, which removes manual copying between sites.
Shared permissions: Editorial roles are defined once, so access rules must be designed per domain rather than per site.
Single release calendar: All domains move together on the same core and module upgrades.
Module compatibility: Confirm that every contributed module in use supports domain-aware behavior before committing.
Search and caching: Check how the search index and cache tags handle per-domain content.

Before choosing, ask your team to list which content must be shared, which can differ by domain, and whether any domain needs a different release date.",

Core multisite fits a small number of sites that share a design system, a team and a release calendar, and where each site has its own database and files. Core multisite runs one codebase against several settings.php entries and separate databases, so a core or module update is applied once. The cost is that all sites share one code tree, so a module that breaks on one site can block the update for every site, and the team must test each site after each release.

Shared codebase: One Composer project and one deployment pipeline serve every site.
Separate data: Each site keeps its own database and sites/ directory, which limits data mixing.
Coupled upgrades: A failing update on one site delays the rollout for all of them.
Operational growth: Adding sites increases test time, database maintenance and backup jobs linearly.
Configuration isolation: Confirm that per-site settings, such as trusted host patterns, are managed without copy errors.

Before choosing, ask how many sites are planned, how often they will diverge in features, and whether one team will own all of them.

Security boundaries to design for in a multisite estate

A multisite Drupal estate shares one codebase, one release train and often one team, so a weakness in one site can reach the others. The cards below cover the boundaries to design before the first site launches, from credentials and secrets to shared accounts and the advisory process that patches every site at once.

Per-site database credentials

Each site in a multisite install has its own database, and the database user for each site should only have rights to that site's schema. Sharing one database account across sites means a compromised settings file exposes every site's content and users. Check that each settings.php entry under sites/ points to a distinct user, and that the account cannot read or write sibling databases on the same server.

Secrets kept out of the repository

Because all sites live in one Git repository, a password or API key committed once is copied to every site and to every clone. Keep database passwords, salts, mail and API credentials in environment variables or a secrets manager, and load them in each site's settings file at runtime. Confirm the repository history has been scanned for credentials that were committed before this rule existed.

Per-site file access and private paths

Each site has its own public and private file directories, and the web server must block direct access to private paths for every site, not only the first one configured. Test that a file from site A cannot be fetched through a URL on site B, and that the private file path sits outside the web root. Decide whether each site may use a shared storage bucket and, if so, how its prefix is isolated.

Shared user accounts and roles

Core multisite does not provide a single sign-on boundary: each site keeps its own users, roles and permissions, so the same person may hold different rights on each site. Decide which sites share an identity provider, how accounts are created and removed when someone leaves, and who may grant administrator roles on each site. Document the offboarding path, because a disabled account on one site can remain active on another.

Trusted host configuration per site

Each site must list the host names it answers to in trusted_host_patterns, so that a request with a spoofed Host header cannot poison generated links or password reset emails. In a multisite layout, check that every site directory has its own pattern and that a new domain pointed at the server does not fall through to an unintended site. Test this in each environment, because the list often differs between staging and production.

One advisory response for every site

The Drupal Security Team publishes advisories for core and contributed projects, and a security release applies to every site that runs the affected code. Because the sites share one codebase, one vulnerable module can expose the whole estate on the same Wednesday release window. Plan who watches advisories, how fast a patch is tested across sites, and how a site with a custom override of a contributed module is handled.

Questions buyers ask about Drupal multisite

Does multisite cost less effort than running separate Drupal sites?

Multisite usually reduces the repeated work of building, upgrading and patching one codebase, but it does not remove the per-site work. Each site still needs its own content model decisions, theme variations, database, file store, settings and testing. The effort saved on shared upgrades is real only if the sites genuinely share modules, configuration and a release calendar. Ask for the quote to separate one-time build work (shared platform, site template, migration of each site) from recurring work (upgrade testing, security releases, per-site content and configuration changes). Compare both options against the same written list of sites.

How long do setup and migration into a multisite take?

The duration depends mostly on the number of sites, how different their content models and themes are, how much content must move, and how many integrations each site uses. Setup of the shared platform is a separate piece of work from migrating each site, and migrations of Drupal 6 or 7 sites are slower because themes must be rebuilt and content is moved into a new site with the core Migrate modules or Drush. Ask for a timeline per site and per phase in the written scope, and confirm which sites have sign-off dependencies with other teams.

What must our team provide before a multisite project starts?

The engagement depends on a few inputs from your side:

Named content owners for each site who can approve content models, navigation and sign-off
A release calendar that shows freeze windows, campaign launches and change approval steps
Hosting access to the environments, databases, file stores and DNS records used by each site
Identity, mail and integration contacts who can grant test accounts and credentials

Confirm these owners and access paths in the written plan before work begins, since delays in any one of them move every site that shares the platform.

Can our internal team run a multisite Drupal platform after launch?

Yes, if the team has the skills and time to handle shared upgrades, security releases and per-site operations. A multisite platform needs people who understand Composer builds, database updates, configuration import, cron and backups across every site. Security releases arrive on the third Wednesday of the month, and bugfix releases on the first Wednesday, so the team must be able to test and deploy on that rhythm. Ask a partner to document the runbook, hand over the build pipeline and agree on whether ongoing support is handled in-house or through a retainer.

How are upgrades and security releases coordinated across sites?

All sites in one multisite share a single Drupal core and contributed module set, so an upgrade or security fix affects every site at once. Coordination means testing each site against the new release before a shared deployment, agreeing on a window that suits the slowest-changing site, and keeping a rollback plan. Drupal 10 reaches end of life on December 9, 2026, and Drupal 12 is scheduled for the week of December 7, 2026, so plan the next major upgrade early. Ask for the test matrix, the rollback steps and the approval path for each site in the written plan.

What should a quote for multisite work include?

A quote should follow from a written plan that lists each site, its content types, themes, integrations, data to migrate, environments and acceptance tests. Ask the provider to separate the shared platform build, the per-site work, testing, documentation and handover, and any retainer for ongoing upgrades and security testing. The quote should also state what the client must provide, which assumptions it depends on, and what changes would reopen the price. DeployOpen does not publish a price list, and most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.

When is multisite the wrong choice for our sites?

Multisite fits sites that share a team, brand standards and a release calendar. It fits poorly when sites need different Drupal versions, different module sets with conflicting requirements, or independent release schedules. In those cases separate codebases or Domain Access on a single database may suit better. Confirm your answer against a written inventory of modules, release cadence and compliance boundaries, because a choice made early is expensive to reverse.

What drives the cost of a multisite build

The largest cost driver in a multisite build is discovery, not code. Before anyone configures a site, the team has to establish which sites are truly independent and which only look separate. Sites that share a content model, a menu structure, a search index or a single set of editors create shared-architecture work that is paid for once and then carried by every site. Sites with their own content types, their own theme and their own release timing cost more to isolate, because each needs its own settings, file path, database and test coverage. Ask the partner to document the site inventory, the shared and per-site components, and the decisions each one depends on. A quote that prices the build without that inventory has not measured the work.

Most of the one-time cost sits in the shared platform and in each site's onboarding. The shared platform covers the Composer build, the per-site settings.php pattern, the database and files layout, the hosting topology and the automated test pipeline that runs against every site on each release. Per-site work covers configuration, theme adaptation, and content migration, which is often the least predictable item. Migration effort rises with the number of content types, the volume of legacy content, the number of redirects to preserve and the amount of manual cleanup the editors accept. Ask for a per-site line item for configuration and migration, a separate line for the pipeline, and a statement of which items assume your existing content is clean.

Recurring cost is where multisite decisions pay off or fail. Every core and contributed update, every security release from the Drupal Security Team and every major upgrade is applied to the shared codebase, so one site's test failure can hold back all of them. Monitoring, backups for each database and file set, and the time to triage failures across sites all recur. Ask the partner to state who runs the pipeline, how many sites a single security release is expected to touch, how long the test suite takes per release, and whether support is priced per site or per shared codebase. Confirm these figures against the written scope, since no fixed effort is implied here.

How DeployOpen scopes and delivers a multisite estate

A multisite estate shares one codebase, one upgrade cycle and one set of operational habits, so the scope has to be settled before anyone writes code. The cards below follow the work in order: written scope, delivery in your environment, evidence for assessors, and ongoing support under a retainer.

Written scope before build

DeployOpen agrees scope, deliverables and timelines in writing before work starts, so the multisite decision is made on paper. The scope should list every site, its database and files location, its owning team, its theme and module set, and which sites may diverge from the shared codebase. Ask for the list of sites that are out of scope, because retired or unmanaged sites are where multisite estates tend to drift.

Site inventory and dependency map

Before choosing a layout, DeployOpen works with your team to record each site's contributed modules, custom code, integrations and release owner. Shared modules that appear on several sites become the coupling points that decide whether one upgrade window can serve all sites. Confirm that the inventory covers sites that share a database server, a file store or a cron host, since those shared resources bind release timing as tightly as code does.

Delivery inside your infrastructure

All build and hosting work runs in your cloud accounts, data centers or air-gapped networks, so your team keeps control of the databases, the sites/ directory layout and the deployment pipeline. Agree in advance who holds administrative access, where Composer packages are mirrored and where backups are stored for each site. Confirm these before the first environment is provisioned, not after the sites go live.

Release and rollback runbook

A shared codebase needs a written procedure that says how one site's failed update is isolated from the rest. The runbook covers the order of database updates across sites, the rollback point for each database and file store, and the criteria for holding a site back. DeployOpen documents this runbook as a deliverable so that your operators, not only the delivery team, can execute a release.

Evidence for compliance assessments

DeployOpen prepares the system descriptions, access records, configuration baselines, backup and restore results and change logs that an assessor will ask to see for each site. DeployOpen does not issue audit reports, attestations or certifications; independent auditors and certification bodies make that determination. Ask early which assessor you will use and which evidence format they expect, so the collection matches their request.

Retainers for upgrades and testing

Upgrades and continuous testing are available as retainers, which suit multisite estates because security releases arrive on a fixed schedule and must reach every site. Define in the retainer which sites are covered, who approves a release, and how test results are reported. The retainer cost recurs, so compare it with the internal effort of keeping the same schedule across all sites.