A central server describes the desired state; agents bring hosts to it. Between them sits an honest reconcile loop and a single transport that works in both pull and push.
Keeper holds the registries (services, coven labels, RBAC), renders Destiny from Essence, plans incarnations and keeps the audit trail. All state lives in shared PostgreSQL and Redis, not on the instance disk, so any Keeper can serve any request: the cluster scales horizontally and survives a lost node with no shared storage.
A managed host runs a single static Go binary. It receives the rendered Destiny, compares the host’s current state with the desired one and changes only what drifted. No interpreter alongside it: core modules are compiled in, custom ones attach as plugin processes over gRPC-stdio.
Every Destiny step is idempotent: the module first reads the fact, then changes the host only if the state differs. The step yields changed=true (changed) or changed=false (already so). That signal wires steps together: “restart the service only if the config changed”.
The Keeper↔Soul channel is gRPC over mTLS. In the pull model an agent daemon holds the connection and applies the Destiny itself. In the push model the same binary runs one-shot over SSH — with no resident agent on the host. One module set, one reconcile implementation.
PostgreSQL keeps durable state (incarnations, runs, RBAC snapshots). Redis holds the volatile and hot: presence, heartbeat, leases, pub/sub. Secrets live in Vault and resolve at render time, masked on output. Splitting hot from cold is what keeps the 100k+ host target within reach.
Soul Stack