These are the core words used across the Binions documentation. Keep this page handy as a quick reference while you read the rest of the docs — every term here is defined in one plain sentence, with links to the pages where it is explained in full.
Tip. If a term sends you somewhere deeper, follow the link. This page is a map, not the territory — each concept has a full page behind it.
| Binion | One of the platform's background services — the building blocks of Binions; the full set today is 13. |
| Daemon | A long-running background service managed by systemd; each binion is a daemon. Every daemon processes incoming work concurrently, so a slow operation never blocks the others. |
| Set | The full collection of all 13 binions on one host, and the unit of licensing. |
| Single-host | Binions runs entirely on one Linux machine; there is no cluster. |
| Event bus | The internal channel daemons use to talk to each other over localhost. |
| Redis Streams | The append-only log feature of Redis used as the event bus, with one Redis instance per daemon. |
| Playbook | A YAML file that pairs a trigger with a sequence of steps and an optional execution mode (saga or async). In saga mode each step waits for its result before the next begins; in async mode steps fire immediately so several can run concurrently. How you automate with Binions. |
| Trigger | The event that starts a playbook run — an incoming email, a schedule firing, an HTTP request, system boot, and so on. |
| Step | One action inside a playbook. A step is exactly one of four kinds: run (invoke a daemon operation), parallel (run several operations at once), loop (a bounded, counted repeat), or wait_for (block until a specific response arrives). |
| Saga mode | The default execution mode: steps run one after another, and each run step waits for its response before the next step starts. Earlier results are available to later steps as ${prev}. |
| Async mode | An execution mode in which run steps fire and forget — they emit their action and move on without waiting. You collect a result later with an explicit wait_for step, which lets one playbook fan out many actions at once and join only the results it needs. |
| Operation (verb) | A generic capability a daemon performs — for example, writing a row to a database — invoked from a playbook step. |
| Framework | The shared Rust code every daemon is built on — handlers, health checks, the outbox, and so on. |
| Service user | The dedicated, low-privilege Unix user each daemon runs as, for example loggersvc. |
| systemd unit | The service definition systemd manages, named binions-<name>. |
| cliconsole | The operator command-line tool (binions-cliconsole) for status, validating playbooks, and emitting events. |
| Traefik | The bundled edge router that handles inbound HTTP/HTTPS and TLS. |
| MinIO | The bundled S3-compatible object store, used for backups and file storage. |
| Jaeger | The bundled distributed-tracing system. |
| Naming convention | The same daemon appears three ways: <name>-service (project), binions-<name> (systemd unit), and <name>svc (service user). |
Several of the terms above touch the same idea: Binions does work concurrently. Each daemon handles many incoming actions at the same time through a bounded worker pool, and the playbook engine can keep many runs in flight at once. A slow step — a long network scan, an SSH command — never holds up unrelated work.
Concurrency never reorders things that must stay in order: actions aimed at the same resource (the same schedule, the same page, the same route, the same device) are still processed one at a time, in order. Only independent actions overlap. The two playbook modes give you direct control over this — saga keeps a single run strictly sequential, while async lets one run fan out and overlap its own steps.