Publish and test from cloud

Fabric uses two deliberate deployment shapes:

The production Studio and API are served directly at studio.experiments.fabric.pro and api.experiments.fabric.pro.

Publish the documentation

pnpm docs:deploy

This builds the Fumadocs static export, syncs it into dist/cloudflare-docs, and deploys cloudflare/docs-worker to https://experiments.fabric.pro/docs/. Pushes to main that change the docs or docs worker trigger the same workflow automatically.

Verify the public entry points:

curl -fsSL -o /dev/null https://experiments.fabric.pro/docs/
curl -fsSL -o /dev/null https://experiments.fabric.pro/docs/testing/quickstart/
curl -fsSL -o /dev/null https://experiments.fabric.pro/docs/migration/compatibility/

Publish staging API and Studio

Cloudflare Builds is the normal path. The manual fallback from a clean checkout is:

pnpm install --frozen-lockfile
pnpm --filter @fabricorg/experiments-api run cf:deploy:staging
pnpm --filter @fabricorg/experiments-studio run cf:deploy:staging

The canonical staging hosts are:

• https://api-staging.experiments.fabric.pro
• https://studio-staging.experiments.fabric.pro

The API uses Neon Postgres through Hyperdrive for control-plane state. Configure BETTER_AUTH_SECRET, MANIFEST_KEY_ENC_KEY_HEX, WORKER_API_TOKEN, email delivery, and the database binding as Worker secrets. Do not place secret values in wrangler.jsonc.

Publish edge workers

(cd cloudflare/manifest-worker && pnpm exec wrangler deploy --env staging)
(cd cloudflare/exposure-worker && pnpm exec wrangler deploy --env staging)
(cd cloudflare/audit-export-worker && pnpm exec wrangler deploy --env staging)
(cd cloudflare/cdn-worker && pnpm exec wrangler deploy --env staging)

KV, R2, Queue, Hyperdrive and secret bindings must already exist. The repository's staging runbook records the exact binding names and one-time setup.

Publish production API and Studio

node scripts/check-cloudflare-production-readiness.mjs
pnpm --filter @fabricorg/experiments-api run cf:deploy:production
pnpm --filter @fabricorg/experiments-studio run cf:deploy:production

The API uses the production Lakebase Hyperdrive binding. Production migrations remain owner-governed and are not run by the Cloudflare runtime role.

Maintain the Databricks rollback App

The repository root Databricks Asset Bundle retains the combined App as a rollback target during the cutover window. It uses:

• databricks.yml and deploy/databricks/resources/app.yml for resources;
• app.yaml for the application runtime;
• Lakebase for operational state;
• a Databricks SQL warehouse for aggregate results;
• Databricks secrets and app-resource bindings for credentials.

Validate before deployment:

databricks bundle validate -t prod
databricks bundle deploy -t prod

Use the Databricks deployment guide for resource bindings, migrations, health probes and OAuth behavior.

Legacy service ingress

The old service-ingress Worker has no production route. Restore it only as part of a Databricks App rollback, following the service ingress runbook.

Run the smoke gates

Use the fast service gates while iterating:

FX_LIVE_TEST=1 \
FX_LIVE_API_BASE_URL=https://api-staging.experiments.fabric.pro \
FX_LIVE_API_KEY="$STAGING_API_KEY" \
FX_LIVE_ORG_ID="$STAGING_ORG_ID" \
scripts/live-smoke-m3.sh

Before promotion, run the complete managed path:

node scripts/live-smoke-browser-databricks-studio.mjs

It verifies browser emission → Cloudflare Queue/R2 → Databricks Auto Loader and Delta → aggregate API → authenticated Studio results. The gate also asserts Bayesian, CUPED, time-to-convert, conversion-depth and segmentation surfaces. Missing required configuration fails rather than silently skipping.

See Live smoke and promotion for environment variables, evidence artifacts and the seven-consecutive-night policy.