Independent marketing runtime
Serves cookie-free public content and the feature board without product sessions, product secrets, or tenant data.
Infrastructure
The working pilot is intentionally more complete than a single-container demo, but each component exists to preserve a specific boundary or operating behavior.
Working topology
Provider account details, credentials, internal addresses, and recovery commands stay private. Responsibilities, trust boundaries, maturity, and known limits are public.
Serves cookie-free public content and the feature board without product sessions, product secrets, or tenant data.
Provides sign-in, workspace discovery, and authenticated application traffic with host-local authority.
Carries explicit workspace context through reads, mutations, browser state, and synchronization authorization.
Preserves durable collaboration state and tenant policy while feeding a rebuildable synchronization replica.
Maintains the pilot real-time path and local working set without joining routine web releases.
Turns source identity, image policy, readiness, security, journeys, recovery, and cost into reviewable artifacts.
Tradeoffs
The topology is assessed by the failure behavior it enables—not by the number of services in the diagram.
A marketing change cannot receive product credentials or rebuild the application.
A complete candidate fleet can become ready before authenticated traffic moves.
The current singleton is transparent; multi-node view sync requires its own staged failure proof.
Restore, rollback, rebuild, reconnect, and hydration need separate signals and budgets.
Next chapter