This page defines the handful of words that the rest of the documentation leans on. Binions is a small, self-hosted platform, and it uses a small, consistent vocabulary. Once these terms click, every other page — installation, playbooks, daemons — reads easily. Keep this glossary handy as you explore.
The one-line mental model. Apps and hardware emit events; you write short YAML playbooks that turn those events into actions; small background services called daemons carry the actions out — all on a single Linux host you control.
The single Linux machine that Binions runs on. Everything — every service, the internal messaging, the database — lives on this one host and talks to itself over localhost. There is no cluster to manage and no second machine to keep in sync, and a host can be anything from a Raspberry Pi* to a rack server. See the Architecture overview for the full picture.
One complete installation of Binions on one host — the whole collection of services together. The set is also the unit of licensing: you can run one set on one host for free for non-commercial use, and a second host (or any commercial use) needs a paid licence. You never license individual services; it is always the whole set. Details live in Licensing & Purchase.
A focused background service that does one job well — sending and receiving email, calling a web API, running a database query, moving a file, talking to an AI model, or reading an industrial sensor. Binions is a small suite of these daemons, and the words daemon and service mean the same thing here. You never program a daemon directly; you ask it to do work through a playbook. The full roster lives in Daemons.
The fast internal channel the daemons use to talk to one another. Because every daemon publishes to and listens on the same bus, the platform behaves like one coordinated system even though it is built from many small parts. The bus is private to your host — messages never leave the machine.
Everything that flows on the bus is a message, and messages come in a few kinds:
The standard wrapper that every message on the bus travels inside. Alongside the actual data, the envelope carries a few housekeeping fields — a unique id, the kind and version of the message, which service produced it, and a correlation id that ties together all the messages belonging to one workflow. That correlation id is what lets you trace a whole automation, end to end, in the logs.
A simple, built-in way for each daemon to report whether it is alive and ready to work. Every service answers two checks — “are you running?” (live) and “are you ready to handle requests?” (ready) — which monitoring and the system manager use to confirm the platform is healthy.
A short, readable YAML file that describes a workflow. You do not write code; you list what should happen, and Binions coordinates the daemons to make it so. A playbook deliberately uses only a tiny grammar — a trigger, an optional execution mode, and a list of steps — so you can read one in seconds without learning a programming language. Playbooks live in three folders, by purpose:
office or a table called invoices) and never see credentials, which makes them safe to share and review.See Playbooks & Automation for the full guide, and Your first automation for a worked example.
The building blocks of every playbook. The trigger says what starts the workflow — usually an incoming event, optionally narrowed by a simple filter (for example, only emails from a certain sender). The steps are the ordered list of things to do. Each step is exactly one of four kinds:
run — carry out a single daemon operation. This is the workhorse; most steps are run steps.parallel — a block of independent operations that should run at the same time rather than one after another.loop — repeat a small body of operations a bounded number of times (a counted, capped iteration), useful for fixed batches.wait_for — pause until a specific result arrives, so a later step can use it. This is how a playbook joins back up after firing work off ahead of time.A playbook also has an optional top-level mode that sets how the steps are paced:
saga (the default) — steps run in order, and each step waits for its result before the next one begins. Existing playbooks behave this way without changing anything.async — run steps fire and move on immediately without waiting, so a single playbook can launch many actions at once; you then add a wait_for step to collect just the results you care about.That is the whole grammar — a trigger, an optional mode, and a list of run / parallel / loop / wait_for steps. The full reference, with worked examples, is in Playbook anatomy.
The small set of generic actions that daemons understand. Instead of thousands of app-specific connectors, Binions exposes a compact vocabulary of plain technical verbs — extract, classify, send, move, upload — that you parameterise to fit your case. A verb describes what to do, never a particular business concept: a daemon knows how to “extract data,” not how to “process an invoice.” The business meaning lives in your playbook; the verb stays generic and reusable.
Binions handles work concurrently. Each daemon processes incoming actions through a pool of workers rather than one at a time, so a slow operation — a long network scan, a slow SSH command, a large file transfer — never holds up the unrelated work queued behind it. The orchestrator that runs your playbooks works the same way: it can keep many runs in flight at once and accept new triggers while earlier runs are still going, so throughput scales with the host’s CPU rather than hitting an artificial one-at-a-time ceiling.
Good to know. Concurrency never reorders work on the same resource. Actions aimed at the same target — the same mailbox, the same database table, the same schedule — are still carried out in order; only genuinely independent work runs side by side. A simple single-step run typically completes in about a tenth of a second.
The pattern that lets one generic verb work with many interchangeable back-ends. A broker is the part of a daemon that speaks a verb (for example, “store this file”); a provider is the specific technology behind it. The same storage verb can run over Amazon S3, a local MinIO server, or SFTP — you simply name the provider you want, and your playbook stays unchanged. This keeps the vocabulary tiny while still reaching a wide range of services. The same idea lets the mailbox service speak IMAP, MQTT, or AMQP behind a single set of verbs.
Good to know. You rarely touch brokers and providers by hand. You choose a provider once, in a provisioning playbook, and every business playbook afterwards just uses the resource by name.
* Raspberry Pi and other 64-bit ARM hardware are supported from the public 1.0 release. Binions is currently in alpha, and the alpha packages are for 64-bit x86 (amd64) only.