pipo. docs

Dashboard

The dashboard is the visual way to watch and operate your pipelines, and to build new ones. The engine serves it at /ui on its gateway. It's static files talking to the engine's REST API and event stream, so everything it does is also available from the CLI and the API.

pipo ui                       # starts the engine if needed, prints the URL and opens it
pipo ui --no-open             # only print the URL
pipo ui --workspace ~/pipes   # where the builder saves new pipelines (when it starts the engine)

pipo ui --json prints {url, started, pid, workspace}. An open dashboard keeps the engine awake: the idle clock only starts once the last tab closes.

The top bar has ๐Ÿ  Pipelines, ๐Ÿงฎ Tasks, ๐Ÿ› ๏ธ Builder, ๐Ÿ”‘ Agents, ๐Ÿค– Bots and โš™๏ธ Settings, the engine's status, the live event stream's status, ๐Ÿ‘ค with the owner's name (it opens Settings), and ๐ŸŒ— to switch between the light and dark themes (it follows your system until you pick one). Animations respect your system's reduced-motion setting.

Pipelines#

The home page (#/) lists every pipeline the engine knows as a card: its state, its version, packets accepted, delivered and pending, the dead-letter count, throughput per minute, CPU and memory, and the lifetime remaining, counting down live when the pipeline has a TTL.

Below them, ๐Ÿงฐ Ready to run lists the .pipo files in the workspace that aren't running, each with โ–ถ๏ธ Run and โœ๏ธ Edit. โœจ New pipeline opens the builder on a fresh draft.

A pipeline's page#

Click a card to open the pipeline (#/p/<name>). Its header has the controls, the counters and โœ๏ธ Edit, which opens the file in the builder. Edit works even before the pipeline has a journal (it never started, or failed to start).

ControlEffect
โธ๏ธ Pause / โ–ถ๏ธ ResumePause processing (inputs keep journaling) or resume it.
๐Ÿšฐ DrainStop taking input, finish what's in flight, then stop. Asks first.
โน๏ธ StopStop the pipeline. Packets in flight stay in the journal and resume on the next start. Asks first.
๐Ÿ”„ RestartStop, then start the same file again. Asks first.
๐ŸŒฑ StartStart a stopped or failed pipeline (in place of Stop).

The page has five tabs. A tab that can't load shows its error in place of its content.

๐Ÿ—บ๏ธ Overview#

  • The live graph. The pipeline drawn from its definition, with counters on each node (in, ok, failed, filtered) and error badges. Packets travel along the edges as they flow. Click a node to see its counters.
  • ๐Ÿ”€ Graph | ๐Ÿ™๏ธ City. The same pipeline as a small isometric town: each node is a building whose shape says what it does, and each wire is a coloured data lane. Live events send a van down each lane a packet takes, and show retries (๐Ÿ”), dead letters (๐Ÿ’ฅ), filtered packets (๐Ÿงน) and deliveries (โœ…) at their building. Click a building for its counters. Buildings can be moved, and the town is read-only otherwise. Your choice of view is remembered per browser.
  • ๐Ÿงช Send a test packet. Type JSON and push it into the running pipeline (POST โ€ฆ/push). It runs for real: taps fire and the output is written.
  • ๐Ÿ“ฆ Recent packets, with ๐Ÿ” Follow the last one. Click a packet to open it in the inspector.

๐Ÿ“œ Logs#

The tail of the runner's log (<home>/logs/<name>.log), followed live: the same lines as pipo logs -f.

๐Ÿค– Agent#

  • ๐Ÿ“ Proposals: each change proposal with its status, author (๐Ÿง‘ human or ๐Ÿค– agent), reason, size of the change and the version it became. Proposals come from the builder's Apply live, pipo proposals โ€ฆ propose and agents.
  • ๐Ÿค– Agent activity: packets handed to the agent (then: agent, stalls with on_stall: handle) and why, how each was resolved and by whom, and every applied version.

See Agents as operators and Live changes and proposals.

๐Ÿ’€ DLQ#

The dead-letter queue: each packet, the step it failed at, its attempts and error. ๐Ÿ” Replay puts one packet back in flight at the step it failed on; ๐Ÿ” Replay all replays them all. Click a packet to inspect it. See Recovering packets.

๐Ÿ•ฐ๏ธ Versions#

Every version with its author, reason, creation time and pending packets, the current one marked โญ current. ๐Ÿ”Ž diff vs vN shows a version's diff against the current one, and โช Roll back runs an earlier version again, as a new version, after a confirmation. See Versions and rollback.

Packet inspector#

#/p/<name>/<packet_id> traces one packet through every step, like pipo inspect: its version, source, receive time, key and total time, then one entry per step with its event, duration, attempts and time.

  • The first step shows the data the packet came in with.
  • Each later step shows only what it changed: the top-level keys it set or changed (โœ๏ธ changed), or data unchanged. Keys a step dropped show as removed: โˆ’ key, never as null, since null is a value a step can really write.
  • Errors show on the step that failed.

On a delivered or filtered packet, each node step has ๐Ÿ” Rerun from here. It shows the rerun plan (the steps that will run again, flagged when they call an agent again, reach outside again or write again) and runs it after you confirm. See Recovering packets.

๐Ÿงฎ Tasks#

The task manager (#/top) lists every pipeline with its state, runner pid, CPU, memory, process count, throughput and pending count. It refreshes every 2 seconds and sorts by CPU. CPU and memory cover the runner's whole process tree, including agent CLIs it runs: CPU is a percentage of one core, summed, so it can pass 100. Each row has the pipeline's controls. Stop, drain and restart ask first.

๐Ÿ”‘ Agents#

What agents do on this engine (#/agents), and what waits for you:

  • Waiting for your approval: pipelines agents wrote with create_pipeline. Each shows the agent, its reason, what the pipeline reaches outside its folder (runs programs, sends data out, spends on agents, listens for requests, reads or writes files), and every file it wrote, the .pipo source open. โœ… Approve, โ–ถ๏ธ Approve & start or โŒ Reject (with a reason the agent sees). See Agents that build pipelines.
  • Changes waiting for you: proposals agents made to pipelines agents wrote, which are held for you. ๐Ÿš€ Apply or reject them.
  • Connected agents: OAuth grants, with their scope, pipelines and when each was last used, and ๐Ÿ”Œ Disconnect to revoke one. Static tokens from config.yaml are listed too.
  • Pipelines agents wrote: the ones you already approved or rejected.
  • Auto-approve agent pipelines: a toggle for engine.mcp.auto_approve, saved to config.yaml.

Connecting an agent#

When an MCP client connects over OAuth (see Agents as operators), your browser opens Connect an agent (#/connect/<id>). It shows the client's name (its own claim, which Pipo can't check) and where the token goes, a program on this machine or a website. You choose the scope (the one the client asked for is preselected; author is flagged), all pipelines or a list, and the name its actions are recorded under. โœ… Approve sends your browser back to the client with a one-time code; ๐Ÿšซ Deny tells the client no. A request waits 10 minutes.

๐Ÿค– Bots#

The Telegram bots of this Pipo home (#/bots): add, edit, rename, test, make one the default, and remove. A token is typed into a password field and never shown again. A token can also be a reference (op://โ€ฆ or env:โ€ฆ). Bots are stored in <home>/bots.json, and a change applies from a pipeline's next start. See Telegram bots.

โš™๏ธ Settings#

  • ๐Ÿ”Œ Engine: its pid, address and start time, with ๐Ÿ”„ Restart engine and โป Stop engine.
  • ๐Ÿ‘ค Owner: the owner's email, with ๐Ÿ“จ Send test email once engine.mail is set; ๐Ÿ”‘ Change password; ๐Ÿ‘‹ Log out and ๐Ÿšช Log out everywhere. With engine.auth: open it says there is no login. See Owner and remote access.
  • ๐Ÿ“ Workspace: the folder the builder saves new pipelines in, and where ๐Ÿงฐ Ready to run looks for files. Pick one by walking folders from the current one, or type a path. A missing folder can be created. The choice applies at once and is saved as engine.workspace in config.yaml, so the next engine uses it too. Pipelines already saved stay where they are.

The workspace defaults to the folder the engine was started from. pipo ui --workspace <dir> or pipod --workspace <dir> set it for one engine, and a choice made here wins over both.

When the engine is down or out of date#

  • Offline. When the engine can't be reached (it went to sleep, or was stopped), the dashboard shows The engine is napping ๐Ÿ˜ด with the command to wake it, and reconnects by itself once it's back.
  • Stopping the engine. โป Stop engine (on ๐Ÿงฎ Tasks and โš™๏ธ Settings) asks first, then stops it as pipo engine stop does: pipelines drain, detached runners keep running, crashed pipelines are remembered. The page then shows the stopped screen with the command to start it again.
  • Out of date. After you update Pipo, the engine still runs the old code. The dashboard notices and shows a banner with ๐Ÿ”„ Restart now: the old engine finishes what's in flight and stops, a fresh one starts at the same address (reattaching detached runners and starting the handed-over pipelines again), and the page reloads by itself. pipo ui prints the same warning. Per-start options (--listen, --ttl) aren't carried over, and a paused pipeline starts again active.

Security#

The dashboard needs the owner's login. The first visit creates the owner with a setup code (#/setup; pipo ui fills it in), and after that a 401 sends you to Log in (#/login) and back. Forgot your password? (#/forgot) emails a reset link when engine.mail is set, and otherwise names pipo owner reset. See Owner and remote access. It answers only on 127.0.0.1 unless you expose the engine, and only to requests whose Host is a loopback name or engine.public_url's host. Pages from other origins are refused, the session cookie is SameSite=Strict, and every API POST must be JSON. A web page you visit can't drive your engine. Data from pipelines is always rendered as text.