Skip to main content
Three host surfaces ship from packages/server, each a tighter fit for a different deployment:
  • startServer: self-contained HTTP server with REST routes for run lifecycle, SSE event streams, and approvals; one server, many workflows by path. Use it for a plain HTTP API with no client SDK.
  • createServeApp: Hono app bound to one already-loaded workflow and run; what bunx smthrs up --serve mounts. Compose it into a larger Hono app or call app.fetch in tests.
  • Gateway: headless control plane. Authenticate once, stream events over WebSocket with resume-on-reconnect, decide approvals, inject signals, run cron schedules, and serve many registered workflows: the surface the Gateway client and custom UIs talk to.
createServeApp needs a SmithersDb adapter and a loaded SmithersWorkflow, both from your workflow module (new SmithersDb(workflow.db)). Gateway is constructed with new Gateway(opts), then you register() workflows and listen().

startServer

Boots a listening http.Server exposing REST run lifecycle, SSE streams, and approval routes. Synchronous: returns the bound server immediately.
ServerOptions
object
A listening Node http.Server, with headersTimeout/requestTimeout applied to bound slow header/body uploads. Full route table (run start/resume/cancel, SSE events, frames, approvals, signals, /metrics) lives in Server Mode.
Source index.js · ServerOptions.ts · Tests server.test.js · See also Server Mode, Control-plane deployment

createServeApp

Builds a Hono app for a single, already-loaded workflow and run: mount it with Bun.serve, route it into another Hono app, or drive app.fetch directly in tests. Backs bunx smthrs up --serve.
ServeOptions
required
object
A Hono app. Routes (/health, run status, SSE events, approvals, signals, /metrics) are documented in Serve Mode.
Source serve.js · ServeOptions.ts · Tests serve.test.js · See also Serve Mode, Server Mode

Gateway

The multi-run control plane: construct it, register() one or more workflows, then listen(). Serves RPC over POST /v1/rpc/<method> (and POST /rpc) and over WebSocket on the same origin, plus /health, /metrics, /workflows, and per-workflow webhook endpoints. RPC methods (launchRun, getRun, listRuns, submitApproval, submitSignal, cron, time-travel, and more) are documented per method; see launchRun for the request/response and scope shape they share.
register, extend, and the constructor are chainable. listen defaults to port 7331; pass path for a Unix socket. close aborts active runs, drains inflight work, and tears down connections and the scheduler.

GatewayOptions

GatewayOptions

GatewayAuthConfig

A discriminated union on mode. Runs started through an authenticated gateway expose ctx.auth = { triggeredBy, role, scopes, createdAt }.

UI config

defaults

register

Registers a workflow under key: wires up its DB tables, optional cron schedule, webhook config, and embedded UI bundle. Returns this, so calls chain. A schedule writes a cron row keyed gateway:<key>; cron-fired runs get ctx.auth.role = "system", triggeredBy = "cron:gateway", scopes = ["*"].
string
required
Workflow key; becomes the path segment for workflow-level UI and webhooks.
SmithersWorkflow
required
Loaded workflow instance.
GatewayRegisterOptions

listen / close

object
Promise<http.Server>
Resolves once the server is bound and the scheduler and event bridge have started.
Promise<void>
Aborts active runs, awaits inflight work, closes connections, and stops the scheduler and watchers.
Source gateway.js · GatewayOptions.ts · GatewayAuthConfig.ts · Tests gateway.test.jsx · See also Gateway, Control-plane deployment, launchRun, Gateway client
For the full route tables and wire shapes, see Server Mode, Serve Mode, and Gateway; exact type definitions are mirrored in Types reference.