CMAK vs Kafdrop
ComparisonsCMAK vs Kafdrop, compared
Key takeaway
CMAK and Kafdrop are not substitutes: CMAK is an administration console with no message browsing, and Kafdrop is a message viewer with no partition reassignment. Both are free, self-hosted Apache 2.0 web interfaces over a Kafka cluster somebody else runs, and neither has anybody under contract. CMAK requires a ZooKeeper ensemble, which Apache Kafka 4.0 removed, so it cannot address such a cluster. Kafdrop has needed none since 3.10.0, but three reports of its topic view failing under KRaft were closed as not planned. Kpow by Factor House is licensed per cluster at a published price.
What is CMAK?
CMAK is Cluster Manager for Apache Kafka, originally Kafka Manager, built at Yahoo and released under Apache 2.0. It runs on Scala and the Play framework, and its scope is administrative rather than data-plane.
- registering and monitoring several clusters from one view
- creating and modifying topics, and managing partitions
- preferred-replica election and partition reassignment
- optional JMX polling at broker and topic level
The newest tagged release is 3.0.0.6 of April 2022, and 3.0.0.5 of June 2020 before it, so the cadence had already slowed before it stopped. The last commit on master is December 2022 and the last push of any kind is August 2023. 522 issues stand open. The repository is not archived, and it carries 11,925 stars, which is why it keeps appearing on shortlists.
What is Kafdrop?
Kafdrop is an open-source Kafka web UI on Spring Boot, Apache 2.0, maintained by the Obsidian Dynamics team. It runs as a stateless Java process against standard broker protocols with no separate backend datastore, which keeps setup to a single container. Requirements are Java 17 or newer and Kafka 0.11.0 or newer, the UI serves on port 9000, and TLS and SASL to brokers are documented.
- view brokers and topics
- browse messages in JSON, plain text, Avro and Protobuf
- view consumer groups with combined and per-partition lag
- create topics, view ACLs, and reach Azure Event Hubs
The repository carries 6,154 stars, is not archived, and has 46 issues open, with commits landing through August 2026 including a Spring Boot 4.1 upgrade and Java 25 in December 2025. The newest tagged release is 4.2.0 of July 2025, so the 2026 feature work sits in no published image.
What is the official 2026 pricing of CMAK and Kafdrop?
Neither of these has a price, so the whole cost is operator time. There is no SLA on either, because there is nobody under contract on either. The difference is that one of them has a tracker somebody still reads.
For a team of five, Kafdrop is genuinely cheap: one container, minimal overhead, and five engineers who all hold cluster credentials anyway. CMAK at five people costs an sbt and Scala build on a current JDK, or a community Docker image whose repository is now archived and read-only, before anybody sees a topic. At fifty they separate for different reasons. Kafdrop has no authentication to give fifty people, and that is settled rather than pending: the request was opened in January 2026 and closed as not planned in February. CMAK has LDAP basic authentication and coarse global feature flags, which is authentication without authorisation. Both end at a reverse proxy that secures the front door and changes nothing inside it.
Where does each one run out?
CMAK requires a direct connection to a ZooKeeper ensemble, and that one fact governs everything else. Apache Kafka 4.0 supports KRaft only, with ZooKeeper mode removed, so CMAK cannot address such a cluster at all. The maintainer acknowledged this in 2022 and no implementation has shipped since. Managed services either lock down or no longer expose ZooKeeper endpoints, and enabling ZooKeeper ACLs breaks the connection outright.
- Data plane: no message browsing, and no Schema Registry, Kafka Connect or ksqlDB integration.
- Freshness: reads come from an internal cache, and hours of catch-up replication have shown as complete in seconds.
- Access control: no SAML, no OIDC, no per-user or per-topic granularity and no audit log.
- Deployment: both community paths, the Docker image repository and the Kubernetes operator chart, are archived and read-only.
Kafdrop has needed no ZooKeeper connection since 3.10.0 and takes all cluster information through the Kafka admin API, but KRaft is still where it runs out. KRaft has been production-ready since Kafka 3.3 and mandatory from Kafka 4.0, and three reports of the topic view failing against a KRaft cluster were closed as not planned, two of them in 2025.
- Authentication: none in the product. The README documents an NGINX basic-auth workaround.
- Write operations: exposed, so an unprotected instance makes accidental topic deletion possible. The read-only toggle has sat in a pull request since November 2020.
- Reach: one cluster per deployment, no message search by key or value, and message format set per topic by hand.
- Scale: 5,566 consumer groups took over 30 minutes to load, and the same view returned in under a minute with that step disabled.
Which should you pick?
Neither, if the cluster is on Kafka 4. CMAK cannot address a cluster with no ZooKeeper, and Kafdrop’s KRaft position is three declined reports, so for a team already committed to a KRaft cutover this pair is the wrong shortlist.
Pick Kafdrop if:
- what you need is a window onto one cluster rather than a console for operating it
- the job is local development, a dev cluster, or ad-hoc inspection of a topic
- a handful of people who already hold credentials are the whole audience
- nobody untrusted can reach it on the network
Keep CMAK, for now, if:
- the cluster is ZooKeeper-era
- partition reassignment and preferred-replica election are what it gets used for
- its replacement date is already in the same calendar as the KRaft cutover
Moving to Kafdrop means going back to kafka-reassign-partitions.sh or across to Cruise Control for reassignment, because Kafdrop does not do it at all.
Kpow: access control that lives inside the product
Neither of these authorises a person inside the product itself. CMAK’s LDAP integration is basic auth plus coarse global feature flags, with no per-topic granularity and no audit log, and Kafdrop ships with no authentication at all — the README’s answer is an NGINX basic-auth workaround sitting in front of it, which is also what leaves write operations exposed on an unprotected instance. Kpow by Factor House authenticates and authorises users in the product itself rather than at a reverse proxy, runs on KRaft with no ZooKeeper dependency, and ships as a single stateless JVM container with no external database or sidecar. It is licensed per cluster rather than per user, so bringing on another engineer never changes what access control costs.
Access control bolted on at the network edge is access control nobody can audit. Kpow puts it back inside the tool people actually use.