Umbraco multi-site architecture: running several brand or regional sites on one installation

An Umbraco multi-site setup runs several websites from one installation by giving each site its own root node in the content tree and binding its domains to that node under Culture and Hostnames. Umbraco’s documentation puts it simply: each root node acts as a separate website. All sites share one database, one codebase and one set of document types, which is exactly what makes multi-site cheap to run and also what limits it.

This guide is for teams running several brand, product or regional sites who want to decide how to structure them in Umbraco. It covers root nodes and hostnames, languages, shared versus site-specific content, per-site permissions, forms and integrations, and when to split into separate installations or go headless. The examples come from three of our projects: the Alliant insurance sites, the Omoda Denmark headless build and the Ben-Gurion University platform.

How Umbraco multi-site works

Root nodes and hostnames

The basic structure is a set of root nodes at the top of the content tree, one per site:

Content
├── Brand A            (brand-a.com, en-US)
├── Brand B            (brand-b.com, en-US; brand-b.dk, da-DK)
├── Regional: Nordics  (example.com/dk, da-DK; example.com/se, sv-SE)
└── Shared library     (no hostname, not routable)

For each root node you open Culture and Hostnames, add one or more domains and pick a language for each. A few routing rules from the Umbraco outbound pipeline docs are worth knowing before you design the tree:

• Any node with a hostname starts a new site. Its descendants get URLs relative to that domain.
• Domains can include a path. www.site.com/dk is a valid domain, which lets several regional sites share one hostname.
• Root nodes without hostnames can collide. If several root nodes have no domain, two pages can end up with the same URL, and Umbraco returns an error placeholder instead of a link. Give every routable root a domain.
• Cross-site links become absolute. When a page links to content in another site, Umbraco builds an absolute URL using that site’s domain. The ISiteDomainMapper decides which domain to use when the target has several, and the default mapper can group related domains so editors see only relevant URLs.

On Umbraco Cloud, hostnames are added in the Cloud portal first so they get TLS certificates, then mapped to root nodes in the back office.

Languages and cultures

Languages are defined once for the whole installation. Each site then picks the cultures it uses through its hostnames. That gives you several patterns:

Use variant document types (content that varies by culture) when the same page exists in several languages and should stay linked. Use separate root nodes when regions publish different content, not just translations. Mixing both in one tree is possible but makes permissions and navigation harder to reason about.

Shared versus site-specific content

The biggest design decision is what is shared. A useful split:

• Shared code: document types, element types, block components, views and services. This is where multi-site pays off: one component library, many sites.
• Shared content: a non-routable “library” root for things like office locations, legal text, team profiles or product data that several sites reference through pickers.
• Site-specific content: pages, navigation, site settings (logo, colors, analytics IDs, footer) and anything a single brand owns.

Practical rules we follow:

1. Put site settings on the root node or a settings child of it, and resolve them by walking up from the current page. Never hard-code a site in a view.
2. Use composition document types for shared groups of fields (SEO, social, header options) so every site gets them consistently.
3. Theme with settings, not forks. Brand differences such as colors, logos and layout variants belong in site settings and block settings. If two brands need genuinely different templates, that is a signal to consider a different front end, covered below.
4. Keep the shared library small. Every shared item is a dependency between sites; editors of one brand can affect another.

Umbraco’s multisite tutorial lists the trade-offs plainly: one project can increase resource usage, editors on different sites still work in one shared database, and it limits options for developing new features and making schema changes, because a change to a document type changes it for every site.

Example: Alliant, one modular codebase for a family of sites

Alliant, a large US insurance brokerage, had several related sites on an outdated stack, each handled on its own, with editors relying on developers to publish. We rebuilt the estate on current Umbraco with a modular architecture: custom Umbraco packages and shared components hold the logic every site needs, and new sites plug into the same structure and reuse its components without duplicating logic. The result is that multiple websites are managed in one system and new projects launch on the existing architecture without major rework. Details are in the Alliant case study.

Permissions per site

In a multi-site installation, permissions do the work that separate installations would otherwise do. Umbraco gives you several layers, documented under Users:

• User groups carry permissions; users get them through group membership.
• Content and media start nodes limit which part of the tree a user sees. Point a brand’s editor group at that brand’s root node and media folder.
• Granular permissions assign rights on specific documents, for example letting a group publish only one section.
• Language access on a user group limits which languages its members can edit, useful for regional translators.
• Property permissions can restrict read and write access to individual properties on a document type in current versions.

