Skip to main content
Fabro provides two interfaces — a CLI for local development and an HTTP API for production use. Both share a common workflow engine.

Shared engine

At the core of both modes is the WorkflowRunEngine. It parses the DOT graph, walks nodes, dispatches to handlers (agent, command, human, etc.), selects edges, and checkpoints after each stage. The engine is parameterized by an Interviewer trait that controls how human-in-the-loop questions are presented — terminal prompts in CLI mode, HTTP request/response in API mode.

CLI mode

fabro run workflow.fabro --goal "Implement the login feature"
The CLI parses the workflow, creates the engine with a ConsoleInterviewer, and executes synchronously. Events are printed to stderr, progress is shown with terminal indicators, and human-in-the-loop questions are answered via interactive terminal prompts. When the run finishes, the process exits. CLI mode is ideal for:
  • Local development and iteration on workflows
  • One-off runs and debugging
  • Scripting and CI/CD pipelines

API mode

fabro serve
fabro serve starts an HTTP server (default 127.0.0.1:3000) backed by SQLite for run persistence. Runs are submitted via the REST API and executed asynchronously.

Configuration

The server reads ~/.fabro/server.toml for default settings (model, sandbox, variables, authentication). This file is live-reloaded — changes take effect within seconds without restarting the server. Key server config options:
SettingDescription
api.host / api.portBind address (default 127.0.0.1:3000)
api.authentication_strategiesAuth methods: jwt, mtls, or both
api.tlsOptional HTTPS with cert/key/CA paths
max_concurrent_runsScheduler concurrency limit (default 5)
[llm], [sandbox], [vars]Defaults applied to every run (overridable per-run)

Run lifecycle

  1. SubmitPOST /runs with a DOT workflow source. The run is created with status Queued and the response returns immediately with the run ID.
  2. Schedule — A background scheduler promotes queued runs to Running in FIFO order, up to the concurrency limit.
  3. Execute — The engine walks the graph, streaming events to all subscribers.
  4. Complete — The run transitions to Completed, Failed, or Cancelled.

Event streaming

The API streams run events via Server-Sent Events (SSE). Every significant action — stage starts, LLM calls, tool invocations, edge selections — is emitted as a structured JSON event. The web UI uses this endpoint for real-time run monitoring. Any HTTP client that supports SSE can subscribe. See the run events endpoint in the API reference.

Human-in-the-loop

In API mode, human-in-the-loop questions are served over HTTP instead of terminal prompts. The engine blocks the current stage until an answer is received, then continues execution. See the Human-in-the-Loop API reference for the polling and answer submission endpoints.

Authentication

API mode supports two authentication strategies, configurable in server.toml:
  • JWT — EdDSA-signed tokens (used by the web UI)
  • mTLS — Mutual TLS with client certificates (used for service-to-service communication)

Demo mode

Demo mode is per-request: send the X-Fabro-Demo: 1 HTTP header to get static mock data with authentication disabled. The web UI sends this header automatically when configured with FABRO_DEMO=1. This lets you explore the UI without API keys or real workflow execution.

Web UI

The web UI is a React app (apps/fabro-web) that connects to the API server. Start it alongside fabro serve:
fabro serve                        # API on port 3000
cd apps/fabro-web && bun run dev   # Web UI on port 5173
The UI provides:
  • Run board — List and monitor all runs
  • Run detail — Real-time stage progress, event stream, diffs, usage stats
  • Start new run — Submit a DOT workflow from the browser
  • Human-in-the-loop — Answer agent questions through the web interface
  • Sessions — Interactive chat interface (coming soon)
  • Insights — SQL-based analysis across runs via DuckDB

Comparison

See Server Mode for a full feature comparison between standalone and server mode.