AEM aacs multi site | Community
Skip to main content
D
davidef34326447
Level 3
February 16, 2026
Solved

AEM aacs multi site

  • February 16, 2026
  • 6 replies
  • 69 views

Hi everyone,

 

I’m looking for some guidance on an architectural decision for a multi-site setup on AEM as a Cloud Service.

 

I need to create additional websites on the same AEM Cloud program. Some of these new sites will share part of the existing platform (authoring model, utilities, or components), while others may require different structures, custom components, or even different frontend approaches. In short, it’s a mix of shared and site‑specific functionality.

 

On AEM on‑prem, my usual approach would have been:

 

- One **common multi‑module project** containing shared utilities, services, and reusable components.

- One **separate multi‑module project per site**, each deployable independently (its own pipeline, its own release cycle).

- The shared project consumed as a dependency by each site.

 

### With AEM as a Cloud Service, I’m trying to understand the best practice for this scenario.

 

From what I know, AACS encourages a **single Git repository** and a **single pipeline** per program, but at the same time multi‑site architectures often require clear separation and modularity.

 

So I’d love to hear from the community:

 

1. **How do you usually structure multi‑site solutions on AEM as a Cloud Service** when:

   - some components are shared across sites,

   - but other features, templates, or frontend frameworks differ?

 

2. **Is a single Git repository with a multi‑module structure** the recommended approach (e.g. `core-common`, `core-siteA`, `core-siteB`, `ui.apps.common`, `ui.apps.siteA`, …)? 

   Any naming or packaging patterns you found effective?

 

3. **How do you handle deploy independence** in a Cloud environment where you cannot deploy each module separately? 

   Any governance or branching strategies that help isolate work for different sites?

 

4. **Are there use cases where you would actually split multiple Git repositories** within the same Cloud Manager program (e.g. drastically different tech stacks or teams)?

 

I’m not looking for guidance on a specific number of sites — more for a general best practice on how to scale the codebase cleanly while avoiding regressions and keeping the architecture maintainable over time.

 

Any experience, reference architecture, or real‑world lessons learned would be greatly appreciated.

 

Thanks a lot!

Best answer by giuseppebaglio

hi ​@davidef34326447,

AEMasCS supports multi-site via a single repo where modules separate shared (commons or core) from site-specific code (site-a/ui.apps, site-b/ui.apps).

  • Shared modules handle reusable components, utilities, and services under /apps/commons (e.g., ui.apps.common, core.common for OSGi bundles).
  • Site-specific modules extend shared ones, deploying to distinct paths like /apps/site-a/components or /apps/site-b/templates.

Use all Maven module as the container package embedding everything (ui.apps, ui.content, ui.config) for deterministic deployments, respecting immutable (/apps) vs. mutable (/conf, /content) splits.

If sites truly have different frontend stacks , you simply have separate frontend modules in the repo. They build independently via their own npm scripts; the all POM coordinates the final assembly.


The hardest constraint to work around is deploy independence and governance, and there's no perfect solution — only tradeoffs. Branching strategy is your primary isolation mechanism:

  • Environment-per-site staging: Use separate non-production environments (Cloud Manager supports multiple dev environments) to stage and test site-specific changes before they merge to main. Site A's team works on a feature/siteA/* branch, gets validated in a dedicated dev environment, then merges to a shared develop or main branch.
  • Feature flags: Site-specific features can be gated by OSGi configurations scoped to a run mode or by a feature flag service, so code for Site B lands in a deployment but is inert until switched on. This decouples code deployment from feature release.
  • Release trains: Some teams move to a regular cadence (e.g., bi-weekly releases) and accept that all sites deploy together. This works well when teams are disciplined about backward compatibility and use feature flags liberally.

The governance reality is that code coupling is now the bottleneck, not deployment coupling. If Site A's team can break Site B's components through a shared dependency, that's a coordination overhead regardless of deployment model.

 

Multiple repos within the same Cloud Manager program are possible:

The genuine cases where it makes sense:

  • Drastically different ownership and security boundaries — e.g., one site managed by an agency that must not have visibility into another brand's codebase, and even branch-level access controls in a monorepo are insufficient.
  • Completely different technology stacks where the Maven reactor provides no shared value — for example, one site is a pure headless Edge Delivery Service implementation with no AEM authoring at all.
  • Regulatory or compliance requirements that mandate code-level isolation between brands or business units.

