Shared engine
At the core of both modes is theWorkflowRunEngine. 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
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 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:
| Setting | Description |
|---|---|
api.host / api.port | Bind address (default 127.0.0.1:3000) |
api.authentication_strategies | Auth methods: jwt, mtls, or both |
api.tls | Optional HTTPS with cert/key/CA paths |
max_concurrent_runs | Scheduler concurrency limit (default 5) |
[llm], [sandbox], [vars] | Defaults applied to every run (overridable per-run) |
Run lifecycle
- Submit —
POST /runswith a DOT workflow source. The run is created with statusQueuedand the response returns immediately with the run ID. - Schedule — A background scheduler promotes queued runs to
Runningin FIFO order, up to the concurrency limit. - Execute — The engine walks the graph, streaming events to all subscribers.
- Complete — The run transitions to
Completed,Failed, orCancelled.
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 inserver.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 theX-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:
- 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