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

← Operating Neon Law Navigator

Environment Matrix

Chapter 4 of 7 · Section 28 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

Deployed runtime: repositories, content, AI, and scheduled work

CapabilityEnvironment variables
Mounted Git writerNAVIGATOR_GIT_REPO_ROOT
Forge coordinate, both requiredNAVIGATOR_GIT_HOST (default github.com), NAVIGATOR_GITHUB_ORG (no default)
GitHub App identityNAVIGATOR_GITHUB_APP_ID
GitHub App installationNAVIGATOR_GITHUB_INSTALLATION_ID
GitHub App proofNAVIGATOR_GITHUB_APP_PRIVATE_KEY
GitHub token fallbackNAVIGATOR_GITHUB_TOKEN (or GITHUB_TOKEN)
GitHub endpointNAVIGATOR_GITHUB_API_BASE
GitHub webhook receiverNAVIGATOR_GITHUB_WEBHOOK_SECRET, NAVIGATOR_GITHUB_CANONICAL_REPOSITORY
Receiver identity and Restate submitNAVIGATOR_GITHUB_APP_LOGIN, RESTATE_INGRESS_URL, RESTATE_AUTH_TOKEN
GitHub concurrency capNAVIGATOR_GITHUB_MAX_CONCURRENT
GitHub revision capNAVIGATOR_GITHUB_MAX_REVISE_ROUNDS
GitHub daily token capNAVIGATOR_GITHUB_MAX_DAILY_TOKENS
DevX Slack worker (in workflows-service)SLACK_WEBHOOK_URL
Content rootsNAVIGATOR_PUBLIC_DIR, NAVIGATOR_BLOG_DIR, NAVIGATOR_WORKSHOPS_DIR
CLI login fileNAVIGATOR_CREDENTIALS_FILE, NAVIGATOR_CONFIG_DIR
Harness worktree/cacheNAVIGATOR_WORKTREE_PATH, NAVIGATOR_CHROME_CACHE_DIR
Vertex coordinatesNAVIGATOR_GCP_PROJECT_ID, NAVIGATOR_GCP_LOCATION, GOOGLE_METADATA_URL
Contract reviewerNAVIGATOR_CONTRACT_REVIEW_MODEL plus the same GCP project, location, and metadata variables
On-chain attestationNAVIGATOR_ONCHAIN_BACKEND
Billing exportBILLING_EXPORT_TABLE, BIGQUERY_PROJECT
Billing noticesBILLING_CANARY_NOTIFY_EMAIL
Billing digestBILLING_DIGEST_NOTIFY_EMAIL, BILLING_DIGEST_WINDOW_DAYS

Presenter notes

Matter creation must have a real Git writer even if the higher-level forge is local. The content variables only relocate the read-only files baked into the image. Navigator MCP uses NullRouter without the GCP project; contract review uses StubContractReviewer without the same Vertex coordinates. The on-chain backend defaults to null, recording no transaction. Scheduled cost and billing diagnostics stay disabled when their table or recipient variables are absent.

The GitHub webhook receiver is the exception to that degrade-quietly pattern, and where it runs is deliberate. It is served at POST workflows.<domain>/webhooks/github/{secret} by workflows-service, on its own Axum listener (WORKFLOWS_WEBHOOK_LISTEN, 9082) beside the worker's Restate endpoint; the Envoy sidecar routes /webhooks/github/* to that listener and every other path to the Restate leg. It runs on the workflows host, not on www, because www remains behind the firm's Tailscale tailnet perimeter — and GitHub, an external sender that cannot join a tailnet, can only reach a public host. That split is the rule worth remembering: the tailnet protects the human surface (www, the portal, the workbench), while a machine caller's endpoint stays public and is authenticated by the signature it carries, not by the network it arrives from. GitHub signs each delivery, so the receiver verifies X-Hub-Signature-256 against the raw body — which is why the Envoy leg to it stays HTTP/1.1 end to end and forwards the bytes unaltered.

Startup still requires the webhook secret, canonical repository, GitHub org, and app login, and RESTATE_INGRESS_URL plus RESTATE_AUTH_TOKEN: a receiver that cannot verify a delivery or reach the Restate ingress has no safe reduced mode. It is still one worker process — there is no separate receiver container — but it now owns a second listener port that Envoy fronts, rather than sharing web's. The DevX Slack services DevxIssueTriage and devx-pr fold into workflows-service alongside the legal workflows and the receiver; they alone read SLACK_WEBHOOK_URL and fail closed when Slack is absent so Restate can retry instead of acknowledging a lost engineering notice. Only neon-law-stg is allowed to mount the receiver or bind the GitHub services. It also requires positive NAVIGATOR_GITHUB_MAX_CONCURRENT, NAVIGATOR_GITHUB_MAX_REVISE_ROUNDS, and NAVIGATOR_GITHUB_MAX_DAILY_TOKENS values: its singleton devx-guardrails/global object serializes all reservations, defers work at the concurrency cap, and pauses new token reservations through the UTC-day reset. Other deployments do not bind that object or read these limits.

The receiver watches two GitHub owners. The product code lives at github.com/neon-law/navigator and is always watched; the firm's private per-Project repos live under github.com/neon-law-firm/<projects.code>, where neon-law-firm is NAVIGATOR_GITHUB_ORG. A delivery is accepted when it comes from the canonical code repository or any repo owned by that org.

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 🗽.