Drupal 11 site factory: which architecture should you choose for your site?

A Drupal "site factory" aims to industrialize the creation, maintenance, and deployment of multiple websites on a common technical foundation. The objectives are governance (consistency), rapid deployment, and efficient maintenance (security).

With Drupal 11, which is entirely based on Composer, the most modern versions of PHP and advanced configuration management, the "old" methods have been refined.

Here are the different solutions and approaches to building a site factory with Drupal 11.

Native multisite architecture: the historical approach for homogeneous fleets

This is Drupal 's historical approach , still present in the Core .

Concept: a single Drupal codebase (a single composer.json , a single core folder , modules, themes ) serves an unlimited number of sites.

Technical operation:

• The sites / folder contains a subfolder for each site (e.g., sites/site1.com, sites/site2.fr).
• The sites/sites.php file links (mapping) a domain name (URL) to the corresponding site folder.
• Each site has its own database and its own files folder .
• All sites share exactly the same code (identical module versions). However, it is possible to override each site with code elements specific to a particular instance.

Benefits :

• Maximum centralization: a single security update (a composer update) updates all sites at once.
• Very fast for "cloning" a new basic website.

Significant drawbacks:

• Fragile monolith: a failed update (e.g., a bug in a module) breaks all sites simultaneously.
• Lack of flexibility: it's impossible to have different module versions. If "Site A" needs module X v1.0 and "Site B" needs module X v2.0, it's impossible.
• Configuration management (see point 4) becomes complex when dealing with variations between sites.

The "distribution" approach (installation profile)

This is the most robust "modern" approach, aligned with the Composer philosophy .

Concept: you don't manage a single codebase, but a website "template" . Each site is an independent project, but all are derived from this template.

Technical operation:

• You create a Drupal installation profile (a "distribution").
• This profile contains the theme, default modules and, most importantly, the default configuration (exported to config/sync).
• Creating a new site is done via a command: composer create-project my-company/site-factory new-site.
• Each site is then a complete and independent Drupal 11 project (its own composer.json, its own Git repository, etc).
• This functionality is further enhanced by the Recipes system.   which allows the full power of an installation profile to be deployed even on sites already in operation.

Benefits :

• Perfect isolation: each site is autonomous. A site that crashes does not affect any other.
• Flexibility: a site can decide not to make an update, or to add a specific module that is not in the common core, without affecting the factory.
• Maintenance: Updates to the "common core" are pushed to the profile. Sites simply need to run `composer update my-company/site-factory` to retrieve the new features.

Disadvantages:

• Decentralized maintenance: updating 100 sites means running the update 100 times (but easily scriptable via CI/CD).

"Monorepo" approach (management via "composer")

It is a powerful hybrid, often used by agencies and PaaS platforms.

Concept: a   The only Git repository (Monorepo) contains the common code, but uses advanced Composer mechanisms to handle variations.

Technical operation:

• There is a composer.json file at the root that defines the Drupal 11 core .
• Each site (or "family" of sites) may have its own additional composer.json, or the repository uses scripts to build different deployment "artifacts".

Benefits :

• Balance between code centralization (a single Git repository) and deployment flexibility.
• Perfectly suited for CI/CD pipelines (GitLab CI, GitHub Actions).

Disadvantages:

• Technical complexity: requires excellent mastery of Composer and deployment tools.

Essential module: “Config Split”

Regardless of the approach chosen (especially 1 and 3), one module is vital: Config Split .

In a website factory, 90% of the configuration is identical (content types, fields). However, there are variations:

• "Site A" (e-commerce) has the commerce module activated.
• "Site B" (blog) does not have it.
• "Site C" (intranet) has an ldap module enabled.

Config Split allows you to define "conditional" configuration sets . It "splits" (separates) the original configuration from the optional configurations.

You have a config/sync database, then:

• config/split/ecommerce (contains the Commerce module configuration)
• config/split/intranet (contains the LDAP config)

Depending on the site, you activate the corresponding "split". This is the number one governance tool in a site factory.

Turnkey PaaS platforms

Finally, there is the solution of outsourcing the complexity of the infrastructure.

Concept: you use a specialized service that has already built all the infrastructure (servers, Git, deployment) optimized for Drupal multisite.

Example: Acquia Site Factory: the long-standing and most integrated solution. It's a low-code interface for cloning established sites based on profiles you define. It handles bulk updates.

Benefits :

• Abstract the complexity: you focus on Drupal, not on servers or pipelines.
• Rapid deployment and high availability guaranteed.
• Powerful site, code, and database replication capabilities

Disadvantages:

• Cost: these PaaS services are logically more expensive than traditional hosting.
• Vendor lock-in: you are tied to the platform's technology even if it remains based on a market standard.

Summary of approaches

Recommendation for Drupal 11: For a sovereign and robust site factory, approach nᵒ 2 (Distribution / Installation Profile) , combined with the Config Split module and automated by a CI/CD , is the modern "best practice".

Conclusion

Streamlining and industrializing your web platform is becoming essential in digital marketing. You gain greater autonomy and can generate your own websites (product launches, events, new campaigns, etc.) with a focus on time to market. The Smile Drupal teams work with you to analyze your strategic needs and implement the best website factory architecture to optimize your costs and boost your communication and marketing operations.