Neon Law | Workshops | Deploy The Navigator | Step

How a Project portal reaches a client

Each Project has its own source repository — neon-law/acme, say — holding a React application under portal/. That bundle is never committed anywhere in Navigator, and it never touches git on the way to a client. It is built in the Project repository's own CI, published to the deployment's private -applications bucket, and streamed from there by web — same-origin, and only after the session and Project participation row are checked.


flowchart LR
  subgraph repo["Project repo — neon-law/acme"]
    src["portal/ — React + Vite"]
    ci["CI on push to main:<br/>validate + application-publish"]
    src --> ci
  end
  subgraph gcp["Deployment project — neon-law"]
    bucket[("<deployment>-applications<br/>acme/portal/ — private, UBLA")]
  end
  subgraph nav["Navigator — neon-server"]
    web["web streams the bundle at<br/>/app/projects/acme/portal/"]
  end
  client(["Client browser"])

  ci -- "keyless WIF (navigator-app-publisher):<br/>upload dist/ — hashed assets first,<br/>index.html last, never delete" --> bucket
  client -- "GET /app/projects/acme/portal/" --> web
  web -- "check session + participation" --> web
  web -- "stream objects, same-origin" --> bucket

Presenter notes

The repository name is the Project code, so the Vite base baked at build time (/app/projects/acme/portal/) and the object prefix in the applications bucket (acme/portal/) both derive from it — nothing declares its own name. Publish order is load-bearing: hashed assets are uploaded first and index.html last, and nothing is ever deleted, so a client mid-load never resolves an asset the running index.html has not published yet. The ten-year lifecycle reaches only assets a later build orphaned, because every publish rewrites the live set unconditionally.

The publisher is a per-deployment navigator-app-publisher service account reached by keyless Workload Identity, so no key leaves GCP. It holds a custom role carrying exactly storage.objects.create, storage.objects.get and storage.objects.update — objectCreator is create-only and refuses every republish. The applications bucket is shared across Projects, so the bucket is not the boundary: that grant carries an IAM condition naming this Project's own acme/portal/ prefix, and it is the condition that stops a sibling Project's repo publishing over this one. Serving is the mirror of that trust: web holds objectAdmin on the bucket but streams the bytes itself rather than handing out a signed URL, so a bundle's own /app/api reads carry the same session cookie and stay inside the participation gate.

View all slides Open display