itero

itero (Latin: “I repeat”) runs workflows on one machine. A workflow is a few lines of JSON: what starts it, and the steps it takes. A step is an action, a small executable file in any language, or another workflow.

{
  "on": [{ "event": "mail.received" }],
  "steps": [
    { "#ai": { "ask": "Summarize this mail in one line, and rate it: important, normal or spam." } },
    { "#notify": { "on": [{ "$rating": "important" }], "title": "$from", "text": "$summary" } }
  ]
}

A mail arrives; #ai, a few lines of shell around curl, asks an AI assistant to read and rate it, and prints {"summary": "...", "rating": "important"} into the run’s state. The rating decides the rest: you hear only about the important mails, and the spam and the ads pass quietly.

Small files

A workspace is a folder: workflows as JSON, actions as executables, sources as executables. No action descriptions, no expressions.

Messages, schedules and files

A message from an app, a source or itero emit starts runs, and reaches the runs waiting for it; a schedule or a watched file starts them too.

The Unix way

An action reads its values as environment variables and prints JSON; its exit code says how it went. curl, jq and the shell do most of the work.

Kept up

Every message and answer is in a SQLite journal, and every step in a JSON log. A lost step runs again; a watchdog restarts the daemon, which starts at login.