Why one binary
Fanout packages telemetry ingest, storage, queries, alerting and the browser client in one process. The built-in agent and external MCP clients use the same typed tools to investigate that telemetry and build dashboards.
Operation
Section titled “Operation”One binary pins the runtime version, and one data directory holds telemetry and application state. Back up the complete directory and restore it with the matching binary version.
Queries read local storage. The browser, agent and alert engine share query implementations and analytical rollups. Configuration comes from environment variables, documented in the generated reference.
Resource sharing
Section titled “Resource sharing”Ingest, queries and maintenance share CPU, memory bandwidth and disk. They have separate coordination paths, but cannot scale onto separate machines. Compaction prepares merges while reads continue, then briefly gates readers while swapping files. Tune retention explains the maintenance controls.
One process is one failure domain. Stopping it stops ingest, queries, alerts and the UI. Monitor the instance from outside its host.
Deployment scope
Section titled “Deployment scope”Fanout runs on one machine; see trust domains and namespace access.
Workloads requiring horizontal ingest, replication or an object-storage tier require a backend that provides those capabilities.