Drupal multisite setup — benefits, risks and hosting needs
🎧 Listen to every article back to back
Drupal multisite is useful when several related websites should share one codebase. It is risky when each site needs independent release timing, different modules or isolated performance.
Drupal supports multisite in core (opens in a new tab): one codebase can serve several independent sites, each with its own database, configuration, files and base URL.
The architecture is attractive because one update can cover many sites. The trade-off is that one bad dependency, weak hosting setup or untested deployment can also affect many sites at once.
When multisite makes sense
Works well when:
- The organisation runs multiple structurally similar sites — regional offices, subsidiaries or separate brands
- The sites share functional requirements — common modules, shared design logic, shared integrations
- You want security updates and Drupal version upgrades to happen for all sites at once, not separately
Does not work well when:
- The sites have completely different functionality from each other
- Teams are independent and want full autonomy over their platform
- Performance issues on one site must not affect the others
How Drupal multisite works technically
Drupal identifies which site to serve based on the domain or URL. Each site gets its own:
- Database — content, users and configuration are separate
- Files directory — uploaded files are stored separately
- Configuration — modules, theme and language settings can be configured independently per site
The shared part is the codebase — Drupal core, contributed modules and custom modules. When you update a module, it updates for all sites at once.
Drupal multisite setup checklist
Before building multisite, decide these points explicitly:
- which domains or subdomains map to which site directories;
- whether each site gets a separate database;
- how uploaded files are separated and backed up;
- which configuration is shared and which is site-specific;
- how updates are tested across all sites before deployment;
- who approves releases when one change affects several teams.
The decision extends beyond Drupal configuration. It also concerns hosting requirements, backups and governance.
Practical benefits
Updates — one Composer update changes the shared codebase once. Database updates and regression checks still need to run for every affected site.
Shared development — custom functionality is written once and available to all sites. When one site gets a new module, it can be activated on the others easily.
Shared deployment — one CI/CD pipeline, one deploy process, one staging environment.
What needs planning
Database separation — each site needs its own database connection. Simple to configure, but needs to be factored into hosting requirements.
Capacity planning — combined traffic, cron jobs and queues from several sites can increase the load on shared infrastructure. Size the environment for the total workload rather than one site in isolation.
Test coverage — automated tests must cover the critical workflows of all sites. A change to one site could theoretically affect others.
Version management — all sites run the same Drupal version. If one site requires a specific module version, it must be compatible with all others.
Backups and restores — restoring one broken site must not accidentally roll back the others. Ask the hosting provider how database and file restores work in a multisite setup.
Cron and queues — each site may need cron, indexing and queue processing. If cron runs only for one domain, background tasks may silently fail for the others.
Alternative: separate installations
Multisite is not the only way to manage multiple Drupal sites. Separate installations are a simpler solution when:
- Sites update at different times
- Teams are independent
- Functional overlap between sites is small
The downside of separate installations is that security updates must be applied to each site individually — which becomes resource-intensive with a larger number of sites.
Summary
Drupal multisite can reduce duplicated maintenance when several similar sites genuinely benefit from one release cycle. Separate installations are usually clearer when teams, functionality or release schedules need to remain independent.
If you are evaluating whether multisite fits your situation, describe the setup to us — we can help clarify the architectural decision.
Need Drupal help?
If the article describes your situation, you do not have to read everything first. A real person will help you choose the next step.