Skip to content

What Fanout is

Fanout is a single self-hosted binary for OpenTelemetry. One Go process accepts OTLP over gRPC and HTTP, writes telemetry to disk as Parquet, answers queries with DuckDB, evaluates alert rules, serves a chat investigator and MCP tools, and hosts the browser client.

The point of that list is that it is one list. A conventional deployment of the same capability is a collector, a storage backend, a query layer, a dashboard service and an alertmanager, each with its own configuration, failure modes and upgrade cadence. Fanout is one process with one configuration and one thing to restart.

PartWhat it does
OTLP ingestAccepts traces, logs and metrics on gRPC and HTTP
StorageWrites Parquet to a local data directory; no external database
QueryDuckDB in-process, over the Parquet it wrote
AlertsEvaluates persisted rules on a fixed interval against rollups
InvestigatorA chat agent working from the same typed query tools
MCP serverExposes those tools to an external agent
Browser clientServed by the same process, from the same binary

Fanout is not a hosted service, and it is not a collector. It sits where the backend sits: your SDKs or your existing Collector export to it.

It is also not a multi-tenant platform. Namespaces scope telemetry queries so one instance can hold several services’ data without them running together, but a namespace is not a user, an organisation or an authorisation boundary. An instance is a trust domain.

Teams that want their telemetry on their own hardware, with a small enough operational surface that observability does not become its own on-call rotation. The reference deployment target is a single small VM.

Fanout is pre-release. It changes without migration paths, and the shape of things that already run may still move. The capabilities page is the account of what is settled and what is not; it is worth reading before building anything durable on top.