Drupal multisite runs multiple independent sites from one shared codebase, and it fits best when those sites can stay similar and release together. Separate Drupal installations fit best when sites need different features, versions, or deploy schedules. Each multisite member keeps its own database, configuration, files, and domain or URL. The practical trade is governance against autonomy: shared code saves repeat work, while separate code preserves independent control.
Table of Contents
- How does multisite keep sites separate?
- What does adding another site require?
- When does multisite save maintenance effort?
- When do separate sites justify the extra work?
How does multisite keep sites separate?
According to the Drupal.org Wiki guide, multisite shares Drupal core, contributed modules, and themes across sites while giving each site its own database, configuration, files, and base domain or URL shared multisite code base. That split lets teams reuse functionality without mixing content or settings.
According to Acquia Product Documentation, incoming requests reach the right site through alias rules in sites/sites.php, which maps each domain or domain-plus-path to a site folder and settings file. A visitor sees a normal independent site. Developers maintain one document root behind those addresses.
What does adding another site require?
According to the Drupal.org setup guide, each new site needs its own database, settings file, files directory, hosting entries, and routing entry multisite setup steps. The work is routine, but every piece must be present.
- Create and connect a separate database for the new site
- Copy default settings to sites/[name]/settings.php and adjust it
- Create the site files directory with correct permissions
- Point DNS and virtual hosts at the shared document root
- Add the domain mapping in sites.php
When does multisite save maintenance effort?
According to arocom, one core, module, or security update to the shared codebase applies to all member sites at once multisite maintenance analysis. Teams avoid patching many installations one by one. Routine upkeep becomes faster and more consistent.
The saving is largest for structurally similar sites. Think brand sites, country subsidiaries, or branch sites with the same design system, modules, and content types but different content and domains. Central ownership keeps that shared structure stable.
When do separate sites justify the extra work?
According to Acquia Product Documentation, multisite multiplies the blast radius because one bad update, misconfiguration, or compromised site can affect every site on the installation multisite risk documentation. Separate codebases isolate that risk. They also let one site change without forcing change on the rest.
Shared code also forces coupled releases. According to arocom, all sites must run compatible versions from the same lock file and cannot stay on different core versions. Each site still needs its own database updates and configuration handling after deployment. Choose multisite only when one team can coordinate testing and simultaneous releases.
