Multi Site Manager (MSM) overview
Purpose: Understand blueprints, live copies and rollouts enough to work on a multi-site codebase without breaking inheritance.
Who this page is for
| Audience | Why it matters to you |
|---|---|
| All engineers | MSM mistakes are expensive; know the basics before touching multi-site content |
The idea
One blueprint site (e.g. the master PHI site) feeds many live copies (regional/brand variants) which inherit content but can locally break inheritance per component/page. Like forks with an upstream you can re-sync.
/content/phi-master/plans/gold-hospital (blueprint)
│ rollout
├──▶ /content/phi-au/plans/gold-hospital (live copy, inherits)
└──▶ /content/phi-nz/plans/gold-hospital (live copy, local premium override)| Term | Meaning |
|---|---|
| Blueprint | Source site + rollout config |
| Live copy | Inheriting copy |
| Rollout | Push blueprint changes to live copies (manual or on-modify) |
| Inheritance break | Local edit detaches a component/property from upstream |
| Suspend / resume | Temporarily stop inheritance for a page |
Developer responsibilities
- Components must tolerate MSM: no hardcoded paths to a specific site branch; resolve site roots relative to the current page.
- Deleting/renaming components used by live copies can orphan inherited content — coordinate with content ops.
- Rollout configs decide *when* changes propagate; do not assume immediate consistency across copies.
When NOT to use MSM
Language-only variation with translation workflows may be better served by language copies + translation projects; purely data-driven differences (premiums per region) may belong in content fragments or backend config rather than forked pages. Escalate structure decisions to the architecture owner — see Multi-site architecture.