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

← Operating Neon Law Navigator

Ship the Instance

Chapter 7 of 8 · Section 46 of 51

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. Operate Forgejo beside Navigator

  • 18. Deploy the forge before switching repositories
  • 19. Separate people, Git transport, and machine access
  • 20. Require the gate and protected-main policy
  • 21. Bind the workflow to one Project and one commit
  • 22. Notify failures even when the manifest is broken
  • 23. Restore the repository before cutting over

5. Environment Matrix

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

6. Configure the Trust Boundaries

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

7. Ship the Instance

  • 45. Ship and verify
  • 46. Post the verified handoff in `#navigator`
  • 47. Point your domain at the instance (optional)
  • 48. Drive it from the CLI
  • 49. Make it yours — white-label under your own brand
  • 50. This is how we set up our production deployment

8. Wrap Up

  • 51. Canonical references

Post the verified handoff in #navigator

Post only after the verification loop prints all three OK lines. Replace YY.M.D once with the deployed tag and preserve the config/host mapping exactly. The message body is:

:white_check_mark: Navigator YY.M.D is live on three deployment stacks

Verified /readyz, /version.release == "YY.M.D", and a browser visit:

  • staging
  • Neon production
  • Neon Law production

Set exactly one website to one published version:

Choose its name from the deployments/ tree (host is that config's NAVIGATOR_PUBLIC_HOST), set tag, then run:


name=neon-law-stg tag=YY.M.D
host=$(sed -n 's/^NAVIGATOR_PUBLIC_HOST = "\(.*\)"$/\1/p' "deployments/${name}/config.toml")
gcloud auth login --force --update-adc

set -a; eval "$(grep ' = "' "deployments/${name}/config.toml" | sed 's/ = /=/')"; set +a
gcloud container clusters get-credentials "$NAVIGATOR_GKE_CLUSTER_NAME" \
  --region "$NAVIGATOR_GCP_LOCATION" \
  --project "$NAVIGATOR_GCP_PROJECT_ID"

navigator ops secrets apply --deployment "$name"
navigator ops observability --deployment "$name"
navigator ops ship --deployment "$name" --tag "$tag" --dry-run
navigator ops ship --deployment "$name" --tag "$tag"

curl --fail --show-error --silent "https://${host}/readyz" >/dev/null
curl --fail --show-error --silent "https://${host}/version" |
  jq --exit-status --arg tag "$tag" '.release == $tag'

Change only name and tag; the host follows from the config. The current tree maps:

  • neon-law-stg → staging.neonlaw.com
  • neon-law-prod → www.neonlaw.com
  • neon-law-prod → www.neonlaw.com

All three hosts resolve to their own deployment's gateway IP, so all three answer /readyz and /version directly.

Presenter notes

Roll and verify staging before production. A successful Kubernetes apply is not completion: /readyz must succeed, /version.release must equal tag, and the website must open in a browser.


Do not present the Slack message as a deployment command. It is the evidence handoff after every deployment's health, version, and browser checks pass. Demonstrate the single-site recipe separately: one deployment, one immutable tag, one cluster context, and one host verification. Keeping those values paired is what prevents an operator from rolling the wrong site.

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
  • Blog
  • Contact
  • Glossary
  • Navigator
  • Notations
  • Presentations
  • Privacy
  • Team
  • Terms
  • Testimonials
  • contact@neonlaw.com
  • +1 510 800 2090
  • California
    1515 20th StreetBakersfield, CA 93301
  • 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 PC

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

Powered by Neon Law Navigator 26.10.18

neon-law/navigator opens in a new tab

Everyone deserves access to justice. Made with ❤️ in 🗽.