In all other cases IMHO, the coordination overhead of multiple repos (keeping shared library versions in sync, managing cross-repo dependency upgrades, duplicate CI configuration) outweighs the independence you gain. The monorepo with strong module boundaries is almost always preferable.

6 replies

lukasz-m
Community Advisor
lukasz-mCommunity Advisor
Community Advisor
February 16, 2026

Hi ​@davidef34326447,

I would recommend to have a look below presentation/recording from last year adaptTo() conference.

One of the last slide contains list of links, that also could be useful.

I do not think there is one correct way, and it is more combination of your needs and AEMaaCS/Cloud Manager limitations/capabilities.

    Vishal_Anand
    Vishal_Anand
    Level 5
    February 16, 2026

    ​@davidef34326447 Use a single Git repository with a clear multi-module Maven layout for most multi‑site situations, and split into multiple repos/programs only when teams or technology stacks require truly independent lifecycles.
     

    Why single repo works?

    • Shared code & dependencies: Easier to enforce contracts, run a single build, and manage shared OSGi bundles, components, and clientlibs.
    • Cloud Manager fit: AEM as a Cloud Service expects one Cloud Manager program / pipeline per repo; single pipeline simplifies CI/CD and environment consistency.
    • Reduced drift: One repo reduces version skew and regression risk across sites.

    Suggested repo layout (pattern)

    • core-shared: common OSGi services/utilities.
    • core-siteA, core-siteB: site-specific backend code (if needed).
    • ui.apps.shared: shared components/content packages.
    • ui.apps.siteA, ui.apps.siteB: site-specific components/templates/content.
    • ui.frontend.shared: shared clientlibs/frontend build (libraries).
    • ui.frontend.siteA: site-specific frontend (SPA or HTL builds).
      Name modules clearly with site suffixes and keep shared packages truly generic.

    Handling deployment independence

    • Feature toggles / runtime switches: Allow deploying shared code without enabling site features until ready.
    • Content-only packages: Manage site content upgrades separately where possible (but still validate in pipeline).
    • Separate frontends: Host SPAs or radically different frontends outside AEM/CDN so they can release independently.
    • Branching & gating: Use short‑lived feature branches with trunk-based practices; use Cloud Manager stages/manual approvals to control releases. Long‑lived site branches only when unavoidable.

    When to split repos / programs

    • Different tech stacks or frameworks (e.g., one site pure HTL, another large React SPA with separate pipeline needs).
    • Different release/uptime SLAs or autonomous teams that must deploy without affecting others.
    • Security or tenancy separation requirements.
      In those cases, consider separate Cloud Manager programs or external hosting for non‑AEM frontends.

    Governance & practices

    • Module ownership and API contracts (semantic version shared modules).
    • Automated tests per site and cross-site integration tests in pipeline.
    • CI checks that run site-specific test bundles to avoid regressions.
    • Deprecation policy for shared components and a component registry/catalog.

    Short checklist to decide

    • If sites mostly share components → single repo multi‑module.
    • If sites need independent pipelines/releases or totally different tech → consider separate repos/programs.
    • For mixed cases → single repo + external frontend hosting + feature flags.
      Vishal_Anand
      Vishal_Anand
      Level 5
      February 16, 2026

      ​@davidef34326447  Use a single Git repository with a clear multi-module Maven layout for most multi‑site situations, and split into multiple repos/programs only when teams or technology stacks require truly independent lifecycles.
       

      Why single repo works?

      • Shared code & dependencies: Easier to enforce contracts, run a single build, and manage shared OSGi bundles, components, and clientlibs.

      • Cloud Manager fit: AEM as a Cloud Service expects one Cloud Manager program / pipeline per repo; single pipeline simplifies CI/CD and environment consistency.

      • Reduced drift: One repo reduces version skew and regression risk across sites.

      Suggested repo layout (pattern)

      • core-shared: common OSGi services/utilities.

      • core-siteA, core-siteB: site-specific backend code (if needed).

      • ui.apps.shared: shared components/content packages.

      • ui.apps.siteA, ui.apps.siteB: site-specific components/templates/content.

      • ui.frontend.shared: shared clientlibs/frontend build (libraries).

      • ui.frontend.siteA: site-specific frontend (SPA or HTL builds).
        Name modules clearly with site suffixes and keep shared packages truly generic.

      Handling deployment independence

      • Feature toggles / runtime switches: Allow deploying shared code without enabling site features until ready.

      • Content-only packages: Manage site content upgrades separately where possible (but still validate in pipeline).

      • Separate frontends: Host SPAs or radically different frontends outside AEM/CDN so they can release independently.

      • Branching & gating: Use short‑lived feature branches with trunk-based practices; use Cloud Manager stages/manual approvals to control releases. Long‑lived site branches only when unavoidable.

      When to split repos / programs?

      • Different tech stacks or frameworks (e.g., one site pure HTL, another large React SPA with separate pipeline needs).

      • Different release/uptime SLAs or autonomous teams that must deploy without affecting others.

      • Security or tenancy separation requirements.
        In those cases, consider separate Cloud Manager programs or external hosting for non‑AEM frontends.

      Governance & practices

      • Module ownership and API contracts (semantic version shared modules).

      • Automated tests per site and cross-site integration tests in pipeline.

      • CI checks that run site-specific test bundles to avoid regressions.

      • Deprecation policy for shared components and a component registry/catalog.

      Short checklist to decide

      • If sites mostly share components → single repo multi‑module.

      • If sites need independent pipelines/releases or totally different tech → consider separate repos/programs.

      • For mixed cases → single repo + external frontend hosting + feature flags.

       

        giuseppebaglio
        giuseppebaglioAccepted solution
        Level 10
        February 17, 2026

        hi ​@davidef34326447,

        AEMasCS supports multi-site via a single repo where modules separate shared (commons or core) from site-specific code (site-a/ui.apps, site-b/ui.apps).

        • Shared modules handle reusable components, utilities, and services under /apps/commons (e.g., ui.apps.common, core.common for OSGi bundles).
        • Site-specific modules extend shared ones, deploying to distinct paths like /apps/site-a/components or /apps/site-b/templates.

        Use all Maven module as the container package embedding everything (ui.apps, ui.content, ui.config) for deterministic deployments, respecting immutable (/apps) vs. mutable (/conf, /content) splits.

        If sites truly have different frontend stacks , you simply have separate frontend modules in the repo. They build independently via their own npm scripts; the all POM coordinates the final assembly.


        The hardest constraint to work around is deploy independence and governance, and there's no perfect solution — only tradeoffs. Branching strategy is your primary isolation mechanism:

        • Environment-per-site staging: Use separate non-production environments (Cloud Manager supports multiple dev environments) to stage and test site-specific changes before they merge to main. Site A's team works on a feature/siteA/* branch, gets validated in a dedicated dev environment, then merges to a shared develop or main branch.
        • Feature flags: Site-specific features can be gated by OSGi configurations scoped to a run mode or by a feature flag service, so code for Site B lands in a deployment but is inert until switched on. This decouples code deployment from feature release.
        • Release trains: Some teams move to a regular cadence (e.g., bi-weekly releases) and accept that all sites deploy together. This works well when teams are disciplined about backward compatibility and use feature flags liberally.

        The governance reality is that code coupling is now the bottleneck, not deployment coupling. If Site A's team can break Site B's components through a shared dependency, that's a coordination overhead regardless of deployment model.

         

        Multiple repos within the same Cloud Manager program are possible:

        The genuine cases where it makes sense:

        • Drastically different ownership and security boundaries — e.g., one site managed by an agency that must not have visibility into another brand's codebase, and even branch-level access controls in a monorepo are insufficient.
        • Completely different technology stacks where the Maven reactor provides no shared value — for example, one site is a pure headless Edge Delivery Service implementation with no AEM authoring at all.
        • Regulatory or compliance requirements that mandate code-level isolation between brands or business units.

        In all other cases IMHO, the coordination overhead of multiple repos (keeping shared library versions in sync, managing cross-repo dependency upgrades, duplicate CI configuration) outweighs the independence you gain. The monorepo with strong module boundaries is almost always preferable.

          D
          davidef34326447Author
          Level 3
          February 17, 2026

          Thank you both for the replies — extremely helpful perspectives.

           

          To clarify my scenario a bit (in a generic way): 

          I need to create additional sites on the same AEM as a Cloud Service program. 

          Some of these new sites will reuse part of the existing platform (shared utilities, services or authoring patterns), while others will require different components or different frontend behaviours.

           

          On AEM on‑prem I would normally structure this as:

          - one “common” multi‑module project with shared functionality,

          - and one separate multi‑module project per site, each deployable independently through its own pipeline.

           

          With AEMaaCS, since Cloud Manager promotes a single repository and a single pipeline per program, I’m trying to understand the best architectural balance between:

           

          **(A)** a single Git repo with a clear multi‑module, multi‑site structure 

          vs. 

          **(B)** multiple repositories / multiple programs when sites diverge significantly in terms of technology or lifecycle.

           

          The points mentioned above about:

          - feature toggles for isolating site‑specific releases,

          - clear separation through `core-shared`, `core-siteA`, `ui.apps.siteX`, etc.,

          - and governance to avoid regressions across sites,

          are very aligned with what I was considering.

           

          I also appreciated the suggestion to look at the adaptTo() talk on multi‑tenancy — I’ll go through that next.

           

          If you have any additional insights on:

          - when a single repo becomes too “heavy” for multi‑site scenarios,

          - or practical examples of how you modularize site‑specific vs shared components,

          - or how you handle frontend differences (HTL vs SPA) inside the same Cloud Manager pipeline,

           

          I’d be very interested to hear more.

           

          Thanks again for the valuable input!!

            giuseppebaglio
            giuseppebaglio
            Level 10
            February 17, 2026

            When using a single repository, the biggest governance challenge is code coupling, not the complexities of deployment. With a single repository, if Site A’s team modifies code that directly impacts Site B’s components through a shared dependency, it creates a coordination overhead; the potential for breaking Site B’s functionality remains a significant concern.

             

            Multiple repos within the same Cloud Manager program are possible:

            Use multiple repositories

            https://Git submodule support for Adobe repositories

            This should be used only in situations where the justification is overwhelmingly clear:

            • Drastically different ownership and security boundaries — e.g., one site managed by an agency that must not have visibility into another brand's codebase, and even branch-level access controls in a monorepo are insufficient.
            • Completely different technology stacks where the Maven reactor provides no shared value — for example, one site is a pure headless Edge Delivery Service implementation with no AEM authoring at all.
            • Regulatory or compliance requirements that mandate code-level isolation between brands or business units.

            In all other cases, the coordination overhead of multiple repos (keeping shared library versions in sync, managing cross-repo dependency upgrades, duplicate CI configuration) outweighs the independence you gain. The monorepo with strong module boundaries is almost always preferable.

              AmitVishwakarma
              Community Advisor
              AmitVishwakarmaCommunity Advisor
              Community Advisor
              February 18, 2026

              Hi ​@davidef34326447 ,
              1. Default choice: one program, one repo, multi‑module
              Use a single Cloud Manager program + single Git repo with a multi‑module Maven layout:

              • core-shared – common services/utilities
              • core-siteA, core-siteB – per‑site backend
              • ui.apps.shared – shared components under /apps/commons
              • ui.apps.siteA, ui.apps.siteB – per‑site components/templates
              • ui.frontend.shared – design system
              • ui.frontend.siteA, ui.frontend.siteB – per‑site themes (HTL or SPA)
              • dispatcher – one dispatcher module with separate vhosts/rules per site
              • all/application – container package that embeds everything

              This aligns with AEMaaCS project structure and Cloud Manager’s “single artifact per program” model.
              2. Deployment “independence” inside one program

              You cannot deploy sites separately, but you can isolate impact:

              • Feature flags / config per site (via /conf/siteA, /conf/siteB, OSGi configs)
              • Front‑end pipelines for faster, site‑specific CSS/JS deploys
              • Branching + code ownership (site‑specific modules vs shared modules)

              3. When to split repos/programs

              Only split into multiple repos/programs if you have:

              • Strong isolation needs (separate agencies, security/compliance boundaries), or
              • Completely different stacks / SLAs where sharing brings little value.

              Otherwise, a single repo + clear module boundaries is almost always easier to run long‑term.

              Thanks,
              Amit

              Amit Vishwakarma - Adobe Commerce Champion 2025 | 16x Adobe certified | 4x Adobe SME
                Terms & ConditionsAccessibility statement

                Loading footer...