Skip to main content
When you publish a workflow, it gets its own Runner page: a simple form built from your User Input nodes. Each input node becomes a field. Fill in the fields, hit run, and review the history of past runs — without ever reopening the editor or rewiring anything. The Runner is for using a workflow, not building it. The canvas is where you experiment; the Runner is where you (or anyone you share it with) press the same button again and again.

​
What a Runner run does

A Runner run executes exactly like a full run in the editor — same engine, same nodes, same result. The Runner is just the published front door wrapped around it. On top of running the graph, it also:
  • Handles auth — gates who can run based on the visibility you chose at publish time.
  • Maps inputs — takes the caller’s form values and feeds them to your User Input nodes.
  • Applies the creator fee — adds your run price on top of compute, if you set one.
The Runner never changes the workflow’s logic. It only collects inputs and triggers the run — the wiring you built in the editor is exactly what executes.

​
Also an API

Publishing the workflow exposes it as an API endpoint too. The Runner page is the human front door; the endpoint is the code front door. Your app or a scheduled job can trigger the same run, with the same inputs, and get the same result back.

Editor vs Runner

Where you build versus where you rerun — and why they’re separate surfaces.

Running the full workflow

What a full run actually executes — the engine the Runner sits in front of.