Deployment

Radar has three deployable surfaces, each hosted where it fits best.

Documentation (this site)

The docs site is a Fumadocs static export served by a Cloudflare Worker with a static-assets binding on radar.fabric.pro — the same pattern as the rest of the Fabric family. The build exports to apps/docs/out/, syncs into dist/cloudflare-docs/, and deploys with Wrangler:

pnpm docs:build   # next build → apps/docs/out
pnpm docs:sync    # rsync → dist/cloudflare-docs
pnpm docs:deploy  # build + sync + wrangler deploy

Docs are fully static with no governed mutations, no tenant data, and no workspace dependency, so they stay on the edge with the rest of the family. Databricks Apps hosting is reserved for the console.

Console

The Radar console — the anomaly inbox, monitor registry, and intervention approvals — is a Next.js application deployed as a Databricks App, because it needs in-workspace identity and data access. It renders in the shared Fabric family shell and reads from Platform projections; it never writes business state directly.

Control plane

The Radar FabricModule — monitor declaration, the anomaly lifecycle, and the intervention actions — runs on the Fabric Platform Host with a PostgreSQL (Lakebase) store for durable invocations and the event log. Detection runs as Fabric Experiments evaluators on a Temporal Schedule; interventions execute as durable workflows composed from @fabric-harness/temporal.

Delivery and promotion of Radar itself is delegated to Fabric Runway, which ships the module and console through the same gated pipeline Radar watches for everyone else.