Neon Law
  • Services
  • Book Consultation opens in a new tab
  • Sign in

← Operating Neon Law Navigator

Configure the Trust Boundaries

Chapter 5 of 7 · Section 36 of 45

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 Navigator deployment matrix
  • 7. The `/app` mount and HTTP route ownership
  • 8. `neon` — the whole brand seam
  • 9. Live rollout checkpoint
  • 10. Set one site to one version

3. Provision the Infrastructure

  • 11. The APIs that light up
  • 12. Network and storage buckets
  • 13. How a Project portal reaches a client
  • 14. A document's bytes and authorization are separate
  • 15. A private image registry
  • 16. The cluster comes up
  • 17. What setup owns — and what follows it

4. Environment Matrix

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

5. Configure the Trust Boundaries

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

6. Ship the Instance

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

7. Wrap Up

  • 45. Canonical references

The external surface — every third party, in one place

Neon Law Navigator's runtime external surface has these services, in two kinds — platform services (the cloud the stack runs on) and feature vendors (each lights up one capability and stubs out cleanly when unconfigured):

ServiceWhat it gives youKindAt boot
Google CloudStorage, OIDC, archiveplatformrequired — provisioned by navigator ops gcp setup
Restate CloudDurable workflow execution (workflows-service)platformrequired — the workflow broker
Vertex AIInbound contract reviewfeatureoptional — the stub reviewer until configured
GitHubPrivate per-Project repositoriesplatformrequired in the requested cloud topology
DocuSignE-signaturefeatureCI-harness stub; required in a normal dev deployment and production
XeroAccounting / billing (ACCREC invoices)featureStubBillingProvider until XERO_* is complete
SendGridOutbound + inbound emailfeatureCI-harness capture; otherwise required

Presenter notes

The full catalog, with env prefixes and the per-environment account rule, is docs/third-party-integrations.md — the table above is the deployer's-eye view of it. Garage is the default open store for local and on-premises installs, while the S3 contract permits any conforming endpoint. The single-node Garage shape in KIND is disposable developer infrastructure, not a production HA topology. Two things worth saying out loud for a copyist:

  • Non-production boots with the canonical catalog; deployed integrations fail closed. The explicit local CI harness needs none of the feature vendors: it captures email and uses in-process stubs, while Garage, SurrealDB, Rauthy, and Restate run in KIND. Cloud staging and production instead require configured SendGrid and DocuSign accounts at boot. Test-only records stay inside the harness's isolated database schema.
  • One provider attachment per deployment. Staging attachments point only at sandboxes and production attachments point only at live accounts. A provider tenant may hold several attachments when that is its native model, but credentials, webhooks, senders, data partitions, and smoke evidence remain per deployment. That convention lives in docs/provider-environment-parity.md, docs/third-party-integrations.md, and docs/docusign-esignature.md.

One boundary worth naming: Xero reconciles against the firm's bank (Mercury) inside Xero — Neon Law Navigator never speaks to Mercury. Our only integration edge is the Xero API. That is the shape to copy: integrate the system of record, not everything it in turn connects to.

View all slidesOpen display
← PreviousNext →
Neon Law
  • X opens in a new tab
  • LinkedIn opens in a new tab
  • YouTube opens in a new tab
  • API opens in a new tab
  • Blog opens in a new tab
  • Contact
  • Glossary opens in a new tab
  • Navigator opens in a new tab
  • Notations opens in a new tab
  • Presentations opens in a new tab
  • Privacy opens in a new tab
  • Team opens in a new tab
  • Terms opens in a new tab
  • Testimonials
  • UX opens in a new tab
  • 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
  • Justice Technology AssociationMission-Aligned Partner opens in a new tab

Attorney advertisement. Nothing here is legal advice without a signed retainer for an active project. Past results do not guarantee future outcomes.

© 2026 Shook Law PLLC

NEON LAW® is a registered trademark of Shook Law PLLC, U.S. Reg. No. 6,325,650 opens in a new tab

Powered by Neon Law Navigator 26.10.4

Everyone deserves to be seen. Made with ❤️ in 🗽.