iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Need a server to try this on? Antihost offers Linux VPS plans with NVMe storage, full root access and a 14-day free trial.
Use Drupal multisite when you need several independent websites to share one Drupal codebase. Each site gets its own configuration directory, settings.php, database and files, while every web-server virtual host points to the same Drupal document root. Drupal selects the correct site from the incoming host and path through sites/sites.php aliases and its normal hostname discovery.
This arrangement reduces duplicated code and centralizes updates, but it also couples every site to the same code and deployment. The steps below show how to build the layout, route domains safely, isolate data and operate the group without confusing one site for another.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
What Drupal multisite means
Drupal multisite is one Drupal installation serving several separate sites. “Installation” here means the shared Drupal core, contributed modules, themes and document root. A multisite does not mean that all sites share content or a login by default.
Drupal’s official installation documentation describes the model as a single installation hosting several Drupal-powered sites, each with its own individual configuration. Its multisite overview specifies that each site has its own database, configuration, files and base domain or URL.
#1 Best Overall
- Shared: the Drupal codebase and normally common modules and themes.
- Separate: each site’s
settings.php, database, public files, private files and configuration values. - Routed: the web server sends every site hostname to the same document root; Drupal then chooses the site directory.
The result is appropriate for genuinely independent sites that happen to be maintained together. If the sites must share a content model, users or domain-aware permissions, a single Drupal site with a domain-routing solution may fit better than core multisite.
Decide whether multisite fits your requirements
Choose multisite for independent sites
Multisite is a good boundary when each site should have its own database and administration, and an error or content change on one site should not automatically alter another site’s content. The sites can use different domains, subdomains or URL paths, provided the web server and Drupal routing are configured for each one.
Do these 3 things before closing this tab:
1Scan for outdated or missing drivers - takes under a minute2Repair Windows errors before they cause bigger problems3Fix the driver behind crashes, sound loss and screen glitchesUse one domain-aware site for shared content
Core multisite does not provide shared content, shared users or single sign-on merely because the code is shared. If editors need one content model across several domains, or permissions must be aware of domains inside one content store, evaluate a single Drupal site using the Domain Access project or another domain-routing architecture. Keep the decision explicit: separate databases create separation, while a single site creates intentional sharing.
Accept the shared-code trade-off
A common codebase means one update can be applied once instead of being repeated for every site. It also means a faulty code or dependency change can affect every site at the same time. Treat the group as one deployment portfolio: schedule maintenance windows, test changes against every site, back up all databases and files, and keep a rollback procedure that can restore the whole set.
Architecture: what lives where
| Layer | Typical location or responsibility | Isolation rule |
|---|---|---|
| Drupal core and shared extensions | The common Drupal document root | All sites run the same checked-out code and dependency set. |
| Site directory | sites/site1.example.com, or another directory named for the site |
Contains that site’s settings.php and site-specific files. |
| Database | The connection defined by that site’s $databases array |
Use a separate database for each independent site unless you deliberately document table-prefix coupling. |
| Public and private files | Inside each site’s directory, using that site’s file settings | Keep uploads separated so one site cannot accidentally expose or mix another site’s files. |
| Web server | Apache, Nginx or another supported server | Every virtual host points to the shared Drupal root, never to an individual sites/ subdirectory. |
| Site selection | sites/sites.php plus hostname/path discovery |
Aliases must resolve each incoming host to the intended configuration directory. |
Common modules and themes can stay in shared locations. A site that needs a local extension can place site-specific modules or themes in its own directory, while the shared set remains available to all sites.
Prerequisites and planning
- A supported Drupal version installed in a document root that all sites will share.
- A DNS record for every domain or subdomain, resolving to the server that hosts the Drupal code.
- A virtual host or server block for every hostname, all targeting the same Drupal document root.
- A database and database credentials for each site, with a default connection defined in each site’s settings.
- Filesystem permissions that allow Drupal to read the code and write each site’s required files directory without granting one site unnecessary access to another.
- A naming convention for site directories, databases, backups and deployment records.
- A plan for cron, cache clearing, logging, updates and rollback across the entire portfolio.
Decide the canonical hostname for each site before installation. A hostname used during development can differ from production, but the alias mechanism must account for that difference. Also decide whether a site will be reached by a separate domain, a subdomain or a path such as sub.example.com/site3; Drupal’s candidate-directory rules depend on the incoming host and path.
PC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Outdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchSet up the first shared Drupal installation
1. Install Drupal in the shared document root
Install a supported Drupal release in the directory that will serve every site. Configure the initial site and its web-server virtual host first. The virtual host’s document root is the Drupal codebase itself, not a site-specific directory under sites/.
2. Verify the root site before adding another
Confirm that the first hostname reaches Drupal, that its database connection works and that its public and private files locations are writable as intended. A clean baseline makes later host-routing problems easier to distinguish from installation problems.
Add each additional site
1. Create the site directory
For a site named site1.example.com, create a directory such as:
sites/site1.example.comThe directory name is the configuration directory Drupal will use after host mapping. Use a consistent convention for every additional site.
The Tool Desk
Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →2. Create a separate database
Create a database for the new site and record its database name, user, password, host and any required connection options. Separate databases provide the clearest isolation: a content change, schema update or database restore is scoped to one site.
Drupal can also use table prefixes when several sites share one database. That approach increases operational coupling: backups, restores, permissions and schema work must account for every prefix. Use it only when there is a specific reason, and document the prefix-to-site mapping.
3. Create the alias file
Copy sites/example.sites.php to sites/sites.php. Add an alias that maps the incoming hostname to the new configuration directory:
$sites['site1.example.com'] = 'site1.example.com';The $sites array is an associative map from <port>.<domain>.<path> patterns to configuration directories. It is especially useful when a development hostname differs from production, because multiple incoming patterns can point to the same directory.
4. Configure the virtual host or server block
Add the new domain or subdomain to Apache, Nginx or your supported web server. Point its document root to the shared Drupal root. Do not point it at sites/site1.example.com; that directory contains configuration and files, not a separate Drupal web root.
If several names should reach the same site, configure them as aliases at the web-server level and decide which one is canonical for redirects, cookies and links.
5. Create site-specific settings
Copy sites/default/default.settings.php into the new directory as settings.php:
sites/site1.example.com/settings.phpSet that file’s $databases array to the new database. Every site needs a default database connection. Set the site’s files paths and other site-specific settings there rather than editing the shared codebase.
6. Configure trusted hosts
In each relevant settings.php, configure $settings['trusted_host_patterns'] to allow every legitimate hostname for that site. Patterns should be precise enough to reject unexpected Host headers. For example, a site that legitimately answers for the bare and www names can use:
$settings['trusted_host_patterns'] = [
'^example\.com$',
'^www\.example\.com$',
];Use the actual names assigned to the site, not a broad pattern that accepts arbitrary domains. Also configure the web server’s default response for requests sent to an unintended host, so an unknown hostname does not accidentally display one of the real sites.
7. Run the installer for the new hostname
Visit the new hostname. Drupal should select the new directory and present the installation process using its database settings. Complete the installer for that site. If the wrong site appears, use the official installation endpoint at /core/install.php after correcting the host mapping and settings file.
8. Repeat the complete unit
For every additional site, repeat the directory, database, alias, virtual-host, settings and installation steps. Do not reuse a site’s database or files directory unless shared data is an intentional part of a different architecture.
How Drupal selects the configuration directory
Drupal first considers the incoming port, domain and path. The sites/sites.php alias file can map a matching pattern directly to a configuration directory. This lets a development address and a production address use the same settings directory without renaming the directory itself.
When no alias matches, Drupal derives candidate directories from the incoming hostname and path. It uses the first candidate that contains a settings.php. If no candidate is found, Drupal falls back to sites/default.
Rank #4
That fallback is convenient for the original site but dangerous in a growing multisite installation: a missing alias, incorrectly named directory or absent settings file can make a new hostname load the default site. Test each hostname explicitly and treat an unexpected default-site response as a routing or configuration error, not as a successful installation.
Database, files and configuration boundaries
Databases
Put each site’s connection details in its own settings.php. Separate databases simplify selective backups, restores, migrations and access control. They also make the independence of the sites visible to everyone operating the system.
Public and private files
Keep every site’s public and private files in that site’s directory. Separate file roots prevent uploads from being mixed and make it possible to back up or restore one site without silently including another site’s assets. Verify permissions after deployment and after restoring a backup; the web process must be able to use the intended directories, while unrelated site directories should not be writable by it without a clear reason.
Configuration
Drupal configuration stored in a site’s database is independent from the other sites when the databases are separate. Shared code does not make configuration changes portable automatically. Use a deployment process that identifies which site is being exported, imported or rebuilt, and never apply one site’s configuration to every database by accident.
Web-server, DNS and security checks
- Create or update DNS for every hostname and wait until it resolves to the intended server.
- Configure a virtual host or server block whose document root is the shared Drupal root.
- Confirm that the server does not expose a site directory as an independent web root.
- Add the host alias in
sites/sites.phpwhen the hostname needs explicit mapping. - Ensure the corresponding
settings.phpexists and contains the correct database connection. - Add every legitimate hostname to that site’s trusted-host patterns.
- Configure a safe default response for unknown or unintended hosts.
- Request each hostname over the intended protocol and verify that the expected site, files path and administrative login appear.
Trusted-host configuration is not optional polish. Without it, an unexpected host header can produce incorrect links or expose a site through a hostname you did not intend to serve. Keep the patterns synchronized with DNS and virtual-host changes.
Operating a shared codebase safely
Updates
Core, contributed modules and shared themes are updated in the common codebase. A dependency change that is correct for one site may still affect every other site, so test the full portfolio before deployment. Include database updates and cache behavior in the test plan, not just whether the front page loads.
Quick wins for a faster PC:
Clear out junk files and repair common Windows errorsFree Scan →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Site-specific extensions
Keep common modules and themes in shared locations. If one site needs a local extension, place it in that site’s directory and record the exception in deployment documentation. This limits unnecessary code exposure to other sites while preserving one common base.
Backups and rollback
Back up every site database and its public and private files, along with the shared code version and deployment configuration. A code rollback without matching database and file backups may leave sites in an incompatible state. Define whether recovery is per site or portfolio-wide and test restoration rather than assuming that a successful backup job is sufficient.
Best Value
Cron, caches and logs
Design cron execution, cache clearing and logging for multiple sites. Jobs must run with the correct site context; cache operations should not erase or rebuild the wrong site’s data; logs should identify the hostname or site directory. Automation that works for one site can become destructive when copied unchanged across the group.
Permissions and deployment automation
Use a repeatable deployment process that knows which directories are shared and which belong to an individual site. Review permissions after every code release and file migration. Keep credentials in the appropriate settings files or secret-management system rather than copying one site’s credentials into another site’s configuration.
Free tools Windows power users keep installed
One-click scans. No signup required.
Multisite versus one domain-routed Drupal site
| Decision axis | Core multisite | One site with domain routing |
|---|---|---|
| Database and content isolation | Normally a separate database and independent content for each site. | One database and a shared content model with domain-aware behavior. |
| Users and authentication | Separate by default; shared login is not supplied by core multisite. | Can use one user system when the chosen architecture supports it. |
| Upgrade independence | Sites share the same code and are coupled to the same core and dependency updates. | One codebase and one application are upgraded together, with domain behavior managed inside that site. |
| Filesystem and backup boundaries | Each site can have its own files and database backup boundary. | Content and operational boundaries are shared unless deliberately separated. |
| Domain and URL requirements | Each host or path must resolve to the shared root and map to the correct configuration directory. | Hosts route into one Drupal site, where domain-aware modules determine what users see. |
| Failure and deployment impact | A shared code failure or deployment can affect every independent site. | A failure affects the one application, while domain-specific configuration can still introduce broad impact. |
Choose the model from the data boundary, not from the number of domains. Separate databases are valuable when sites must be independently restored or administered. A shared content model is valuable when editors, users and permissions cross domain lines.
Troubleshooting common failures
The new hostname shows the default site
- Check that the request reaches the intended virtual host and that its document root is the shared Drupal root.
- Verify the hostname spelling in
sites/sites.php. - Confirm that the alias points to the directory containing
settings.php. - Check DNS and any proxy or load-balancer host forwarding.
- Look for a missing or unreadable settings file; if no candidate matches, Drupal falls back to
sites/default.
Drupal reports a trusted-host error
The requested hostname is not allowed by $settings['trusted_host_patterns']. Add the exact legitimate domain or subdomain to the appropriate site’s settings file, then verify that the web server is not forwarding an unexpected host header.
The installer connects to the wrong database
Open the selected site’s settings.php and inspect its $databases['default'] connection. Confirm that the alias selected the intended directory and that credentials were not copied from another site. Do not solve the symptom by changing the shared codebase.
Uploads appear on another site
Inspect public and private files paths in the affected site’s settings and verify that the web process has access only to the intended directories. A shared files path defeats the isolation you created with separate databases.
Recommended Free Tools
One site breaks after a common update
Treat the event as a portfolio deployment incident. Check the shared dependency or module change against every site, review database-update status and use the documented rollback plan with matching code, database and file backups.
A site works by IP address but not by its domain
Check DNS, the virtual-host name, TLS or proxy forwarding and the host alias. Drupal’s site selection depends on the incoming hostname and path, so an IP-based request may not select the same configuration directory as the production domain.
Pre-launch checklist
- Every hostname resolves to the correct server.
- Every virtual host points to the shared Drupal document root.
- Each site has a uniquely named directory and readable
settings.php. - Each site’s
$databases['default']connection points to the intended database. sites/sites.phpcontains the required host and path aliases.- Public and private files are separated by site and have tested permissions.
- Trusted-host patterns include all legitimate names and reject unintended hosts.
- Unknown-host behavior is configured at the web server.
- Every site has been installed and tested through its real hostname.
- Backups include the shared code version, every database and every site’s files.
- Update, cron, cache, logging and rollback procedures identify the site context.
- Owners understand that shared code couples maintenance and outage risk across the portfolio.
When to add another site or change architecture
Add a site to the multisite installation when it needs an independent database, files, configuration and administration but can accept the common code lifecycle. Reconsider the design when teams require shared users, shared content, cross-domain workflows or independent upgrade schedules. Those requirements point toward either a deliberately integrated single site or separate Drupal installations with their own codebases, rather than adding more directories to a tightly coupled multisite.
The practical test is operational: can you name the database, files directory, trusted hosts, backup set and rollback procedure for each site, while also testing one shared code release across all of them? If yes, Drupal multisite provides a clear and efficient structure. If not, the apparent code savings may cost more in incidents and deployment complexity than separate installations would.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
