When one Drupal database should serve several affiliated sites
Domain Access fits a group that runs several branded or regional sites, shares a large part of its content and editors, and wants one codebase and one database to maintain. Typical cases include a membership body with national chapters, a university with faculty sites, or a company with product brands that reuse the same articles and assets. The Domain project on Drupal.org provides the tools for this model: a stable 3.0.1 release that supports Drupal ^10.2 or ^11, and about 12,188 sites that report using it. Domain is a set of contributed modules that extend Drupal, not a separate product. Drupal itself is licensed under GPL-2.0-or-later and has no paid edition, so the licensing cost is zero and the cost of the project sits in design, build, content migration and support.
Domain does not decide the architecture for you. Before you choose it, confirm with the project page which Drupal version your target platform will run, since the supported range is stated as ^10.2 or ^11 and Drupal 12 is scheduled for the week of December 7, 2026 according to the core release schedule. You still have to design the domain list and its ownership, which content is shared across domains and which is local, how each domain gets its own theme, menus, language and settings, and which editors can publish to which domains. Those decisions shape the content model more than the module does, so they belong in discovery, not after launch. Teams that treat Domain as a switch to flip usually discover the gaps in editor permissions and per-domain configuration only after content has already been created.
Check whether a shared database is the right fit before you commit. If the sites need separate release cycles, separate hosting or strict data separation for legal reasons, an independent installation per site or Drupal core multisite may suit better, and the trade-off should be written down against your own requirements. Ask a prospective partner to walk through a worked example of your domain map, editor roles and a sample configuration split, and to show how upgrades will be tested across all domains at once. Those artifacts tell you whether the design has been thought through.
What the Domain suite does on a shared installation
The Domain project lets one Drupal installation and one shared database serve a group of affiliated sites. The capabilities below are what connects those sites: how content is assigned, who can edit it, what can differ per domain, and how URLs are built. Confirm exact sub-module names and behavior against the project page for the version you plan to run.
Content assignment to domains
Each node can be assigned to one or more domains, so a single article can appear on several regional sites or stay on one brand only. Decide early whether shared content is the norm or the exception, because that choice drives the editorial model, the URL structure and how translations or local variants are handled. Check how the module treats content created before assignment rules were set, and how bulk updates behave on large libraries.
Domain-specific editor access
The suite lets you limit which editors can create or change content on which domain, so a regional team cannot publish on a sister brand's site. Map these rules to your real organizational roles before configuring anything, and test edge cases such as users who belong to several domains and content that is shared across them. Confirm with the project documentation which permissions are domain-aware and which fall back to core Drupal roles.
Per-domain settings
Site name, front page, contact details and other settings can be stored separately for each domain, so one installation can present distinct identities. List every setting that must differ before choosing this route, since settings outside the supported set need custom code or a separate site. Confirm which configuration objects are domain-specific and how they interact with configuration export and deployment workflows.
Theming hooks per domain
Domain-aware theming lets a template or stylesheet vary by the domain being served, which is how sites on one database can look different without separate codebases. Keep the variation small and token-based, because each extra branch of theme logic is something your team must test and maintain. Confirm the exact hooks and theme negotiation options in the version you plan to use and check them against your accessibility and brand requirements.
Domain-aware URLs and aliases
Links, path aliases and redirects can be generated for the domain a visitor is on, which keeps navigation and canonical URLs consistent within each brand. Plan the domain list, DNS and TLS certificates together with the web server configuration, since a misconfigured host name can serve the wrong site. Confirm how aliases are scoped per domain and how existing URLs will redirect during a migration.
Choosing between Domain Access, core multisite and separate installs
This table compares Domain Access on one database, Drupal core multisite with separate databases under one codebase, and fully separate installations across content sharing, permissions, upgrades, configuration, hosting and blast radius. Read each row against your own governance and risk tolerance, then use the final row to see which option fits your situation. Costs are not estimated here, so ask any partner to price each option from a written scope.
| Decision factor | Domain Access on one database | Core multisite (one codebase, separate databases) | Separate installations |
|---|---|---|---|
| Content sharing | Content lives in one database and can be assigned to one or more domains, so shared pages and reuse are straightforward | Sharing requires custom integration or syndication between databases, which adds build and maintenance work | Sharing requires syndication or an API connection, such as Entity Share, between independent sites |
| Editor permission model | Roles combine with domain assignment so editors can be limited to specific domains, but the rules need careful testing | Each site has its own users and roles, so editor separation is clean but duplicated across sites | Each site has fully independent users and roles, with no cross-site rules to maintain |
| Upgrade coupling | All domains share one core and module version, so every site moves together and one blocked module can hold back the rest | All sites share one codebase and upgrade together, though databases can be updated in separate steps | Each site can be upgraded on its own schedule, which lets teams move at different speeds |
| Per-site configuration | Settings can differ by domain for theme, language and selected options, but content types and fields are shared across domains | Each site can have its own settings and database, but configuration changes in the shared codebase affect all sites | Full freedom per site, including content types, fields, modules and themes |
| Hosting and operations cost | One application stack and one database to run, monitor and back up | One codebase but multiple databases to back up, monitor and restore, which raises operational overhead | Multiple stacks, databases and deployment pipelines, typically the highest run cost |
| Blast radius of an incident | A faulty deployment, bad module or database problem can affect every domain at once | A codebase fault affects every site, but a database fault is usually limited to one site | Failures are isolated to one site, at the cost of repeating security and patching work |
| Best fit | Affiliated brands or regions that share editorial processes, a common content model and a team that manages all domains | Sites that need separate databases for compliance or data separation but still benefit from one codebase and release cycle | Sites with different owners, regulatory regimes, or release cadences, or where one site must never share infrastructure with another |
How content assignment and editor access work per domain
In Domain Access, every node is assigned to one or more domains through a domain access field, so the first design decision is which content types belong to a single site and which are shared across all of them. Shared types such as legal pages, reusable blocks, taxonomy terms or a common product catalog are usually kept global, while news, offices or regional landing pages are assigned to a specific domain. Write this decision down per content type before building, because changing it later means reassigning existing content. A node can be published to several domains at once, which suits press releases or policies that must appear on every affiliated site, but it also means one edit changes every site it appears on. Confirm with your team which content can legitimately appear everywhere and which must never leak.
The main operational risk is accidental cross-domain publishing, where an editor assigned to one brand saves content that is also visible on another brand's domain. Limit this with a deliberate editor model: decide which roles can assign domains, which can publish to all domains, and which can only edit content already assigned to their own site. Domain Access provides per-domain permissions that you combine with core roles, and it works alongside Content Moderation for review states and, where editors must be restricted by section or hierarchy, Workbench Access. Test each combination with real test accounts on a staging copy: create a node as each role, try to assign it to a foreign domain, try to publish it, and confirm what a reviewer can see in the moderation queue.
Verify these permission combinations against your own setup rather than relying on a general pattern, because the result depends on which Domain, Content Moderation and Workbench Access versions you run together, and on any custom access code in your modules. Document a test matrix with one row per role, content type and domain, and repeat it after every Drupal core or contributed update. Ask your implementation partner or internal team to show the matrix results as part of acceptance testing, and confirm that the Domain release you choose supports your Drupal version (the stable 3.0.1 release lists Drupal ^10.2 or ^11) before the matrix is written.
How a Domain Access build runs from content model to launch
This sequence takes a group of affiliated sites from a shared domain map to a launched, handed-over installation in which each domain's content, editors and settings are tested before go-live. Each step ends with a written output that the next step depends on.
Agree the domain map and content model
The client and DeployOpen define every domain, subdomain and regional site, the owner of each, the languages it serves and which content types are shared or local. The agreed output is a signed-off domain map and a content model document that marks each field as global or domain-specific. Confirm that the sign-off names a decision owner for each brand, because later disputes about shared content usually trace back to this step.
Configure domains and domain-aware fields
The build team installs the Domain suite on a Drupal version the project supports, registers each domain record, and adds domain access and domain source fields to the content types the map marks as domain-specific. Shared fields stay global. The output is a working test environment where content can be created for each domain and its URL, and the field configuration is exported to version control.
Set permissions and editorial workflows
Roles are mapped to domains so that editors can create and publish only on the sites they own, while global administrators can publish across all of them. The team also decides whether review steps use Content Moderation and how shared content is approved before it appears on several domains. The output is a permission matrix listing each role, domain and operation, which the client signs off before any editor account is created.
Configure per-domain settings and theming
Each domain receives its own site name, logo, menus, contact details, analytics identifiers and theme settings, while the shared configuration remains common. The team checks which contributed modules keep per-domain configuration and which need a custom solution, and records that decision. The output is a configuration inventory that shows, for every setting, whether it is global or per domain and where it is stored.
Migrate or create initial content
Content is either created fresh for each domain or moved in from existing sites, with each item assigned to its domain and the correct shared or local status. Migrations are scripted with the core Migrate API so they can be rerun after fixes. The output is a migration log with record counts per domain, a list of rejected rows and the reasons for each rejection, reviewed by the content owners.
Test cross-domain behavior
The team runs scripted and manual tests that check whether a published item appears only on its assigned domains, whether editors are blocked from other domains, whether shared menus, search and feeds show the correct entries, and whether caching respects the domain of the request. The output is a test report that lists each case, its result and any defects with an owner and a retest date. Launch waits until high-severity defects are closed.
Launch and hand over
The team switches DNS and TLS for each domain, confirms redirects from any legacy addresses, and monitors logs and errors through the first production editing cycle. The client's operators receive runbooks for adding a domain, changing permissions, deploying configuration and restoring from backup, and the editors receive training on their domains. The output is a handover pack and a signed acceptance record, and the client should confirm which support arrangement follows.
What can differ per domain and what must stay shared
The split between per-domain and global settings decides how much of the site each affiliate can change without touching the others. Under the Domain suite, the domain record itself, the content assignment that ties nodes to domains, and the domain-aware settings it exposes can vary by domain. In practice this usually covers the active theme for each domain, the menus and blocks placed in each domain's regions, the URL pattern and hostname each brand answers on, and the default language and region for that audience. Before the build starts, list every setting an affiliate will want to change and mark it as per-domain, global or shared with a named owner. Confirm in your own installation which of these the Domain release you select exposes per domain, because the set of domain-aware options depends on the contributed modules you add alongside it.
Settings that must remain global are the ones where drift causes real damage: the core and contributed module set, the shared content types and their field definitions, the text formats and editor configuration, the security-sensitive pieces such as login, password and role policy, and the cron and queue setup. Store these in the exported configuration that lives in version control and deploy it through the same pipeline for every domain. A useful control is a written rule that a domain-level change may not alter a field, permission or module state that other domains read. Per-domain overrides that touch shared configuration should be reviewed as code, not made in the admin interface on production, because the database holds one copy of the configuration and a change made on one brand's pages is visible to all of them.
Upgrades are where the shared codebase pays off and where the risk concentrates. A core or contributed update, a Domain suite upgrade or a change to a shared field lands on every affiliate at the same moment, so the test plan must check each domain's theme, menus, redirects and language settings, not only the default one. Ask your team to confirm how many domains exist, which ones have custom themes, and which contributed modules are domain-aware before estimating upgrade effort. Use the Drupal core release schedule to plan around bugfix and security windows, and keep a per-domain smoke test list that a release owner signs off before deployment. Your own cost and effort will rise with the number of domains that carry bespoke themes and overrides, so ask any partner to price that dimension separately in the written scope.
What drives effort on a Domain Access project
This table lists the factors that most change the scope of a Domain Access build, one row per driver, with the practical way to keep each one under control. Read it before writing a scope, because the number of domains and how much content they share usually matter more than the theme work. Each row is a question to settle with your team before a quote is requested.
| Driver | Why it changes effort | How to keep it down |
|---|---|---|
| Number of domains | Each domain adds domain records, domain-specific settings, URL and language decisions, and another set of pages to check after every change. | Confirm the real list of domains early, and separate brands that need their own look from regions that only need different copy. |
| Degree of content sharing | Content assigned to several domains needs rules for who owns edits, how translations or local variants diverge, and what happens when shared content changes. | Default to shared content with local overrides for a few fields, and document which fields may differ per domain. |
| Number of editor roles | Each role needs permissions scoped to specific domains, and combinations of domain and content type multiply the test cases. | Start with a small set of roles covering publishing, review and administration, then add roles only when an editor group asks for something the set cannot cover. |
| Theming differences | Each domain that looks different needs its own theme or theme settings, and shared components must work across all of them. | Use one base theme with per-domain settings and a shared component library, and limit visual differences to brand elements. |
| Existing content to migrate | Moving content from separate sites into one database means mapping duplicates, URL aliases, media and taxonomy, then checking each domain's output. | Inventory content per site before design starts, remove obsolete pages, and migrate in batches with a sample check per domain. |
| Integrations with CRMs or search | Forms, lead routing and search indexes may need to know which domain a record came from, and each integration needs its own test data per domain. | Agree on one domain identifier passed to every integration, and decide whether one shared search index or several is needed before building. |
| Testing across domains | Every domain needs functional, accessibility and permission checks, and a fix on shared code can affect all domains at once. | Build an automated smoke test list covering each domain, and confirm with the client which domains are release-blocking. |
How Domain Access connects to identity, search and other systems
On one database, every integration sees all domains at once, so identity, search, forms and caching each need a decision about which domain they serve. The cards below cover the integrations that most often need domain-aware design, and the checks to run before you commit to a module set.
Single sign-on across domains
Decide whether all affiliated sites share one identity provider session or whether each domain has its own login and redirect rules. The OpenID Connect module creates accounts on first sign-in, so confirm which domains a newly created user can reach by default and whether roles are assigned from provider claims. The SAML Authentication module, which lets the site act as a SAML service provider, follows the same account-creation questions. Test sign-out on every domain, since a session on one hostname does not automatically end on another. Confirm each module's compatibility with the Domain version in use before you pick one.
Domain-aware search indexes
A search index built on the shared database holds content from every domain unless you add a domain field and filter on it. Plan whether each domain gets its own index, a shared index with a domain filter, or a mix, and check that the search backend returns results only for the current domain. Facets and autocomplete must respect the same filter, or visitors on one domain will see suggestions from another. Confirm the search module versions against the Domain release you plan to run.
Forms and CRM routing
Form submissions often need to reach a different CRM, mailbox or queue for each domain. Decide where the routing rule lives, usually in the form handler configuration tied to the domain, so that a regional form never sends leads to the wrong sales team. Check that submission data stores the originating domain, because reports and retention rules will depend on it. Confirm with each form and CRM connector vendor that it works with the domain-based setup you choose.
Caching and CDN purging by domain
Cache entries for shared content can be served under the wrong hostname if cache keys ignore the domain. Verify that page caches and reverse proxies vary by host, and that purge requests triggered by an edit on one domain clear only the URLs that domain serves, unless a shared item must update everywhere. Test a purge on a staging CDN before launch, and confirm how your CDN handles per-hostname cache rules and tag-based purging.
Shared storage and media
Uploaded files and media sit in one file system and often one object storage bucket, so a file attached to a domain-specific page is reachable from any hostname that knows its URL. Decide whether assets are shared across domains or kept per brand, and whether public file URLs need access checks. Review image styles and derivatives, which are generated once and reused. Confirm that your storage module handles the Domain version you run.
Upgrade coupling with the Drupal core
Every integration module added to a shared installation shares its upgrade cycle with every affiliated site. Drupal 10 reaches end of life on December 9, 2026, and Drupal 12 is scheduled for the week of December 7, 2026, so the upgrade window for the whole estate must fit those dates. Plan one compatibility matrix covering core, Domain, each integration module and the PHP version, and test the set together on staging before any domain is moved.
Questions teams ask before running several sites on one Drupal database
What drives the cost of running several sites on one Drupal database?
The cost is driven mainly by how many domains you run, how different they are from each other, and how much of the editorial and permission model has to be designed before the build starts. Each domain adds configuration work for its own branding, menus, homepage, URL patterns and content assignments, and each distinct editor group adds permission and workflow design. Costs fall into one-time work (architecture, content model, migration of existing sites, theming, testing) and recurring work (updates, monitoring, backups, support). Ask any quote to split those two groups, list each domain and editor role in scope, and state which third-party modules and hosting components are included.
How long does a Domain Access project take?
Duration depends on the number of domains, whether existing sites must be merged or migrated, how much content is shared versus local, and how many editor roles need separate rules. Teams with an unclear content model or unresolved branding usually spend the most time before any build begins, so decisions about domains, content ownership and permissions should be settled in writing first. Because most engagements are fixed-scope, ask for a timeline tied to named deliverables and to the decisions your organization must make, and confirm which dependencies (approvals, content migration, hosting access) sit on your side.
What does the work need from our team?
The work needs named owners who can decide on brand rules, domain list, content ownership and editorial roles, because those decisions shape the configuration. You will also need access to your existing sites and their content, a hosting environment where the team can deploy, and a point of contact who approves designs and test results. Legal or compliance reviewers should confirm privacy notices and cookie handling for each domain. Ask the partner to list these inputs in the written scope so gaps show up before the schedule slips.
Can our internal team run Domain Access without a partner?
An internal team with strong Drupal experience can build a Domain Access setup, especially for a small number of closely related sites. The hard parts are usually not the module installation but the design choices that are costly to reverse: how content is assigned to domains, how editors are restricted, how configuration is kept per domain, and how upgrades are tested across every domain at once. If your team has not run a multi-domain installation before, consider a fixed-scope review of the design before build, or a partner for the first release. Be realistic about ongoing capacity, because every domain must be updated and checked on the same schedule as core.
Does Domain Access work with Drupal core multisite?
Domain Access and core multisite solve related but different problems, so the choice depends on how separate the sites need to be. Domain Access runs several branded or regional sites from one installation and one shared database, with content and configuration assigned to each domain. Core multisite gives each site its own settings and database tables under a shared codebase, which suits stronger separation between sites. The Domain project is built for the first pattern and is not a substitute for core multisite when sites need separate databases, separate administration or separate release cycles. Confirm the isolation requirements, data residency rules and editor access model before choosing, and ask the partner to document why the chosen approach fits.
How do Drupal core upgrades affect every domain?
Because all domains share one installation, a core or contributed module upgrade changes every site at once. Plan for a single test environment that covers each domain's theme, content assignments, and permission rules before release. Core security releases follow a published schedule, with bugfix releases on the first Wednesday of each month and security releases on the third Wednesday, so your operations team should budget time for those dates. Major versions arrive about every three years, and Drupal 10 reaches end of life on December 9, 2026, so check which major version your installation runs and whether your Domain release supports the target. Ask any quote how upgrades are tested per domain and who signs off on each release.
Which Drupal and PHP versions does Domain Access support?
The Domain project's stable 3.0.1 release supports Drupal ^10.2 or ^11, so a new build should target a supported major version rather than an older one. Drupal 10 requires PHP 8.1 or later, Drupal 11 requires PHP 8.3 or later and Drupal 12 requires PHP 8.5 or later. Drupal 12 is scheduled for the week of December 7, 2026, so confirm whether the Domain release you choose has announced support for it before planning a longer-lived installation. Drupal 7 security support ended on January 5, 2025, so any legacy multi-site estate on that version needs a migration plan first, and sites that cannot migrate yet can review the extended security support partners listed on Drupal.org.
How DeployOpen scopes and delivers a Domain Access implementation
DeployOpen plans, builds, documents and supports Drupal Domain Access setups inside infrastructure you control. We start with a written scope covering the affiliated sites, their content ownership, editor roles and per-domain configuration, so the engagement stays fixed in scope before build work begins. Ongoing support is available as a retainer after handover.
How we scope
- Inventory every affiliated site, its domain names, languages and the content each one needs to own or share.
- Map which editors act on which domains and which roles can publish across domains or edit shared content.
- Agree in writing which settings stay global and which vary per domain, so the boundary is explicit before build starts.
How we build
- Install the Domain suite on a supported Drupal release and set up domain records, aliases and per-domain theme selection.
- Configure content assignment, domain access permissions and per-domain configuration, then test each affiliated site against the written scope.
- Verify routing, caching and URL generation across domains on your web server, database and hosting platform before go-live.
How we hand over
- Deliver configuration exported for version control, with a record of domain settings, roles and the reasons behind each choice.
- Document editor onboarding, the steps to add a new affiliated domain and the checks to run after each change.
- Walk your platform, editorial and security teams through the runbook so they can operate the site without us.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer, scoped in writing after handover.
- Plan Drupal core and Domain module upgrades around the published release schedule and check module compatibility each time.
- Ask any partner quote to itemize scoping, build, testing, handover and retainer work so you can compare it with your own team's effort.
