Kpow vs CMAK
ComparisonsKpow vs CMAK, compared
Key takeaway
CMAK connects through ZooKeeper, and Kafka 4.0 removes ZooKeeper mode entirely, so it cannot reach a 4.x cluster at all. It is still good at partition reassignment and preferred-replica election, but free is the licence and not the cost: an archived Kubernetes chart and 522 open issues with no maintainer behind them. Access control is the other gap: LDAP basic auth, no OIDC, no per-topic granularity, no audit log. Kpow by Factor House bills per cluster from 4,500 US dollars, with 100 users included.
What is CMAK?
CMAK is Cluster Manager for Apache Kafka, built at Yahoo and released under Apache 2.0. It was called Kafka Manager before it was renamed. It is a Scala and Play application, and it connects to a ZooKeeper ensemble rather than to the brokers. Its scope is administrative rather than data-plane, and one structural fact governs every section after this one: CMAK reads through ZooKeeper.
- registering and monitoring clusters from a single view
- partition reassignment and preferred-replica election
- creating and modifying topics, and managing partitions
- optional JMX polling, the thinnest form of Kafka monitoring anybody would name as such
It is genuinely good at two of those. Partition reassignment and preferred-replica election are what operators praise it for most consistently, and both are real operational work rather than a view onto somebody else’s. On a ZooKeeper-era cluster it also remains a clear way to learn Kafka’s internal model.
What is Kpow?
Kpow by Factor House is engineer-facing tooling for Apache Kafka, and it runs against whatever cluster you already have: self-managed Kafka, Amazon MSK, Confluent Cloud, Redpanda, Aiven and Instaclustr. It talks to brokers rather than to ZooKeeper, which is why the metadata question never arises. It is a single stateless JVM container, configured entirely through environment variables, with no external database, no sidecar and no persistent volume, storing its telemetry in internal Kafka topics on the cluster it is already monitoring. One instance manages up to 12 Kafka clusters.
That matters more here than it would against another commercial product. What a CMAK operator is weighing is not one interface against another. It is an application they build from source and carry themselves against one they pull and configure. One structural fact governs Kpow in the same way: it runs on top of the cluster and never runs the cluster, and it is licensed rather than free.
What is the official 2026 pricing of Kpow and CMAK?
CMAK is free under Apache 2.0, on a single self-hosted tier. There is no paid edition, no hosted offering and no support contract, so the whole cost of running it is the engineering time that carries it. For a team of five on one ZooKeeper cluster, that carry is small and the zero is real. For a platform team on six clusters with an audit requirement it is different work: an sbt build on a current JDK, a Docker image somebody in the community maintains on no schedule, a Kubernetes operator chart that is archived and read-only, and 522 open issues with nobody left to send a five hundred and twenty-third one to.
Kpow bills per cluster per year and the price is published. Enterprise starts at 4,500 US dollars per cluster with 100 users included, and Community Edition is free for up to 3 clusters and 10 users, with a 30-day trial of Enterprise on top of it. Adding an engineer does not change the bill, and the number is one somebody can put in a budget before they talk to anybody.
Where does each one run out?
CMAK has no KRaft support and a hard ZooKeeper dependency. Kafka 4.0, released on 18 March 2025, removes ZooKeeper mode entirely, which was the direction set out in KIP-500 and confirmed in KIP-833. The incompatibility is total rather than partial: not a degraded view of a KRaft cluster, but no view. Managed services cut the same way from the other side, because MSK, Confluent Cloud, Aiven and Redpanda Cloud either lock down or no longer expose ZooKeeper endpoints.
- Releases: 3.0.0.6 on 29 April 2022, and the last commit on master is December of the same year.
- Freshness: reads come from an internal cache rather than live broker APIs, so a reassignment can look as though it has not taken effect.
- Access control: LDAP basic auth and coarse global feature flags, with no SAML, no OIDC, no per-topic granularity and no audit log.
- Hardening: credentials pass in plaintext unless SSL is configured by hand, and enabling ZooKeeper ACLs breaks the connection outright.
It is a commercial licence, and a team that will not carry one is not the buyer. It runs on top of the cluster rather than running it, same as CMAK — the difference is what the licence buys: a role model, an audit trail and support behind it, published as one number per cluster rather than negotiated case by case.
How do you switch, or run both?
Running both is fine, and for most teams it is what happens for a while. Neither tool owns cluster state, so the second one is a container and a configuration block rather than a migration, and CMAK keeps working right up until the KRaft cutover and not one day after it. There are four steps, and only one has a date on it.
- Stand the new tool up beside CMAK, before the cutover. Both read the same cluster.
- Re-point the single sign-on. Anything in front of CMAK is a reverse proxy that moves rather than being rebuilt.
- Replace partition reassignment and preferred-replica election, which a lightweight Kafka UI often does not cover.
- Turn CMAK off when ZooKeeper goes. It holds no state of its own.
The well-trodden practitioner path off CMAK runs to AKHQ or Kafbat UI, and either is reasonable where the requirement really is a viewer.
Which should you pick?
Stay on CMAK if:
- the cluster is staying on ZooKeeper
- the work in front of you is partition reassignment on a small estate
- nobody is asking for an audit trail
Move if:
- the KRaft migration is on a roadmap with a date attached
- a managed service is anywhere in the estate
- RBAC for Kafka has to be answerable per user and per topic rather than per instance
Those three conditions usually describe one team rather than three, because losing ZooKeeper access is what sends somebody to the access-control section in the first place. One team leaving a licensed platform compared the open-source options, CMAK among them, and chose Kpow on consumer lag and offset visibility. Ranking CMAK against the best Kafka management tools matters less than the fact that it is already wired to your brokers.
Why does nobody schedule the admin screen?
CMAK earns credit on its home turf. It was built at Yahoo for exactly this job, and partition reassignment and preferred-replica election are what operators still praise it for most consistently — real operational work on a ZooKeeper-era cluster, not a view onto somebody else’s. Registering and monitoring several clusters from one screen is straightforward, and on a stable ZooKeeper cluster it remains a clear way to learn Kafka’s internal model.
But its whole worldview runs through ZooKeeper, and Kafka 4.0 removed ZooKeeper mode entirely: not a degraded view of a KRaft cluster, no view at all. There is no message browsing of any kind, access control is LDAP basic auth with no SAML, no OIDC and no audit log, and there is no support tier to call when any of that goes wrong. Kpow answers each one on the other side: it talks to brokers rather than to ZooKeeper, so the metadata question never arises, message browsing is in the product, and role-based access control, single sign-on and a full audit log ship on Enterprise, with priority support behind it.
It also reaches clusters CMAK cannot: Amazon MSK, Confluent Cloud, Redpanda, Aiven and Instaclustr, as one stateless container with no database or persistent volume behind it, and the price is published per cluster rather than negotiated case by case. The Community Edition is free for up to 3 clusters and 10 users, which is enough to start on Kpow and run the evaluation against your own migration timeline. CMAK reads the cluster through ZooKeeper. Kpow just reads the cluster.