Ownership, and Making This Template Your Own (Part 5)

Part 4 covered how this platform actually ships — scaffolding, CI/CD, and the two deployment shapes. This closing part is the two things every one of the last four parts has assumed: who actually owns each piece of this, and what it takes to make this whole template yours.

Who owns what

Every piece of this platform belongs to exactly one team, and that split is what makes independent deploys survive contact with a real organization, not just a single-team demo:

Piece	Owned by	Depends on
Host / Shell	Platform team	Store, Components, the manifest, the identity provider
Components MFE	Platform / design-systems team	Nothing (a leaf)
Store MFE	Platform team	The identity provider
Utilities MFE	Platform team	Nothing (a leaf)
Domain MFE (×N)	Domain team	Components, Store, Utilities only
Manifest Registry	Platform team	Nothing
Identity provider(s)	Outside the platform — whichever the deployment configures	—
Backend / BFF	Domain team, or a shared gateway (Part 2)	Each team's own data

The rule underneath the table: domain teams never import from each other, only from the shared platform layer. That keeps the dependency graph a strict two-level tree — Host → platform layer → domain leaves — instead of a mesh, which is what keeps independent deployability tractable once there's more than a handful of domain teams. It's the same rule that made every part of this series possible to write in isolation: Part 3's auth flow doesn't need to know Part 4's deploy pipeline exists, and neither needs to know how many domain teams there eventually are.

Making this template your own

Everything organization-specific in this platform — branding, which identity provider(s) it trusts, where the manifest lives — has lived in one file across this entire series, on purpose:

// platform.config.json
{
  "orgName": "acme-corp",
  "branding": { "primaryColor": "#0B5FFF", "logoUrl": "..." },
  "idp": {
    "issuers": [
      { "id": "primary", "issuer": "https://issuer.example.com", "clientId": "...", "default": true }
    ],
    "issuerResolution": "default"
  },
  "manifestUrl": "https://cdn.acme.com/platform.manifest.json"
}

Host, the three platform MFEs, and the CI/CD pipeline ship as a GitHub template repository, not a library to install. Adopting it for a new org, a different business unit, or an entirely different kind of product — internal tool, customer-facing product, partner portal, or any mix — is meant to be: fork → edit platform.config.json → point DNS and CDN at your own infrastructure → done. No fork-and-diverge of Host's or Store's own logic required, which is exactly what keeps a fork upgradable from the upstream template later instead of quietly drifting into its own incompatible thing.

That's what the versioned contracts from Part 2 — StoreContract, DomainMFEExport, the manifest schema — are actually for, beyond just keeping one deployment internally consistent: they're the seam a fork can pull upstream changes across without breaking whatever a domain team already built on top of them.

Where this series leaves you

Five parts: the decision behind Module Federation and why the two credible alternatives lost (Part 1), the topology it produces — Host, the three platform MFEs, and the domain-MFE contract they all render into (Part 2), the login flow that unifies every mounted page regardless of which identity provider issued it (Part 3), and how a new domain team actually scaffolds, builds, and ships through a real CI/CD pipeline (Part 4). This part is the frame around all four: who owns which piece, and how the whole thing is meant to be forked, not just run as-is.

The code for all five parts — real, and the actual source every snippet in this series was pulled from — is on GitHub: github.com/akash-pal/enterprise-mfe-platform.