ClickVisual is a log console that assumes ClickHouse, MySQL and Redis are already there

The architecture assumes a database you do not operate

ClickVisual describes itself as a lightweight browser-based log analytics and search platform for ClickHouse, written in Go. It is a console in front of storage rather than a pipeline in front of it. Nothing in the feature list ingests logs; the pieces it does list are a visual query dashboard, a query histogram, raw logs for SQL, percentage display for specified fields, a configuration board, kubectl-based deployment, and GitHub and GitLab authentication.

The dependency list in go.mod is where the real architecture shows. ClickHouse is reached through clickhouse-go/v2. Authorization goes through casbin with a gorm-adapter and a Redis watcher, so permissions are a database table plus a cache. MySQL and Redis both appear, and so do gorm, cron and a Docker client library. There are also clients for Prometheus and Slack, which lines up with the alarm feature.

Two frontends are in the tree. The Dockerfile builds a ui/ directory with yarn and a ui-v2/ directory with npm, and copies both dist outputs into the Go binary's asset paths. Two UI generations in one release is a maintenance cost and also a hint about how the project evolved.

The last push was on 2026-10-15, and the recent tags are v1.1.2 and v1.1.1 on 2026-09-03 and v1.1.0 on 2026-09-01, so the release cadence is active.

docker-compose up brings the whole neighbourhood with it

The documented quick start clones the repository and starts the compose file.

git clone https://github.com/clickvisual/clickvisual.git
docker-compose up

Then you open http://localhost:19001 and log in with the username clickvisual and the password clickvisual. Those default credentials are in the README, which is exactly why they are a thing to change before this reaches anything shared.

The compose file is the interesting part, because it explains what the software expects. On a bridge network named clickvisual-net it defines nginx, fluent-bit, zookeeper, kafka with bitnami/kafka:2.8.1, kowl as a Kafka UI, and mysql. fluent-bit reads from the nginx log directory that is bind-mounted into the container as /var/log/containers and is pointed at kafka:9092.

That is a demo topology, and it carries two settings you should not copy into production. zookeeper runs with ALLOW_ANONYMOUS_LOGIN=yes and kafka with ALLOW_PLAINTEXT_LISTENER=yes. Both are there so the demo works with no setup, and both are unacceptable outside a laptop.

Kowl is mapped to port 19002 so you can watch the pipeline, which is useful while you are learning what the stack expects to receive.

Running the binary on a host means doing four things by hand

The non-Docker path is longer and the steps are explicit about what you have to arrange yourself. First resolve the latest tag from the GitHub releases API, then download the archive for your platform.

latest=$(curl -sL https://api.github.com/repos/clickvisual/clickvisual/releases/latest | grep  ".tag_name" | sed -E 's/.*"([^"]+)".*/\1/')
wget "https://github.com/clickvisual/clickvisual/releases/download/${latest}/clickvisual-${latest}-linux-amd64.tar.gz" -O clickvisual-${latest}.tar.gz

There is a matching darwin-amd64 asset for macOS, and the naming convention is clickvisual-<version>-<os>-<arch>.tar.gz. After extracting, the README lists the remaining work in order: edit config/default.toml to set the database and Redis or other sections, execute the latest SQL script in the scripts/migration directory, and start the binary.

cd ./clickvisual-${latest} && ./clickvisual -config config/default.toml

The migration step is the one people forget. The binary does not run migrations for you on this path, so a fresh database without the scripts applied leaves you with a running process and no tables. There is also no ARM build mentioned in the README, which matters now that both macOS and most container hosts default to arm64.

The Go module declares go 1.21.1, and the Dockerfile builds with golang:1.21.0-alpine3.17, so the Go version you need is not a moving target.

Alarm rules and DAG workflows are the parts that go beyond search

Query and search is the baseline. Two features sit above it.

The alarm workflow is the one that changes how a team uses the tool. A scheduled rule evaluates a condition and, given the Slack client in go.mod, notifies. The dependency on github.com/robfig/cron/v3 is how scheduling is done, and prom2click in the dependency list suggests a path from Prometheus into ClickHouse as well as out of it.

A directed graph of processing steps sounds like an ETL builder, and the README documents it with a single diagram and no prose, which is the weakest documentation in this repository. It does not say what nodes are available, how state is stored between steps, or whether a failed node retries. Treat it as a feature you have to evaluate by reading the code, not one you can plan around from the docs.

The configuration board is the third piece worth understanding. The README describes it as vscode style, and says it lets you emit a fluent-bit configuration to a Kubernetes ConfigMap. In other words ClickVisual writes the agent side of your logging pipeline for you, which is convenient and also means the wrong field value is pushed to production ConfigMaps rather than caught by a linter.

Where a Kibana-style console is the wrong choice

The obvious comparison is with the Elastic stack, and the difference is not cosmetic. ClickVisual talks SQL to ClickHouse. Elasticsearch talks a query DSL, and the ecosystems around it, from index templates to data streams, are built around that model. Moving from one to the other is not a UI swap; it is a change to how you write queries, how you manage retention, and what your storage engine optimises for.

Within the ClickHouse world, the alternative is writing your own thin UI over clickhouse-go, which is a real option if your needs are a handful of saved queries. You lose the alarm rules, the permission model and the fluent-bit configuration board, and you keep full control.

There are two limitations to weigh before you commit. First, ClickVisual is a console, not a collector: something has to be writing rows into ClickHouse, and ClickVisual does not do it. The compose file's fluent-bit stage exists to demonstrate that handoff rather than to provide it. Second, the host install path depends on a MySQL and a Redis that you provision, plus a hand-run migration, which is three ways for a first install to differ from the demo.

The 1.x version numbers and the two-frontend tree suggest an interface still in progress. That is fine for an internal tool and worth knowing if you are standardising on it.

Editorial conclusion

Adopt ClickVisual when your logs already live in ClickHouse and you want a query console, histograms and alarm rules without building a UI, and start from docker-compose so the dependencies line up. Do not adopt it as a log collector, because ingesting is somebody else's job. Before running it anywhere shared, change the default clickvisual login and the plaintext Kafka listener in docker-compose.yml.

Frequently asked questions

Official sources

1. clickvisual/clickvisual on GitHub
2. License: MIT
3. Project website
4. README
5. Releases