FabricFabricAirlift

Deployment

The declarative Databricks Asset Bundle, the Cloudflare docs worker, and what ships in each phase.

Airlift follows the family deployment layout exactly: a declarative Databricks Asset Bundle for the console and its resources, and a Cloudflare Worker serving this documentation site.

Databricks Asset Bundle

The repo root carries databricks.yml with deploy/databricks/resources/:

  • app.yml — the Airlift console as a Databricks App, with the Lakebase resource binding, the SQL warehouse for parity suites, and secret references (never values).
  • lakebase.yml — the Lakebase Autoscaling project/branch/endpoint/database for the durable governed store (PostgresPlatformHostStore).
  • analytics.yml — the UC schema reserved for Delta projections of the event log.

Every environment-specific value arrives through bundle variables (BUNDLE_VAR_*): no workspace URLs, tokens, warehouse ids, or environment identifiers exist in the repo — the repository contract test enforces it.

databricks bundle validate            # pnpm validate:databricks wraps this
databricks bundle deploy -t dev

Deploying the App activates AIRLIFT_STORE=postgres; the console and worker run ensureSchema() as an explicit controlled-startup step. (The durable store binding is the Phase 1 deliverable — see ADR-005.)

Documentation site

This site is a Fumadocs static export served by a Cloudflare Worker at airlift.fabric.pro — the same docs:build → docs:sync → wrangler deploy trio as every family product:

pnpm docs:build
pnpm docs:deploy

Docs stay on the edge; Databricks Apps hosting is reserved for the console, which needs in-workspace identity and data access.

Console identity

Deployed as a Databricks App, the console resolves the operator from the Apps ingress forwarded headers (x-forwarded-email / x-forwarded-preferred-username), gated on AIRLIFT_TRUST_DATABRICKS_APP_HEADERS=1 and DATABRICKS_APP_NAME so a bare next dev process never trusts spoofable headers. A request without a natural-person marker fails closed: no shell, no governed action.

Live deployment (dev, 2026-08-01)

Phase 1 is deployed and certified on the Tech Fabric dev workspace:

  • Consolefabric-airlift-dev on Databricks Apps, running in postgres mode: ensureSchema() at controlled startup, the governed org bootstrap (AIRLIFT_BOOTSTRAP_ORG_ID) executed durably with a stable idempotency key, and the operator resolved from the workspace-forwarded identity.
  • Durable store — Lakebase project fabric-airlift-dev (database airlift); certify:live drives estate → assessment → object → wave → assignment through the governed pipeline over a short-lived OAuth database credential and asserts the projection read-back; the running console renders the same rows.
  • Lakebridge wrapper jobsairlift-lakebridge-analyzer and airlift-lakebridge-converter, serverless notebook jobs implementing the adapter's notebook-exit contracts; the real analyzer produced xlsx+JSON reports into the artifacts volume, and the converter's deterministic pass runs the built-in SqlglotEngine (BladeBridge/Morpheus install is refused inside Databricks Runtime — they remain operator-workstation engines; Switch is the agent lane).
  • Residue spike (ADR-0004) — executed against the public Northwind estate (36 objects): 35 auto-converted, 1 residue (2.8%) — far under the 60% tripwire; the agentic Phase-2 scope stands. Every outcome was loaded through governed actions and is visible in the live funnel.

Phase map

PhaseStatus
0 — Walking skeleton: module + policies + worker (mock) + console (seeded) + docs + contract testsDone
1 — Lakebase store, live Lakebridge workspace jobs, bundle deploy, funnel demo, residue spikeDone (cutover effector awaits the first design partner)
2 — Conversion factory: Harness repair agent + testkit parity suites, the certified-rate metricNext
3 — Cutover governance polish: durable approvals against real Temporal, evidence export surfacesPlanned
4 — Databricks M&M Brickbuilder submission from design-partner migrationsPlanned

On this page