Show HN: Fanout – OpenTelemetry back end in one Go binary (Parquet, DuckDB, MCP) Labstack released Fanout, a pre-release OpenTelemetry back end that runs as a single Go binary and stores traces, logs and metrics in local Parquet files with DuckDB analytics, ingesting OTLP over both gRPC and HTTP on port 7520. Fanout ships an MCP server that serves protocol versions 2026-07-28, 2025-11-25 and 2025-06-18 over Streamable HTTP, letting external agents use the same typed query tools as its built-in investigation agent, and it supports Anthropic or OpenAI as the AI provider via FANOUT_AI_PROVIDER. Labstack warns the release has no migration paths and that the browser client, built-in agent, MCP tools, dashboards and alerts are preview capabilities. Observability your agents can operate. Send OpenTelemetry to one binary, then investigate with Fanout's built-in agent or connect your own over MCP. Fanout keeps OpenTelemetry traces, logs, and metrics in one binary and one data directory, with no external storage services to operate. Fanout is pre-release and changes without migration paths; the browser client, built-in agent, MCP tools, dashboards, and alerts are preview capabilities status https://fanout.run/status/capabilities . Start with the documentation https://fanout.run or run it below. - OTLP ingest over gRPC and HTTP, with local Parquet storage and DuckDB analytics. - An investigation agent that answers questions about your telemetry in plain language. - An MCP server for external agents using the same typed query tools. - Dashboards across traces, logs, and metrics, and alerts on service error rate, latency, throughput, and log volume. docker run --name fanout -p 7520:7520 \ -v fanout-data:/var/lib/fanout/data \ -e FANOUT AUTH CODE SECRET=$ openssl rand -hex 32 \ labstack/fanout:latest Open the one-time setup URL printed by the container and create the first administrator. Fanout displays the ingest token exactly once; save it with your collector secrets. For later sign-in without SMTP, mint a 15-minute, single-use link against the running container's control database: docker exec fanout fanout login-link admin@example.com The UI, API, MCP, and both OTLP transports share port 7520 . See installation https://fanout.run/start/install for image defaults and bind-mount ownership, and first boot https://fanout.run/start/first-boot for setup and SMTP login. Install a checksum-verified release for Linux or macOS, amd64 or arm64: curl -fsSL https://raw.githubusercontent.com/labstack/fanout/main/scripts/install.sh | sh export FANOUT AUTH CODE SECRET=$ openssl rand -hex 32 fanout Set FANOUT VERSION to a release tag https://github.com/labstack/fanout/releases , such as v2026.10.23-alpha , to pin a release, and FANOUT PREFIX to choose the installation directory. Native installs bind 127.0.0.1:7520 ; set FANOUT ADDR=:7520 for remote access, then follow the same first-boot setup. A standard OTLP/HTTP exporter can use the saved ingest token: export OTEL EXPORTER OTLP PROTOCOL=http/protobuf export OTEL EXPORTER OTLP ENDPOINT=http://localhost:7520 export OTEL EXPORTER OTLP HEADERS="authorization=Bearer%20$INGEST TOKEN" For a Collector on the same private container network, the forwarding side is: exporters: otlp http/fanout: endpoint: http://fanout:7520 headers: Authorization: "Bearer ${env:INGEST TOKEN}" service: pipelines: traces: { receivers: otlp , exporters: otlp http/fanout } metrics: { receivers: otlp , exporters: otlp http/fanout } logs: { receivers: otlp , exporters: otlp http/fanout } Use an existing otlp receiver, set INGEST TOKEN , and replace fanout with the Collector's reachable private hostname. OTLP/gRPC uses localhost:7520 locally; see send telemetry https://fanout.run/start/send-telemetry for TLS and HTTP/2 setup. Select FANOUT AI PROVIDER=anthropic and inject ANTHROPIC API KEY , or select FANOUT AI PROVIDER=openai and inject OPENAI API KEY , then restart Fanout; the selected provider requires its key at startup. With no provider, chat is disabled and the other features still work. See AI settings https://fanout.run/reference/settings/ai . Set FANOUT PUBLIC URL to your stable, externally reachable HTTPS origin, then point a remote MCP client at that origin's /mcp endpoint. The client discovers and registers through OAuth; you authorize its scopes in the browser. Fanout serves MCP 2026-07-28 and, through the initialize handshake, 2025-11-25 and 2025-06-18 over Streamable HTTP. See connect over MCP https://fanout.run/guides/connect-over-mcp for setup and permissions. | If you use | Where Fanout differs | |---|---| | Grafana with Loki, Tempo, and Mimir | That stack keeps a service and a query language per signal, plus object storage underneath. Fanout keeps one process, one data directory, and one typed contract across all three signals, at the cost of the horizontal scale those components are built for. | | SigNoz | Both are OTLP-native and self-hosted. SigNoz composes a collector, ClickHouse, and query services; Fanout compiles ingest, authoritative Parquet storage, indexed trace reads, DuckDB analytics, alerting, and the browser client into one binary. | | Jaeger | Jaeger covers traces and expects a storage backend you run separately. Fanout ingests traces, logs, and metrics into the same store, with nothing else to deploy. | | Prometheus with Grafana | Prometheus pulls metrics and is excellent at them. Fanout accepts pushed OTLP for all three signals and is built around investigating a specific incident rather than maintaining long-range metric series. | | Datadog , Honeycomb , Grafana Cloud | Those are managed services: someone else runs the storage, the scaling, and the upgrades, and your telemetry leaves your network to get there. Fanout is a binary you run, on data that stays on your disk. | | An OpenTelemetry Collector piped into ClickHouse | The same shape, assembled by hand: collector, database, dashboards, and the glue between them. Fanout is that assembly as one program, with an agent and an MCP server already wired to the same query contract. | Fanout is a single node. It has no clustering, no replication, and no object tier; a deployment that outgrows one machine's disk and CPU has outgrown Fanout. One process contains ingest, storage, query, alerts, the agent, MCP, and the React client. Browser and agent clients share a typed observability contract. Parquet holds telemetry, DuckDB query state is rebuildable, and SQLite holds transactional product state. See how storage works https://fanout.run/explanation/storage-model for durable ingest, indexed reads, and compaction while reads continue. Configuration is environment-only: built-in defaults followed by nonempty process environment values, validated before data files or listeners open. Settings are read once at startup; every change requires a restart. | Environment variable | Default | Purpose | |---|---|---| | FANOUT ADDR | 127.0.0.1:7520 | UI, API, MCP, and both OTLP transports | | FANOUT DATA DIR | ./data | Parquet, query state, and control SQLite | | FANOUT AUTH MODE | local | Login link or SMTP, or oidc | | FANOUT AUTH CODE SECRET | — | Required in local mode, 32+ characters | | FANOUT AI PROVIDER | — | Empty disables chat; anthropic or openai enables it | | ANTHROPIC API KEY | — | Required for Anthropic chat | | OPENAI API KEY | — | Required for OpenAI chat | | FANOUT RETENTION DAYS | 30 | Telemetry retention window | | FANOUT MCP ENABLED | true | Serve the MCP endpoint at /mcp | Every secret accepts