FabricFabricHarness
Reference

Production Readiness Checklist

What to validate before running Fabric Harness agents in production.

Use this checklist to validate the exact runtime, providers, credentials, policies, and stores in your deployment environment. Generated Node artifacts use the shared v2 server; hosted targets add their own identity, networking, quota, and recovery requirements.

Release baseline

Before promoting a release:

  • Review Validation status, pin the exact package set, and list every capability the client pilot will enable. A passing workflow with skipped credentialed steps is not live provider evidence.
  • Run pnpm install --frozen-lockfile.
  • Run pnpm run check.
  • Run pnpm run build.
  • Run pnpm run test.
  • Run the package suites with constrained concurrency if the workspace-wide parallel run times out; the current Databricks App persistence and CLI dev-banner tests are sensitive to full-workspace contention.
  • Pack publishable packages and inspect manifests for semver dependency ranges, not workspace:*.
  • Install @fabric-harness/sdk@latest, @fabric-harness/node@latest, and @fabric-harness/cli@latest in a clean ESM consumer project.
  • Run the downstream template mock suite against the release candidate version before publishing.
  • Keep downstream templates on exact package versions and update those pins only after the packed artifact and registry compatibility gates pass.
  • Verify fh --help, SDK subpath imports, and CommonJS resolution of those subpaths through require.resolve when CJS-based tooling is in the deployment.
  • Deploy the Fumadocs site and verify https://harness.fabric.pro/docs plus llms.txt.

Choose a deployment path

  1. Start with the node target and virtual sandbox for simple support/routing/extraction agents.
  2. Use local only when CI/repo automation intentionally needs host tools.
  3. Use Docker sandbox for untrusted shell or data-analysis work.
  4. Use Temporal for long-running tasks, approval delays, and restart durability.
  5. Use Cloudflare for edge and serverless workloads after running the account smoke test.
  6. Run the documented environment validation for AKS, ACA, Databricks, E2B, Daytona, and Modal.
  7. Use policies and approvals for every mutating command, tool, or external integration.
  8. Put definition-wide enforcement controls on AgentDefinition; call-level policy may add restrictions but cannot loosen the definition policy or budget.

Security gate

  • Define explicit filesystem, command, tool, and network policies.
  • Prefer deny-by-default command and network policy for unattended agents.
  • Route risky actions through requireApproval or custom approval rules.
  • Store secrets outside prompts and logs; verify redaction on representative failures.
  • Prefer Docker or a remote sandbox for untrusted code. Avoid host-local sandbox for untrusted workloads.
  • Configure tenant IDs when running multiple users/customers through the same deployment.
  • Return explicit principal permissions from authenticate; do not rely on the unrestricted legacy compatibility principal.
  • Grant operator-console users only the required admin:read, session:abort, and session:delete scopes.
  • Protect the default branch with pull-request review and blocking CI. Restrict secret-bearing GitHub Environments to protected branches or release tags and disable administrator bypass.
  • Run pnpm check:github-actions; require the current supported Node 24-native action majors, keep self-hosted runners current, and review weekly GitHub Actions Dependabot updates. Do not use ACTIONS_ALLOW_USE_UNSECURE_NODE_VERSION to prolong an obsolete action runtime.

Runtime gate

  • Set request body limits, auth, and rate limits for every public HTTP surface.
  • Use durable session stores for production deployments; avoid in-memory stores outside tests.
  • Back up session/artifact stores according to your recovery objectives.
  • Verify cancellation, retry, and timeout behavior on your target runtime.
  • For Temporal, test worker restart, workflow retry, approval delay, and namespace/auth configuration.

Observability gate

  • Export traces through OpenTelemetry, App Insights, Langfuse, or your chosen collector.
  • Track token usage, cost, duration, tool calls, approvals, and task lifecycle events.
  • Add dashboards/alerts for model failures, budget exhaustion, approval timeouts, rate limits, and sandbox failures.
  • Keep audit exports for compliance-sensitive agents.

Hosted integration gate

Run credentialed tests for every backend in the deployment:

  • Real model provider smoke tests.
  • Docker sandbox execution.
  • Postgres/Redis/session stores under expected concurrency.
  • Temporal local or cloud namespace tests, using a real gRPC readiness probe before integration tests.
  • Cloudflare Worker/R2 deployment smoke tests, including Shell Workspace code tool execution when using mode: 'shell-workspace'.
  • Azure OpenAI, Foundry, AKS, ACA, or ARM tests as applicable.
  • Databricks App deploy, Model Serving, SQL, Jobs, Volumes, AI Search, Genie, Lakeflow, Feature Serving, OBO scope/denial, Lakebase, and System Tables through the certification evidence runner.
  • For a shared Databricks App, require two-user session-isolation evidence and one complete OBO token expiry/refresh cycle. Confirm the generated sql, genie, and model-serving scopes are consented.
  • Require MLflow tracing in App readiness and an AI Gateway inference table on the ResponsesAgent endpoint. Use the App HTTP limiter because Databricks agent endpoints do not support Gateway rate limits.
  • E2B, Daytona, Modal, Kubernetes, or other sandbox provider tests as applicable.

API and release policy gate

For every public release:

  • Publish and follow a SemVer/deprecation policy.
  • Document supported subpaths, deployment requirements, and behavioral constraints clearly.
  • Provide migration guides for minor versions with behavioral changes.
  • Generate public API reference from JSDoc.
  • Keep example projects runnable against the published npm packages.
  • Use the protected sdk release scope when an independently versioned SDK/CLI package cut must ship while a separate Databricks candidate is awaiting live certification. The scope publishes the SDK before the CLI consumer and cannot include the Databricks package.

Record the command output, artifact digest, configuration version, and credentialed test evidence with the release. For Databricks, use the authoring certification guide and certification evidence file.