FabricFabricExperiments
Deployment

Staging environment

Bring up the Cloudflare-native staging control plane with an isolated Azure Databricks data path and promotion-grade evidence.

Staging is intentionally separate from the production Databricks App. It proves the browser and edge path on Cloudflare while exercising the same governed Databricks workload surfaces used in production.

Prerequisites

  • Cloudflare access for Workers Builds, routes, KV, Queues, R2, Hyperdrive and secrets.
  • GitHub access to connect the repository to Cloudflare Builds.
  • A Neon staging database and migration credentials.
  • An Azure Databricks workspace, restricted workload identity, SQL warehouse, scratch catalog/schema, Volume, isolated Auto Loader pipeline and staging ingestion job.
  • A staging organization, API key and synthetic user credentials stored as CI secrets.

Bring-up order

  1. Create Neon Postgres, apply all migrations, and connect it through Hyperdrive.
  2. Create Cloudflare KV, Queue and R2 resources.
  3. Configure API, Studio and edge-worker secrets.
  4. Connect Cloudflare Builds and deploy API, Studio, manifest, exposure, audit, CDN and docs workers.
  5. Provision the isolated Unity Catalog schema, Volume, Auto Loader pipeline, SQL warehouse access and browser-to-Studio ingestion job.
  6. Create the restricted workload service principal and grant only the staging resources it needs.
  7. Seed an organization, experiments and an API key.
  8. Run fast service smokes, the required Databricks suite, and the complete browser-to-Studio path.
  9. Accumulate seven consecutive scheduled green nights before production promotion.

Canonical staging endpoints

SurfaceURL
APIhttps://api-staging.experiments.fabric.pro
Studiohttps://studio-staging.experiments.fabric.pro
Manifesthttps://manifest-staging.experiments.fabric.pro
Ingestionhttps://ingest-staging.experiments.fabric.pro
Documentation previewhttps://experiments-staging.fabric.pro/docs/ when enabled

Deployment commands

Cloudflare Builds deploys on the configured production branch. The fallback is:

pnpm install --frozen-lockfile
pnpm --filter @fabricorg/experiments-api run cf:deploy:staging
pnpm --filter @fabricorg/experiments-studio run cf:deploy:staging
(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)

Use repository-root builds because applications and workers consume workspace packages. Store secret values in Cloudflare secrets or CI environments, never in committed Wrangler files.

Validation order

Run cheap checks first and stop on failure:

  1. DNS, TLS and /healthz for API and edge workers.
  2. Authentication, organization resolution and Studio server rendering.
  3. Manifest publication and signed-preview verification.
  4. Browser/tag-loader exposure and conversion delivery to Cloudflare.
  5. Required Azure Databricks live checks under the restricted identity.
  6. Browser → R2 → Auto Loader → Delta → aggregate API → Studio results.
  7. Evidence upload and unconditional resource cleanup.

The live-smoke guide lists the exact gates and configuration. The certification page reports the current observation status.

Promotion boundary

A manual green run is diagnostic evidence, not a scheduled-night credit. The promotion counter increments only after the scheduled complete path succeeds; any scheduled failure resets it. Production promotion remains blocked until the counter reaches seven and backup/restore plus rollback evidence is current.

On this page