A typical setup is one editor group and one publisher group per site, plus a small central group for shared content and settings. Keep the number of groups manageable by naming them consistently (for example BrandA Editors, BrandA Publishers).

Example: Ben-Gurion University, scoped access for about 1,000 editors

Ben-Gurion University’s Umbraco site holds about 80,000 pages and is edited by around 1,000 people. It includes an Organizational Units subsystem in which each unit runs its own content. With that many editors, safe access was a core requirement: custom access control limits each editor to specific pages and their children, on top of a library of 100+ reusable components. The same platform handles daily imports of 15,000+ staff profiles and peaks of around 300 requests per second. The Ben-Gurion University case study covers the search, caching and AWS migration.

The lesson for large multi-unit setups: out-of-the-box start nodes are the starting point, but when the organization chart does not match the content tree neatly, plan for custom access rules early rather than restructuring content later.

Forms and integrations per site

Forms and integrations are where multi-site setups often leak between brands.

Umbraco Forms has its own security model, separate from content permissions. You can grant per-user or per-group rights (manage forms, view or edit entries, manage workflows), allow or deny access to individual forms, and set start folders so a brand’s editors only see that brand’s form folder. Set ManageSecurityWithUserGroups to true to manage this by group, and consider setting DefaultUserAccessToNewForms to deny so new forms are not visible to every editor by default.

For integrations, the pattern that scales is configuration per site, code shared:

• Store per-site values (CRM list IDs, analytics keys, consent settings, recipient addresses) on the site settings node or in configuration keyed by site.
• Write one Forms workflow or one integration service that reads those values from the current site.
• Keep secrets in configuration or a vault, not in content.

On Alliant, custom Umbraco Forms workflows send submissions straight to Eloqua, so campaign forms no longer need extra setup each time, and editors sign in to the back office through Okta SSO in line with Alliant’s identity setup. Hosting runs on Azure with Azure Load Balancer, media in Azure Blob Storage, releases through Azure CI/CD pipelines and Datadog monitoring in production. For integration work like this, see our integrations service.

When to split into separate installations

One installation is not always the right answer. Consider separate Umbraco installations when:

A middle path is several installations built from one shared set of NuGet packages for components and integrations. That keeps code reuse without sharing a database. Umbraco Cloud’s documentation also suggests Baselines for this situation, where child projects inherit from a parent project.

When to go headless

Going headless with Umbraco means editors keep the back office while one or more front ends fetch content through the Content Delivery API. It fits multi-site when the brands share a content model but need different designs, frameworks or release cycles on the front end.

The Delivery API supports multi-site directly. Each item’s route includes its start item (root node), and the Start-Item header scopes a path lookup to a given root by URL segment or GUID. Combined with Accept-Language for culture and Preview plus Api-Key for draft content, one Umbraco back end can serve several front ends:

GET /umbraco/delivery/api/v2/content/item/models/omoda-5
Start-Item: brand-b
Accept-Language: da-DK

(Illustrative request; the endpoint and headers are from the Umbraco Delivery API documentation.)

Example: Omoda Denmark, one monorepo for several front ends

For the Danish Omoda launch site we built Umbraco as a headless CMS with a NestJS proxy in between and Next.js rendering pages and blocks on the fly. A monorepo holds the shared components, rendering logic and APIs behind several sites with different designs. Localization combines the Umbraco Dictionary with Next.js routing, Umbraco preview runs inside the Next.js app behind admin authentication, and lead forms (test drive booking, newsletter sign-up) use TanStack Forms with conditional fields and validation. New branded sites can reuse the same components and APIs from the monorepo. See the Omoda Denmark case study.

The trade-off: headless adds a second application to build, host and monitor, and editor features like preview and forms need explicit work. It pays off when front-end flexibility across brands matters more than that extra moving part.

Choosing an architecture

Multi-site setup checklist

• Every routable root node has at least one hostname with a language
• Site settings live on or under the root node, resolved from the current page
• Shared components and compositions are used across sites; site-specific document types are the exception
• Each site has its own editor and publisher groups with content and media start nodes
• Forms are organized in per-site folders with Forms security configured
• Integration settings are per site, integration code is shared
• Caching, search indexes and sitemaps are scoped per site
• There is an agreed process for schema changes that affect all sites

If you are planning to consolidate several sites into one Umbraco platform, or to split one that has grown too large, our Umbraco development team has built all three patterns described here.