Neon Law | Make it yours — white-label under your own brand

Make it yours — white-label under your own brand

Neon Law Navigator runs two brands from one binary. A deployment operator can ship it under another identity without forking source by describing the organization once in a private navigator.yaml bundle:


cp navigator.example.yaml navigator.yaml   # then edit: names, emails, domain, logos
cargo run -p cli -- ops rebrand build --out .devx/brand-bundle
cargo run -p cli -- ops rebrand verify --dir .devx/brand-bundle
set -a; source .devx/env; set +a                # object storage and the rest of the runtime env
NAVIGATOR_CUSTOM_BRANDING=.devx/brand-bundle cargo run -p neon

Presenter notes

The bundle sets only identity — names, support addresses, postal addresses, the primary domain, the consultation link, and brand static files. It never machine-generates binding legal text. Kubernetes mounts it read-only at /etc/navigator/brand on the web and workflow-worker pods, and the deployment sets NAVIGATOR_CUSTOM_BRANDING to that path to opt in — without the env var the identity stays Neon Law. An application admin role does not imply authority to alter that deployment mount.

Most firms already run their own marketing site and have a team for it, so Neon Law Navigator does not need to be your public website — it can be just the client portal and workflow engine. portal_only: true in the bundle mounts only the application surface (/app, auth, /api, /mcp, the git transport, webhooks, the health probes, and the legal pages) and drops the public marketing + Foundation site; / redirects to /app/projects, and your own website links to your Neon Law Navigator portal. terms_url / privacy_url point the footer's Terms and Privacy links at the legal pages your own attorney publishes on your own site; bundle validation rejects a portal-only bundle with an empty terms_url — so you never ship NeonLaw's bundled, Nevada-governed terms under your name.

View all slides Open display