The topology is three runtime projects and the deployments checked into deployments/ — neon-law-stg,
neon-law-prod, and neon-law-prod, each carrying its own config.toml and secrets.enc.yaml, and each rolled by the
release run. neon-law-prod is provisioned in neon-law-prod and live: www.neonlaw.com resolves to its gateway IP
and is served by its Ingress, so all three rows now serve their own public host. neon-law-stg is the only persistent
staging lane; it exercises simulated matters through the same shared application, data-access, authorization, API, and
agent-protocol code used by every production brand. The image hub is a fourth project, ghcr, and is not an
environment.
Read the matrix by row. The neon-law-prod row, running neon-server, is the firm's primary website: the
deployment our public traffic is for. Its hostname is configuration, not code — NAVIGATOR_PUBLIC_HOST in the row's
config.toml — so the display brand and public URL can change any time without renaming a crate, an image, or a
deployment. Every production brand keeps an isolated resource prefix, database, cluster, namespace, runtime identity,
Secret, and Restate journal. Staging proves the common application once; brand route tests prove the public face shipped
by each immutable image.