Visual designer

The Pipeline Designer is the visual way to author and edit a config. It renders a pipeline as a left-to-right graph — one box per route, the adapter chain stacked inside each box, and the queue/topic edges between routes — and keeps that graph in lock-step with the underlying YAML. Everything you can do in Author a config you can do here, plus you can see how messages fan out, fan in, and gate as they move through the pipeline.

Expand

The designer in action — click to expand for detail.

Close

Open it

In the web UI, go to Configs:

• New pipeline — click Design new (route /configs/new/design). You start from an empty canvas with a Start node.
• Edit an existing one — open a config and click Design (route /configs/{id}/design).

The designer is a faithful projection of the config model — it never invents structure the YAML can't express. A route is an ordered adapter chain with one inbound binding; routes connect only through queues and topics.

The three panels

• Adapter toolbox (left) — the live adapter catalog grouped by workflow package. Search it, expand a group, and drag an adapter onto the canvas — drop it on a route to append it to that chain, or on empty space to start a new route. The # toggle flips every label between its display name ("HTML to Markdown") and its raw type identifier (html_to_markdown). The panel collapses to a rail to give the canvas more room.
• Canvas (center) — the graph. Pan, zoom, select a route or adapter, and drag between connectors to wire routes. The legend (bottom-left) decodes every glyph.
• Inspector (right) — context editor for whatever is selected: pipeline settings, a route's inbound/outbound/DLQ, or an adapter's schema-generated config form (live-validated against the backend).

Design ⇄ YAML

The top bar toggles between Design and YAML. They are two views of the same config — edit either and the other re-derives. The YAML view preserves your exact source (comments, key order, formatting) round-trip, so dropping into raw YAML for something the canvas doesn't surface never reformats the file.

Reading the canvas

A route box shows its wiring inline: the inbound queue (with concurrency) sits above the adapter chain, and the outbound queues/topics sit below it. Adapters stack vertically in chain order, joined by a comb connector on the left whose downward chevrons mark the top-to-bottom flow.

Edges between routes carry small icons that tell you what actually happens at that hand-off — the part that's invisible in flat YAML. Hover any edge for a plain-English description.

Cue	Edge operation
	Queue — point-to-point hand-off, delivered to one consumer
	Topic — broadcast; every subscriber gets a copy
	Fan-out — the stage has ≥2 outbound targets
	Dynamic fan-out — the stage emits one message per item (1→N, count set at runtime)
	Fan-in — ≥2 routes produce the queue this stage consumes
	Gated / batch — the stage accumulates inputs and emits once (count, signal, or idle-timeout)
	Conditional — the outbound fires only when its when predicate matches (the predicate is shown)
	Open port — a queue/topic with no counterpart in this config (a seam to another pipeline) — not an error

The fan-out and gated/batch icons come from adapter capabilities the backend reports in the catalog, so they reflect what the adapter genuinely does, not a guess from the wiring.

Validate and save

The header shows live error and warning counts as you edit — the same validation the server runs (see the validation rules). Findings highlight the offending route or adapter.

When the graph is clean:

• New pipeline → Review & create stores it as a config.
• Existing pipeline → Save updates it.

From there the config runs like any other — start an execution from the CLI or the UI, then watch it in monitoring and lineage.

See also

• Configs — what a pipeline and a route are
• Author a config — the YAML + CLI authoring loop
• Pipeline YAML reference — the full schema and validation rules
• Adapter catalog — every adapter the toolbox lists