bridge

mirror of https://github.com/luxfi/bridge.git synced 2026-09-24 00:26:46 +00:00

Files

T

zeekay cae93ea5d2 feat: standalone compose + LLM.md standalone audit + Hanzo non-existence note

User asked 'make sure that bridge can work standalone? ~/work/hanzo/teleport
and ~/work/hanzo/bridge' — both Hanzo paths confirmed not to exist; the
canonical Lux bridge is split across ~/work/lux/teleport (Warp 2.0
protocol, LP-021v2 / LP-7330) and ~/work/lux/bridge (UI + SDK + shim
server, this repo).

This commit answers the 'standalone' part:

compose.standalone.yml — bare three-service topology:
  - postgres (state)
  - bridge-server (API, optional LUX_* env stubs commented)
  - bridge-ui (Vite SPA via ghcr.io/luxfi/bridge image with BRIDGE_* env)

  NO Casdoor, NO Vault, NO NATS, NO Consul, NO 3-node MPC cluster.
  Every external Lux service is OPTIONAL at runtime — the backend
  graceful-degrades when the corresponding env block is unset and picks
  the integration up when it appears.

docs/LLM.md gains:
  - 'Standalone mode' section: docker compose recipe, what's
    intentionally NOT in standalone compose + why (one-line per service)
  - 'Hanzo-side bridge / teleport — does not exist' subsection: makes
    explicit that there is no ~/work/hanzo/teleport / ~/work/hanzo/bridge.
    If a Hanzo-branded tenant is needed, the right play is a Hanzo
    tenant build under app/ (mirror of app/bridge/) consuming @luxfi/bridge
    + @hanzoai/brand. SDK is the integration point; tenants are thin.

Verification: bridge backend already swallows MPC / IAM / NATS init
failures (logger.warn instead of fatal). Only Postgres is a hard dep,
which compose.standalone.yml provides. Full SQLite-only mode would
require a Prisma provider swap + per-table audit; that's a separate
session and standalone compose covers the immediate ask.

No code-runtime changes — the existing graceful-degradation paths in
app/server already supported this topology; this commit just makes
the recipe explicit + documented.

2026-05-23 18:59:25 -07:00