fh deploy

Build and deploy a Fabric Harness workspace to Databricks, Node, containers, Kubernetes, Cloudflare, Foundry, Temporal, or Render.

fh deploy --target <target> [--preview] [--profile <name>] [--env <file>] [--env-name <name>] [--with-app]

fh deploy selects a target driver, builds the workspace for that target, runs its prerequisite checks, and invokes the platform deployment command. Use --preview first in automation or a new account; it prints the driver actions without changing the target platform.

Targets

Target	Deployment path
`databricks-app`	Build and deploy a Databricks App through its Declarative Automation Bundle
`databricks-serving`	Build the MLflow proxy and deploy a Databricks Model Serving endpoint
`node`	Run the built Node server locally
`docker`	Build and run the generated container
`cloudflare`	Deploy the generated Worker
`aks`, `aca`, `aci`	Deploy to Azure Kubernetes Service, Container Apps, or Container Instances
`foundry-hosted-agent`	Deploy the generated Microsoft Foundry Hosted Agent assets
`k8s`	Apply the generic Kubernetes artifact
`temporal-worker`	Deploy the generated Temporal worker
`render`	Deploy the generated Render service

Options

Flag	Behavior
`--target <target>`	Required deployment target
`--preview`	Print intended commands without executing them
`--profile <name>`	Databricks CLI profile used by App/Serving deployment
`--env <file>`	Load an explicit `.env`-style file before config and preflight
`--env-name <name>`	Load `.env.<name>` and matching workspace environment overrides
`--with-app`	After `databricks-serving` succeeds, also build and deploy `databricks-app`

Shell variables win over env-file values. Secrets are passed to provider commands through the environment; they are not written to build manifests.

Databricks Apps

fh doctor --target databricks-app
fh deploy --target databricks-app --preview --profile production
fh deploy --target databricks-app --profile production --env .env.production

The App driver expects the Databricks CLI, authentication, and a workspace bundle generated by the databricks-app build. When the App declares capabilities in FABRIC_DATABRICKS_APP_CAPABILITIES, doctor fails closed if required Lakebase, Genie, OBO, or cost bindings are absent.

Databricks Serving, optionally paired with an App

fh doctor --target databricks-serving
fh deploy --target databricks-serving --preview
fh deploy --target databricks-serving --with-app

Serving deployment runs a network-free doctor preflight before any provider mutation. Missing Python/MLflow, Databricks authentication, or package output stops the command with an actionable error. --with-app is accepted only with databricks-serving; the App deployment starts only after Serving succeeds.

Existing endpoint deployments are safe to retry while Databricks is converging an earlier change. The driver waits for endpoint readiness before replacing the served model, waits again before updating AI Gateway inference-table configuration, and waits for that gateway update to settle before reporting success. New endpoints follow the same readiness boundary between creation and the gateway update. A readiness or update failure stops the deploy and does not start --with-app.

Failure behavior

A missing or unknown target fails before a driver runs and prints close target suggestions.
An invalid flag or using --with-app on another target fails without deploying.
Databricks preflight failures stop before build/deploy provider calls.
A target command failure is returned as a failed deploy; the CLI does not claim rollback of resources already accepted by the provider.

See Databricks deployment, fh build, and fh doctor.