Binions runs on a single host, and that is a deliberate design choice — not a limitation it has yet to grow out of. The whole platform — all thirteen binions, their private Redis instances, the chosen database backend, the HTTP edge, and tracing — lives on one Linux machine and talks over localhost. There is no cluster to stand up, no control plane to operate, and no shared state spread across nodes. When people ask how Binions “scales,” the honest answer is: you scale the one host up, you right-size each daemon to the work it actually does, and — if you genuinely outgrow a single machine — you run more than one independent install. This page explains each of those, and is candid about what Binions does not do.
Good to know. Binions is not a horizontally-clustered system. There is no node membership, no leader election, no sharding, and no shared control plane — by design. A single host keeps the architecture simple, fast, and easy to reason about. If you are looking for an “add more nodes and it spreads the load” story, that is not how Binions works, and this page will tell you what to do instead.
Because everything runs on one machine, scaling Binions comes down to two levers you can actually pull, plus one common request that the platform deliberately does not answer.
| Vertical scaling | Yes — primary path | More CPU / RAM / faster disk on the one host; raise per-daemon caps as needed |
| Per-daemon right-sizing | Yes | Lift the memory ceiling of the busy daemon(s); leave the quiet ones small |
| Workload split (separate installs) | Yes, manually | Run several independent Binions installs, each handling a slice of the work |
| Horizontal clustering | No — by design | One logical install across many nodes is not a thing Binions does |
The most important thing to understand about Binions capacity is that processing is concurrent throughout. Every daemon dispatches incoming actions using a bounded worker pool: independent actions run in parallel rather than one after another. A slow operation — a long network call, a large file transfer, a complex SQL query — no longer blocks other actions waiting behind it on the same daemon. Head-of-line blocking is eliminated.
Concurrency does not mean chaos. Actions that target the same resource — the same schedule name, the same page, the same Traefik route, the same PLC register — are still serialised in arrival order. Only independent actions on the same daemon run in parallel, so ordering guarantees are preserved exactly where they matter.
The playbook orchestrator follows the same principle at a higher level: it decouples accepting new triggers from running active playbooks, and can have hundreds of automation runs in flight simultaneously. Concurrency is bounded by configurable caps (a global in-flight limit and a per-playbook limit), not by an artificial serial ceiling. In practice, throughput scales with available CPU: more cores mean more parallel work, which is exactly why vertical scaling is the primary lever.
Tip. A single Binions host handles a high volume of simultaneous automations without special configuration. If you observe one daemon becoming a bottleneck, raise its worker-pool cap and memory ceiling; the rest of the stack keeps running while that daemon processes its queue.
A right-sized Binions host is one where CPU, RAM, and disk each have comfortable headroom for the work your playbooks actually generate. None of these has a single magic number — they depend entirely on how busy your automations are — but it helps to know what drives each one.
Tip. Start modest and measure. Binions is light at rest, so over-provisioning on day one is rarely worth it. Stand it up, run your real playbooks for a while, watch
/metricsand the memory caps, and grow the host (or lift a cap) when the numbers tell you to — not before.
Before you add hardware or change any caps, find out what is actually slow. On a single host the answer is almost always one of three things, and each daemon’s own metrics will point straight at it. Every daemon exposes a Prometheus endpoint on a loopback address, and these are the figures worth watching.
# Per-daemon metrics live on loopback only — scrape or curl them locally
curl -s http://127.0.0.1:9108/metrics | grep '^binions_'
# Throughput and outcomes by event type (handled / unhandled / duplicate / failed)
# binions_events_processed_total{kind,event_type,status}
# How long each event takes to process (histogram)
# binions_event_processing_duration_seconds{kind,event_type}
# Work waiting to be confirmed downstream — a growing outbox means a slow consumer
# binions_outbox_pending_sizeRead those numbers against the three usual culprits:
XLEN for the length of a stream and XPENDING for unacknowledged messages — since stream lag is not exposed as a Binions metric.Only once you know which of the three is hurting should you reach for more hardware or a higher cap. Adding RAM to fix a slow query, or lifting a memory ceiling on a daemon that is waiting on Redis, just moves the problem around.
Each daemon ships with a sensible memory budget enforced by systemd — a soft target (MemoryHigh) where the kernel starts reclaiming, and a hard ceiling (MemoryMax) it will not exceed. The defaults reflect each daemon’s typical job: the mailbox daemon, which buffers message bodies, gets the most room; the lightweight event routers get the least. If one daemon genuinely needs more headroom for your workload, raise its ceiling; leave the quiet ones small so they never crowd the host.
| mailbox | 768 MB | 1 GB | Buffers full message bodies and attachments |
| database | 384 MB | 512 MB | Query execution and result sets |
| playbook | 384 MB | 512 MB | Orchestrates concurrent automation runs; holds in-flight run state |
| aiinjector | 384 MB | 512 MB | Marshals prompts and model responses |
| logger | 128–192 MB | 256 MB | Batches structured log events to disk |
| datatransporter | 128–192 MB | 256 MB | Streams files between sources and sinks |
| scheduler | 96 MB | 128 MB | Time-driven triggers; little state |
| webhookcaller | 96 MB | 128 MB | Outbound HTTP calls; small footprint |
| traefiklinker | 96 MB | 128 MB | Manages edge routing config |
| dataanaliser | 96 MB | 128 MB | Lightweight event analysis |
| showman | 96 MB | 128 MB | Coordination hub; small state |
| modbus | 96 MB | 128 MB | Industrial register polling; tiny |
Caution. A memory ceiling is a safety rail, not a performance dial. Raising
MemoryMaxon a daemon that is being throttled can help; raising it on a daemon that is healthy does nothing but reduce the protection that stops a runaway from taking the host down. Change one cap at a time, restart that daemon, and confirm the effect in/metricsbefore touching another. The full procedure and the rest of the tuning knobs live on Performance tuning.
If you want to keep workloads apart — one customer’s automations from another’s, or production from staging — the Binions answer is simple: run separate, independent installs. Each install is a complete, self-contained Binions on its own host: its own thirteen binions, its own Redis instances, its own database backend, its own configuration and secrets. They do not know about each other.
A well-sized host carries a lot of automation, but if you reach its ceiling — or you simply want hard isolation between workloads — the path forward is to split into independent installs rather than to cluster. There is no horizontal clustering, so “more capacity” and “more separation” are the same move: stand up another complete Binions on another host and divide the work.
The natural lines along which to split are the ones your business already has:
You will sometimes see this described as a “multi-host” deployment. In Binions that phrase means exactly this: several independent installs, one licence each, deliberately not joined into a cluster — not one install stretched across machines. The setup steps for standing up several installs cleanly are on Multi-host installs.
The trade-off, plainly. Single-host keeps Binions small, fast, and operable by one person. The price is no automatic horizontal scaling: you scale up, or you scale out by hand into separate installs. For the self-hosted automation Binions is built for, that is a trade most operators are happy to make.
* Raspberry Pi and other 64-bit ARM hardware are supported from the public 1.0 release. The alpha packages are for 64-bit x86 (amd64) only — so a Pi or ARM host is not yet an option for splitting workloads.