Self-hosting

The Orchestate runtime is one artifact, three ways: fully managed on Cloudflare, inside your own Cloudflare account, or fully air-gapped on open-source workerd (Apache-2.0). workerd runs the same code as the hosted platform, so you keep the same JSON machine definitions, SDK, and HTTP surface with no platform lock-in and no third-party FSM gateway in the path.

The Offline (Enterprise) tier is the supported path for self-host and air-gap deployments. Machine instances and their state live in infrastructure you control — Durable Objects when you deploy on Cloudflare, or the equivalent local/air-gapped workerd process when you run offline.

Why workerd (Apache-2.0)

Orchestate's engine is its own pure-TypeScript finite-state-machine implementation (workers/runtime/src/fsm.ts). It does not depend on any external state-machine vendor. The runtime Worker targets the open workerd engine — the same Apache-2.0 runtime Cloudflare Workers use — which means:

No source-available trap — workerd is Apache-2.0; you can run it under terms that stay open.
Same artifact everywhere — managed, customer Cloudflare account, or air-gapped workerd all execute the same Worker code.
Customer-owned infrastructure — the self-host and air-gap paths sit behind your account, your bindings, and your access policy.

Who it is for

Offline is the Enterprise, self-hosted deployment option. It is designed for teams whose requirements rule out the multi-tenant hosted service:

Air-gapped or isolated environments — the runtime ships to a Cloudflare account you control, or to a workerd process you run, with no dependency on the shared orchestate.wentzel.ai origin for instance execution.
Data-residency requirements — instance state stays in Durable Object storage within your own account and region footprint (or on local workerd storage when air-gapped).
Enterprise governance — you own the deploy, the bindings, and the access policy around the runtime Worker.

Offline is sold separately from the hosted plans. See the pricing page for tier comparison, and contact sales to request source access and start an Offline engagement.

Architecture

The self-hosted deployment is a single Worker named orchestate-runtime, designed to run on Cloudflare Workers or on open-source workerd. It registers a Durable Object class, MachineInstance, bound to the namespace MACHINE_INSTANCE. Each running machine instance is one Durable Object: the FSM's current state and context are persisted in that object's storage, so an instance keeps its place across requests and Worker restarts.

Your Orchestate console reaches the runtime through a Cloudflare service binding named RUNTIME (or the local workerd equivalent). When the console creates an instance, sends an event, reads state, or opens the live inspector WebSocket, it calls the runtime Worker over that binding, which routes the request to the correct MachineInstance Durable Object.

orchestate-runtime — the entry Worker; routes requests to instances.
MachineInstance (bound as MACHINE_INSTANCE) — one Durable Object per instance; holds the authoritative state in DO storage.
RUNTIME— the console's service binding pointing at the deployed runtime Worker.

Note — the runtime matches the hosted service: it evaluates guard expressions; folds assign into context; runs entry / exit / transition action lists; executes log, http (SSRF-screened), and emit (signed webhooks); and supports after timers plus saga compensation. See Machine definitions for the full schema.

Prerequisites

A Cloudflare account with Durable Objects enabled — every machine instance is backed by a Durable Object — or a local/air-gapped workerd install for fully offline runs.
The Wrangler CLI for building and deploying the Worker (and for local workerd-backed wrangler dev).
Node.js installed locally to run Wrangler and the build.
Source access to the runtime Worker, provided as part of your Offline engagement (contact sales).

Deploy steps

The runtime ships with a wrangler.jsonc that declares the Durable Object binding and its migration. The key fields are shown below — the durable_objects binding for MachineInstance, a migration tag that registers the class as a new class, compatibility_date 2025-03-01, and the nodejs_compat compatibility flag:

{
  "$schema": "https://json.schemastore.org/wrangler.json",
  "name": "orchestate-runtime",
  "main": "src/index.ts",
  "compatibility_date": "2025-03-01",
  "compatibility_flags": ["nodejs_compat"],
  "durable_objects": {
    "bindings": [
      {
        "name": "MACHINE_INSTANCE",
        "class_name": "MachineInstance"
      }
    ]
  },
  "migrations": [
    {
      "tag": "v1",
      "new_classes": ["MachineInstance"]
    }
  ],
  "observability": { "enabled": true }
}

Your copy also defines per-environment (dev, staging) overrides; the fields above are what matter for a production deploy.

Then authenticate Wrangler against your Cloudflare account and deploy the Worker:

# Authenticate Wrangler with your Cloudflare account (one time)
wrangler login

# Deploy orchestate-runtime + register the MachineInstance Durable Object
wrangler deploy

# Local / air-gapped: same artifact on open-source workerd
wrangler dev

The first deploy applies the v1 migration, which creates the MachineInstance Durable Object class in your account. Subsequent deploys reuse it. For air-gapped workerd, use the Offline engagement package and run the same Worker under workerd without a Cloudflare account dependency for instance execution.

Finally, point your console's RUNTIME service binding at the deployed orchestate-runtime Worker so the console routes instance creation, events, state reads, and the inspector WebSocket to your self-hosted runtime instead of the hosted service.

Support

Note — the Offline tier is sold with source access and dedicated support. The runtime Worker source, workerd deploy guidance, and an ongoing support relationship are all part of the engagement — start by reaching out via sales.