This is your handbook for running Binions day to day. Binions is not a cloud service you log into — it is a set of background services running on one Linux host that you operate yourself. This section is the operator's manual: how to start and stop services, read their logs, watch their health, back up their state, keep them secure, and tune them for your hardware.
Once Binions is installed, you do not interact with thirteen separate programs by hand. You drive the whole platform with the same Linux tools you already use for any service — systemctl and journalctl — plus one purpose-built operator command, binions-cliconsole. Everything below is built on that foundation, so if you are comfortable administering a Linux box, you already know most of what you need.
Good to know. Binions is single-host by design. There is no cluster to orchestrate, no control plane to keep online, and no external dependency to reach — the services, their state, and your data all live on the one machine you administer. That keeps operations refreshingly simple.
Before diving into individual tasks, it helps to hold the whole operational model in your head. Here is everything you manage, and the tool you reach for in each case:
| What you run | Each daemon is an ordinary systemd unit named binions-<name>.service, paired with its own redis-binions-<name>.service that holds that daemon's private state. The operator console, binions-cliconsole, is an on-demand command — not a service that stays running. |
| How you control it | systemctl for lifecycle (status, start, stop, restart, enable) and journalctl -u <unit> for the systemd log of any unit. |
| How you check health | Every daemon serves /health/live, /health/ready, and a Prometheus /metrics endpoint on a loopback address (127.0.0.1:91xx). For a single overview, binions-cliconsole status polls every daemon and prints one readiness table. |
| Where the logs are | Daemons emit structured events; the logger service writes them as JSON Lines to /var/log/binions/<service>/events.jsonl (and everything is in journald too). You read them with jq and follow a whole run by its correlation id. |
| How you see traces | Distributed tracing is opt-in. Enable it per daemon and spans flow to a bundled Jaeger UI, reachable on your LAN. Logs and traces share a trace id, so you can pivot between them. |
| How state is protected | A backup script runs automatically every night and captures the database, every daemon's Redis state, and your configuration. Restore is the same steps in reverse. |
| How it is secured | A default-drop firewall, hardened service sandboxes, loopback-only health and admin endpoints, and on-disk secret files — never inline credentials. Administration is LAN/local by design. |
| How you make it faster | Tuning is per-daemon configuration — batch sizes, memory caps, schedule tick rate. Because Binions is single-host, scaling up means a bigger host, not more nodes. |
One command to remember. When something feels off, start with
binions-cliconsole status. It rolls every daemon's readiness into a single table, so you can see at a glance which service needs attention before reaching forjournalctl.
Each page below covers one operational area in depth, with the real commands and configuration you will use. Work through them in order the first time, then treat them as reference:
Most operators settle into a simple cadence rather than watching the platform constantly:
binions-cliconsole status to confirm every daemon is ready. The systemd watchdog already restarts any daemon that hangs, so this is a quick confidence check rather than a chore.This section assumes Binions is already installed and the services are configured. For the bigger picture and the underlying settings, start here: