Running Flows

The editor runs your flow with the real runtime: press Run and the bundled octo binary starts it with hot reload, streaming its logs into the console. You design, run, and iterate without leaving the browser.

Save

Save (or ⌘S) writes the flow as a .yaml file into your mounted directory — the same YAML shown in the editor's YAML view, nothing more. The flow title becomes the filename on the first save (slugified, e.g. "Order intake" becomes order-intake.yaml); changing the title later renames the file on disk.

Because the files are plain runtime configs, everything the editor saves also works outside the editor: octo run -config order-intake.yaml runs it directly. See Running locally.

Run

Run renders the current document and starts the runtime as octo run -config <file> -watch. The button is enabled only when the document is valid; when it is blocked, hover it to see the list of issues to fix.

While the flow is running:

• The console expands and streams the runner's output live, line by line.
• Edits in the editor are pushed to the running config after a short pause (about two seconds), and the runner hot-reloads — you see the change take effect without restarting. Invalid intermediate states are held back, so the live run never reloads a broken config.

Note that Run executes the document as it is in the editor — you don't have to Save first, and saving is still what persists the flow to disk.

The console

The console is the docked panel at the bottom. It shows the runner's version, opens automatically when a run starts, and can be collapsed to its header or resized by dragging its top edge. It has four tabs:

• Logs — the running integration's output, streamed live. Auto-scrolls while you are at the bottom of the stream; the trash button clears the display.
• Problems — validation issues and the reasons a run is blocked. Click one to select the block it belongs to.
• Output — the result of a single flow you invoked, or the message captured at a breakpoint.
• Dev .env — local values for the variables your flows declare (below).

Problems and Output belong to the other way of running a flow — invoking one on its own, with a test input, and stopping it wherever you like. See Debugging flows.

The Dev .env tab

Flows declare the environment variables they need in their env: block (with optional defaults). The Dev .env tab is where you give those variables local values for development — API keys, connection strings — without putting them in the flow file.

• The tab lists every declared variable, plus any extra keys already present in the file; values are shown in the clear (use the eye toggle to mask them when screen-sharing).
• Values are stored in a single .env.dev file next to your flows in the mounted directory — not in the browser. One .env.dev is shared by all flows in the directory.
• On Run, .env.dev is staged into the run and loaded by the runtime; a variable you leave blank falls back to its declared default.

Because .env.dev lives in your flows directory, runs started by the MCP server pick up the same values. If the directory is a git repository, add .env.dev to .gitignore.

Test URLs for HTTP flows

When the running flow serves HTTP (its config declares HTTP_PORT), the editor exposes it through a test URL like http://localhost:3000/editor/runs/<id>/, shown as a link in the console header with a copy button. Requests to that URL are proxied to the running integration, so it works through the editor's own port — you don't need to publish any extra container ports to try your endpoints.

Stopping and restarting

Stop replaces Run while a flow is running. It terminates the runner (gracefully first, forcibly after a few seconds) and cleans up the rendered config and staged resource files. Press Run again to start a fresh run of the current document. A run whose editor has been idle for an hour is also stopped and cleaned up automatically in the background.

Each browser gets its own runner (keyed by a cookie), so two windows can run different flows side by side without disturbing each other.