Extra Block Types (EBT) - New Layout Builder experience❗

Extra Block Types (EBT) - styled, customizable block types: Slideshows, Tabs, Cards, Accordions and many others. Built-in settings for background, DOM Box, javascript plugins. Experience the future of layout building today.

Demo EBT modules Download EBT modules

❗Extra Paragraph Types (EPT) - New Paragraphs experience

Extra Paragraph Types (EPT) - analogical paragraph based set of modules.

Demo EPT modules Download EPT modules

Scroll

Multisite Drupal 8 - overview

14/04/2025, by Ivan

The primary reason to use a Drupal multisite setup is to save time when managing multiple Drupal sites running the same core version. Every time a new core update is released, you only need to update one codebase instead of each individual site. However, there are drawbacks. These can be mitigated if you use the Aegir hosting system.

Otherwise, the complexities and potential issues of managing a multisite manually require fairly advanced technical skills. Users at this level are typically familiar with the command line, and from the command line, you can update each site in under two minutes. With Aegir, it’s even faster, as all sites can be queued for updates using a point-and-click interface, upgrading the entire platform (Aegir's term for the shared codebase) to a newer one. Any sites that fail will automatically roll back.

Multisite Basics

While a Drupal site requires a web server (like Apache or IIS), a database system (like MySQL or MSSQL), and a PHP interpreter, everything unique to your site is stored in your database and codebase.

Updating Drupal core essentially means replacing the codebase. The database remains unchanged, except that after replacing the code, you need to run the update script [YOURSITE/update.php] for each site.

Reasons to Use One Database per Site

Databases run in the background and are managed by the codebase. Typically, you’ll never have to worry about them directly.

Trying to use one shared database for multiple sites has little benefit—if any. The small disk space savings are vastly outweighed by the potential problems.

  • If data on one site is accidentally or maliciously corrupted, all sites could be affected.
  • A database is made up of many tables. If you later want to extract one site from the multisite setup, it’s difficult to determine which tables belong to which site and which are shared.

One Codebase per Site

Theoretically, sharing one codebase across all your Drupal sites would save time and disk space.

Disk space is cheap, so let’s set that aside.

As mentioned above, updating each Drupal site after a core release can take just minutes via the command line. It’s more worthwhile to learn that skill than to wrestle with implementing and troubleshooting a multisite configuration.

Sharing a codebase is most useful when all your sites use the same modules and configurations—for example, if you're managing separate but similar websites for every team in a sports league.

However, if the sites you manage use different modules, a bug in a module used by just one site could break all sites.

Setting Up Drupal 8 Multisite

If you want to configure Drupal sites in a multisite setup, get started here.

Drupal’s online documentation is © 2000-2020 by the individual contributors and can be used in accordance with the Creative Commons License, Attribution-ShareAlike 2.0. PHP code is distributed under the GNU General Public License.