Neon Law
  • Fractional CTO
  • Litigation
  • Fractional GC
  • Legal Services
  • Sign in
← Operating Neon Law Navigator

Provision the Infrastructure

Chapter 3 of 7 · Section 14 of 44

Sections

1. Intro

  • 1. Deploy your own
  • 2. Agenda

2. Prepare Google Cloud

  • 3. Bring your own project
  • 4. Dry-run first
  • 5. Private assets and domain restricted sharing
  • 6. The one project that is public on purpose
  • 7. The Navigator deployment matrix
  • 8. The `/app` mount and HTTP route ownership
  • 9. `neon` — the whole brand seam
  • 10. Live rollout checkpoint
  • 11. Set one site to one version

3. Provision the Infrastructure

  • 12. The APIs that light up
  • 13. Network and five buckets
  • 14. How a Project portal reaches a client
  • 15. One matter's document never backs another matter's
  • 16. A private image registry
  • 17. The cluster comes up

4. Environment Matrix

  • 18. Three operating modes, two deployment profiles
  • 19. Configuration precedence: the first source wins
  • 20. Local dev controls: inputs read by `navigator dev`
  • 21. Local runtime: what `.devx/env` generates
  • 22. The store: SurrealDB
  • 23. Where SurrealDB authorization lives
  • 24. Deployed runtime: core web and worker wiring
  • 25. Deployed runtime: identity and access
  • 26. Deployed runtime: email, signatures, and billing
  • 27. Deployed runtime: repositories, content, AI, and scheduled work
  • 28. Provision and ship: variables read by the operator CLI
  • 29. Ancillary operations and opt-in test controls
  • 30. When simulated data appears

5. Configure the Trust Boundaries

  • 31. Secrets: the invariants that gate the boot
  • 32. Sign-in: bring an OIDC provider; passwords live there, not here
  • 33. Role rings: who can do what
  • 34. Provider signup and parity across the deployments
  • 35. The external surface — every third party, in one place
  • 36. The two service deployments
  • 37. Security architecture

6. Ship the Instance

  • 38. Ship and verify
  • 39. Post the verified handoff in `#navigator`
  • 40. Point your domain at the instance (optional)
  • 41. Drive it from the CLI
  • 42. Make it yours — white-label under your own brand
  • 43. This is how we set up Neon Law Foundation

7. Wrap Up

  • 44. Canonical references

How a Project portal reaches a client

Each Project has its own source repository — neon-law/spotonix, 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/spotonix"]
    src["portal/ — React + Vite"]
    ci["CI on push to main:<br/>validate + application-publish"]
    src --> ci
  end
  subgraph gcp["Deployment project — neon-law"]
    bucket[("neon-law-prod-applications<br/>spotonix/portal/ — private, UBLA")]
  end
  subgraph nav["Navigator — neon-server"]
    web["web streams the bundle at<br/>/app/projects/spotonix/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/spotonix/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/spotonix/portal/) and the object prefix in the bucket (spotonix/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 30-day 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 with objectCreator on this one bucket, reached by keyless Workload Identity from the Project repository alone — no key leaves GCP, and a sibling Project's repo cannot publish 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 slidesOpen display
← PreviousNext →
Neon Law
BlogContactFoundationNavigatorPresentationsWorkshops
Contact us — contact@neonlaw.com+1 510 800 2080
  • Nevada
    5150 Mae Anne AveSte 405-9002Reno, NV 89523
  • New York
    12 E 49th St18th FloorNew York, NY 10017
  • Washington
    720 Seneca StSte 107-715Seattle, WA 98101

© 2026 Shook Law PLLC and Neon Law Foundation

This is attorney advertisement. Nothing on this site is legal advice. Neon Law is the trade name of Shook Law PLLC, and an attorney-client relationship begins only with a signed retainer between you and Shook Law PLLC. Published flat fees cover the scope each one names and do not include third-party filing fees. Every legal matter is different, and past results do not guarantee a similar result.

Shook Law PLLC is a proud supporter of the Neon Law Foundation , a 501(c)(3) nonprofit.

Neon Law Foundation is a Nevada nonprofit corporation and a 501(c)(3) tax-exempt organization. It does not practice law and cannot represent you.

Nothing on this site is legal advice, and nothing here creates an attorney-client relationship.

5150 Mae Anne Ave Ste 405-9999, Reno, NV 89523
support@neonlaw.orgTransparency & public disclosures

Powered by Neon Law Navigator #26.8.20-hotfix.4

Open source — neon-law-foundation/navigator GitHub stars 2