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

Ship the Instance

Chapter 6 of 7 · Section 41 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

Drive it from the CLI

Once your instance answers /readyz, the navigator CLI runs the firm's whole matter flow against it from your terminal. It authenticates like gcloud auth login and lands a short-lived (~8h) token at ~/.navigator.json:


cargo install --path cli          # installs `navigator` on your PATH
# …or skip installing — run it straight from the source tree:
cargo run -p cli -- login --host www.your-domain.example   # `cargo run -p cli -- <args>` == `navigator <args>`

Presenter notes

The login is a browser-loopback OAuth that reuses your instance's existing OIDC session and stores the token 0600 at ~/.navigator.json (a single gcloud-style dotfile; set NAVIGATOR_CONFIG_DIR to use the legacy <dir>/credentials.json location instead). The host is your deployment's — www.your-domain.example, a staging host, or http://localhost:8080 for the KIND loop — so the same CLI drives whichever instance you point it at, each keyed separately in the credential file. That is the whole reason --host is a flag and nothing about a domain is baked in: this CLI is for your install, not ours. The crate is cli; the binary it builds is navigator.

Create a matter in the lawyer UI first, using the service/product picker, then log in and drive its notation workflow from the CLI using the matter code:


navigator site login --host www.your-domain.example    # opens the browser → ~8h token, stored 0600 (~/.navigator.json)
navigator site whoami                                  # "you@example.com (admin) — expires in 7h52m"
navigator site projects list                           # GET /app/projects.csv → table (or --json)
navigator site project open estate-of-doe              # opens the existing matter workbench if visible
navigator site notation create onboarding__retainer \
  --project estate-of-doe --client-email jane@example.com
navigator site retainer approve <notation-id>          # renders + parks the retainer PDF (no envelope yet)
navigator site notation status <notation-id>           # state + signature request id + document_ready
navigator site retainer send <notation-id>             # dispatches one real envelope (409 until document_ready)
navigator site retainer send <notation-id>             # idempotent — reuses the same envelope, no second send
navigator site logout

Use that same sequence to verify a fresh install end to end — it is the smallest real exercise of the durable pipeline after the lawyer UI has opened the matter. Point the client email at an inbox you control (never a third party — send transmits a binding engagement letter), and walk the three assertions: retainer approve should leave the notation parked at generate_pdf__retainer_pdf; notation status should flip to document_ready:true once the worker has rendered and persisted document.pdf (cross-check that the rendered object actually landed in your private documents bucket with gcloud storage ls gs://your-project-id-documents/notations/<notation-id>/); and retainer send should report sent_for_signature__pending with a signature request id, then reuse that same envelope on a second run. When you sign or decline, the inbound webhook should log a HMAC-verified esignature webhook: signature event in the navigator-web pod. Decline or void the test envelope afterward so no live engagement lingers against a real inbox.

After a single login, --host is optional — the one stored host is used — so the later commands stay short. Every command is a thin client over a route web already serves, sent with Authorization: Bearer <token>: your instance resolves that token back into your session and runs the same handler the browser does, so the lawyer_review gate, the role check, and the authored_by provenance all hold unchanged. The send is a durable two-step: retainer approve renders + parks the PDF on the worker, and the separate retainer send dispatches the envelope only after confirming the PDF landed (document_ready:true), returning a 409 with a JSON reason — never an opaque 500 — until then. Sending a retainer for signature stays a deliberate authenticated human command (retainer send) — it is never exposed as an agent-routable tool. The full per-subcommand reference is the cli crate's README.md in the source tree.

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