Binions does its work through a set of small, single-purpose background services — we call them daemons. Each one owns a single capability: storing data, sending mail, calling an API, rendering a page, talking to a factory floor. On their own they do nothing; together, orchestrated by your playbooks, they run your automations. This section is the reference for every daemon — what it does, the operations you can call from a playbook, how it is configured, and the events it emits.
Binions is event-driven. The daemons never call each other directly; they exchange small messages — events — over a fast internal bus. There are three kinds of event, and understanding them is the key to understanding the whole platform:
Action.<Domain>.<Verb>) — a request addressed to one daemon: “write this row”, “send this email”.Fact.<Domain>.<Something>) — a broadcast announcement that something happened: “mail received”, “schedule fired”. Any number of playbooks can react.Control.<Service>.<Verb>) — a runtime instruction to a daemon, such as “reload your playbooks”.You drive all of this from a playbook. A step says run: <daemon>.<operation> — for example run: database.write — and the platform turns that short, lowercase verb into the matching Action.<Domain>.<Verb> and sends it to the owning daemon. What happens next depends on the playbook’s execution mode. In the default saga mode the step waits for the daemon’s response fact before the next step starts, and that fact’s payload is available as ${prev}. In async mode, run: steps are fire-and-forget — the platform emits the action and moves on immediately, so multiple actions can be in flight at once; you collect a specific result with an explicit wait_for: step. See Playbook anatomy for the full step grammar, including parallel:, loop: and wait_for:. You only ever write the verb; the daemon does the work. The full list lives in the Verb vocabulary, and each daemon’s page below documents the arguments its operations accept.
Every event carries a correlation id. Because the trigger, every step it sets off, and every log line they produce all share one id, a complete run can be traced end to end — across every daemon — from a single identifier.
Each daemon processes incoming actions concurrently using a bounded worker pool. A slow operation — a long network call, a database query, an SSH command — does not block other actions queued behind it; head-of-line blocking is gone. Actions that target the same resource (the same schedule name, the same database table, the same Traefik route) are still serialised in arrival order, so concurrency never reorders operations on one resource. The overall effect is that many playbook runs can be in flight at once, and throughput scales with host CPU rather than any artificial serial limit.
A standard Binions set is thirteen daemons. Each is documented in full on its own page:
The daemons do very different jobs, but they are all built on one shared framework, so they look and behave the same way once you know one of them. Every daemon:
binions-<name>.service, started on demand, restarted automatically if it fails, and supervised by a watchdog.redis-binions-<name>.service) that holds its state. Nothing is shared, so one busy daemon never slows another.application.toml per daemon, with credentials kept in separate secret files rather than written inline./health/live, /health/ready and /metrics on a loopback address, and binions-cliconsole status rolls them all up into one view.Licensing is per set, not per daemon. The thirteen daemons are licensed together as one set — £1 per binion, so a full set is a one-time £13 per host; one set on one host is free for non-commercial use. At start-up each daemon performs a licence check; during early access the check is advisory — the daemon warns and starts regardless.
Across the daemons you will see two flavours of operation. Provisioning operations register a long-lived resource once — a mailbox, a database table, a storage bucket, a schedule, an HTTP route — and are usually run from a setup playbook that re-runs safely on every boot. Business operations are the day-to-day work that reacts to events and refers to those resources by the alias provisioning gave them. Keeping the two apart is what lets your everyday workflows stay free of URLs and credentials. The pattern is explained in Provisioning vs business playbooks.