Logchef is a self-hosted log analytics workspace that sits on top of the log storage you already run instead of replacing it. Point it at ClickHouse tables, VictoriaLogs instances, or both, and you get a single interface for exploration, saved queries, dashboards, alerting and access control without moving or reshaping the data underneath. It ships as one Go binary with no runtime dependencies, is licensed AGPLv3, and is built by the team behind the Zerodha tech blog.

The query workflow

Exploration is query-first. LogchefQL is its own small filter language for the common case, with native ClickHouse SQL or VictoriaLogs LogsQL available when a question outgrows it. Saved queries and query history are kept per source, and field exploration builds filters from what is actually in the data rather than from a schema you remember. Live tail streams matching rows as they arrive, both in the browser and from the CLI.

Dashboards, alerts and the AI assistant

Dashboards are a direct-manipulation grid: mix ClickHouse and VictoriaLogs panels on one canvas, drag and resize them in place, and pick time series, stat, breakdown or table views against a shared time range. Alerts are scheduled evaluations of source-aware rules that notify over email or a webhook. An AI query assistant turns a natural-language question into LogchefQL, SQL or LogsQL as a starting point you then edit — useful when you know the shape of the answer but not the dialect.

Access control

Authentication is OIDC for SSO deployments, or built-in email and password when you do not want to run an identity provider at all; the two can run side by side, and OIDC deployments can auto-provision new users safely. Authorisation is role-based, with per-source scope carried through every query, so a team sees only the datasources it was granted — including source-level credentials and VictoriaLogs tenant headers.

Running it

The quickest start is the published Docker Compose file, which brings up Logchef together with ClickHouse. Kubernetes deployments use the Helm chart in deployment/helm, which also wires Dex for OIDC and ClickHouse through the Altinity operator. Release archives for Linux and macOS (amd64 and arm64) run the same server as a standalone binary, and a separate logchef CLI speaks to your instance for query, native SQL or LogsQL, explain, histogram, fields, history, tail, doctor and browser hand-off. Either way you need an existing ClickHouse or VictoriaLogs backend: Logchef is the query and control plane, not the storage.

How it compares

Against Grafana, Logchef trades the broad plugin catalogue and general-purpose dashboard ecosystem for a narrower, log-specific workflow — LogchefQL, tail and alerting over ClickHouse and VictoriaLogs, with little to configure before you can search. Against Grafana Loki the difference is where the data lives: Logchef deliberately does not store logs, so it complements an existing ClickHouse or VictoriaLogs deployment instead of asking you to adopt a new store. Worth weighing before you commit: it is AGPLv3, and its value depends entirely on having one of those two backends already populated.