Multi-site & multi-tenant architecture
Purpose: Structure many sites/brands/regions on one AEM platform without them strangling each other.
Who this page is for
| Audience | Why it matters to you |
|---|---|
| Architects / tech leads | Structural decisions |
| All engineers | Working in a multi-site repo |
The axes of "multi"
| Axis | Tool |
|---|---|
| Same site, many languages | Language roots + translation (i18n) |
| Same content, many regions/brands with variation | MSM blueprint → live copies (MSM) |
| Different sites, shared platform/components | Separate /content roots + shared component library |
| Different tenants (org boundaries) | Separate everything below a governance line — or separate instances |
Shared code, many sites
/apps/acme-platform/components/… shared component library (one team owns)
/apps/site-phi/… site-specific proxies/overrides + theme clientlibs
/apps/site-other/…
/conf/site-phi/… per-site templates & policies
/content/site-phi/… /content/dam/site-phi/… per-site content, mirrored ACL trees- Sites consume the shared library via proxy components + their own policies/styles — the Core Components pattern applied internally.
- Site theming through clientlib theming (CSS custom properties), not component forks.
- Version the shared library and treat site teams as consumers with a changelog; breaking a dialog is breaking an API.
Tenancy honesty
True tenant isolation on one 6.5 instance is limited: OSGi config, JVM, error budgets and deploy cadence are shared. Sharing works for one organisation's brands; for genuinely independent tenants (different orgs, different risk appetites), separate instances cost less than the governance to fake isolation.
Delivery side
Each site gets its own dispatcher farm/vhost and cache tree (farm design); one site's flush storm must not evict another's cache.