AKHQ vs CMAK
ComparisonsAKHQ vs CMAK, compared
Key takeaway
AKHQ and CMAK are both free under Apache 2.0, self-hosted, with no paid tier on either side, so this is not a price comparison. AKHQ is live, shipping 0.28.0 in August 2026; CMAK last released 3.0.0.6 in April 2022 and needs a direct ZooKeeper connection Kafka 4.0 does not have, so a KRaft cutover ends it the day it lands. AKHQ also drops partition reassignment and JMX metrics, both of which CMAK keeps. Kpow by Factor House is licensed per cluster at a published price.
What is AKHQ?
AKHQ is an open-source Kafka management console under Apache 2.0, formerly KafkaHQ, self-hosted, JVM-based and built on Micronaut. One deployment reaches one cluster or many. It reaches a cluster through bootstrap.servers and the ordinary Kafka client properties, with security.protocol, the SASL settings and the SSL stores alongside them. No ZooKeeper property appears anywhere in its cluster connection reference.
- topic browsing, live tailing and producing records
- consumer groups, Schema Registry and Kafka Connect
- ACL management, and role-based access with LDAP and OIDC
- 0.28.0 in August 2026, after 0.27.1 in May and 0.27.0 in March
The commit record is concentrated: the lead maintainer has 441 commits and the next human contributor has 82. The README opens with a block promoting Kestra, the maintainer’s orchestration platform. There is no commercial edition and no feature held back from the open release.
What is CMAK?
CMAK is the Cluster Manager for Apache Kafka, originally Kafka Manager, built at Yahoo and released under Apache 2.0. It is written in Scala on the Play framework, and it requires a direct connection to a ZooKeeper ensemble to function at all. Its scope is administrative rather than data-plane, and multi-cluster registration from a single view is what it was built to do.
- partition reassignment and preferred-replica election
- dynamic topic configuration, partition creation and replica change
- optional JMX polling at broker and topic level
- 3.0.0.6 in April 2022, last commit December 2022, 522 issues open
The repository is public and it is not archived.
What is the official 2026 pricing of AKHQ and CMAK?
Neither project charges anything, so the whole comparison is carry cost, and carry is not the same on both sides. AKHQ is a JVM service somebody sizes, deploys and reads an issue tracker for before upgrading, and its configuration is YAML under Helm, so the cluster list, the users, the groups and the registry links sit in source control. CMAK is distributed as source and expects an sbt and Scala build, its container images are community-maintained, and the only Kubernetes chart was archived by its owner in March 2026.
At five engineers who all hold cluster credentials anyway, free is genuinely free on either side. At fifty, most of whom should never touch a broker, the carry becomes a job: an upgrade path, an access model, and an answer for the morning the console is the thing that is down. Neither has an SLA. The difference is that a report against AKHQ lands in a tracker that gets triaged, and a report against CMAK joins 522 others.
Where does each one run out?
AKHQ’s governance is present but shallow. Data masking takes four modes, configured globally in the application YAML and keyed on topic and field path, so what is hidden does not vary by who is looking, and only one filter per topic is supported. Audit logging is opt-in and writes to a Kafka topic the operator nominates, with no audit view inside the product.
- Audit scope: modifications only, including record produce, delete and empty topic since 0.28.0. Reads are not covered.
- Memory: a constantly-increasing-memory report open since July 2022, and a second since May 2025.
- OIDC: the most active failure surface in the tracker, with new defects still arriving in August 2026.
- Metrics: no JMX visualisation and no alerting, so a Kafka dashboard comes from elsewhere.
CMAK’s ZooKeeper dependency is the whole clock. KIP-500 replaced the ensemble with a self-managed metadata quorum and KIP-833 set its removal for Kafka 4.0, which shipped in March 2025. CMAK talks to the ensemble directly, so on a KRaft cluster there is nothing for it to connect to. Managed services have already closed or stopped exposing ZooKeeper endpoints.
- Message browsing: absent, so there is no way to query a Kafka topic from the interface.
- Freshness: reads come from an internal cache rather than live broker APIs, so a change does not appear immediately.
- Access control: LDAP basic auth and coarse global feature flags, with no SAML, no OIDC and no per-topic granularity.
- Transport: LDAP is unencrypted unless SSL is configured, which the README states.
CMAK has no audit log, and enabling ZooKeeper ACLs breaks its connection entirely. Both are limits on any Kafka security architecture that assumes the console sits inside the perimeter.
Which should you pick?
Pick AKHQ if:
- the cluster is on KRaft, or heading there
- the daily work is message browsing, live tailing and consumer group inspection
- the tool is for engineers who already hold cluster access
- RBAC for Kafka has to line up with an identity provider that already exists
Keep CMAK, with a date on it, if:
- the cluster is still on ZooKeeper
- the daily work is partition reassignment and preferred-replica election
- the KRaft cutover is already in a migration plan somebody owns
Whichever way it goes, the reassignment console does not come across. AKHQ can increase a topic’s partition count, but it has no reassignment, no replica change and no JMX metrics, which are the operations CMAK is best at. Moving means reassignment goes back to kafka-reassign-partitions.sh or to something like Cruise Control, and Kafka cluster monitoring goes to whatever already scrapes JMX. Both tools sit on every list of best free Kafka UI tools, and free is a statement about the invoice rather than about the cost.
Kpow: no rota to run
Neither AKHQ nor CMAK has anybody behind it, so the cost of running either one is a rota rather than an invoice, and that rota only gets longer as the cluster count grows: someone sizes and reads the tracker for the JVM before an upgrade, someone owns the Scala build, and someone is the answer for the morning the console itself is down. Kpow by Factor House is licensed per cluster at a published price instead: one stateless JVM container, with no external database and no persistent volume, running against a cluster you already operate. One instance manages up to 12 clusters, so the person on call does not multiply the way the rota does on either of these.
The rota doesn’t have to be the plan. Starting Kpow against one of your clusters is the way to find out how much shorter it gets.
Sources
- KIP-500: Replace ZooKeeper with a Self-Managed Metadata Quorum
- KIP-833: Mark KRaft as Production Ready