Multiple Domains
MergeSafe supports multiple domains per project. That lets teams expose one project across several product surfaces, environments, or branded entrypoints without pretending every rollout fits a single hostname.
Why teams need multiple domains
- A product may live on a marketing domain, an application domain, and a separate authenticated app hostname.
- Teams often need production and staged or regional hostnames within the same project boundary.
- One product surface may intentionally span several branded or partner-facing domains while still sharing the same tool set and release state.
Matching caveats to keep visible
- Assume broad authorization implications when you add a hostname, especially where subdomain or suffix matching may apply.
- Document the exact host patterns your team expects to authorize and test them before rollout.
- Do not collapse domain behavior into a simple one-host-equals-one-origin mental model if your deployment spans subdomains.
What docs should not overstate
The audited product truth does not support a strong claim that one hostname is globally unique across all projects. Uniqueness appears scoped per project rather than globally enforced, but same-hostname behavior across projects is still an ambiguity that should stay qualified.
That means docs should explain multiple domains as a supported per-project feature without turning that into a guarantee about cross-project hostname exclusivity.
Same-hostname behavior across projects remains an open question
Use careful wording until this is manually verified. The safe claim is only that multiple domains per project are supported.