AKHQ vs Kafbat UI
ComparisonsAKHQ vs Kafbat UI, compared
Key takeaway
AKHQ and Kafbat UI are both free, Apache 2.0, self-hosted and uncapped, so the choice is not about price. AKHQ is the more deployed and production-tested of the two, and its open problems are operational: two memory reports open since 2022 and 2025, and OIDC as its tracker’s most active failure surface. Kafbat UI has the finer access model, with permissions scoped to eight resource types, though its audit level defaults to ALTER_ONLY, so reads go unrecorded. Kpow by Factor House is the licensed, self-managed alternative, and it is not open source.
What is AKHQ?
AKHQ is an open-source Kafka management UI under Apache 2.0, formerly KafkaHQ, self-hosted and built on Micronaut. One deployment reaches one cluster or many, covering topic browsing, live tailing, producing, consumer groups, Schema Registry, Kafka Connect, ACL management and role-based access with LDAP and OIDC. There is no commercial edition, no hosted service and no paid support tier.
- Releases: 0.28.0 on 6 August 2026, after 0.27.1 in May and 0.27.0 in March.
- Maintainership: concentrated, at 441 commits from the lead maintainer and 82 from the next human contributor.
- Adoption: the README names BMW Group, Klarna, Best Buy, Decathlon and Michelin among others.
- Contributions: Michelin built resource-level RBAC on the default authorisation model and contributed it back.
What is Kafbat UI?
Kafbat UI is a free, Apache 2.0 web dashboard for observing and managing Kafka clusters, deployed as a container rather than installed per engineer. It is the maintained continuation of the Provectus kafka-ui project, carried forward by contributors who were there from that project’s inception. Kafbat sells services around the software instead of a paid edition of it.
The fork history is why the two names collide in search. Provectus kafka-ui shipped its last release, v0.7.2, in April 2024 and took its last commit that July. Kafbat is where the work went. The dormant repository carries 12,200 stars against Kafbat’s 2,642, so the first result many engineers reach is the abandoned one, and the old image is still being pulled by teams who believe they are running the current project.
What is the official 2026 pricing of AKHQ and Kafbat UI?
Both are Apache 2.0, and neither has a paid tier, a seat cap, a cluster cap, a registration step or a feature withheld for a commercial edition. The real cost on both sides is operator time. What money can buy is where they differ: Kafbat sells professional services around the open-source product, quoted rather than listed and also sold through AWS Marketplace, covering architecture review, custom UI implementation, performance and scaling, security and compliance, and 24/7 support. AKHQ has nothing to buy, so the escalation path ends inside your own team.
What the deployment costs to run is close to identical. Both are stateless containers with no external database, both are configured in YAML or through environment variables, and both are reproducible in source control alongside the cluster list. Kafbat publishes a Helm chart whose example values are 200m of CPU and a 512Mi memory limit against a 256Mi request, which is a starting point rather than an answer at scale.
Where does each one run out?
AKHQ has both masking and audit logging, and both are shallower than the feature names suggest. Masking takes four modes and lives in the application YAML, keyed on topic and field path, so what is hidden does not vary by who is looking. Only one filter per topic is supported, which breaks where RecordNameStrategy puts several record types on one topic.
- Audit: opt-in, sunk to a Kafka topic the operator nominates, with no audit view in the product. 0.28.0 widened it to produce, delete and empty topic.
- Memory: a report open since July 2022 and last touched in March 2025, and a second from May 2025 with no response.
- OIDC: the most active failure surface in the tracker, with new reports still arriving in August 2026.
- Metrics: port 28081 reports AKHQ’s own health. The request for Kafka JMX collection has been open since September 2021.
Kafbat’s audit trail is the better of the two on paper, and its defaults undo half of it. The level switch defaults to ALTER_ONLY, so who changed something is captured and who read a payload is not, until an operator sets ALL.
- Audit topic: must not be compacted, because records carry no key, and its partition count defaults to 1.
- Masking: covers what the Messages page displays, per cluster and pattern-driven, so coverage depends on the patterns written.
- Releases: five tags across 2025, then v1.5.0 on 20 April 2026 and none since, against commits still landing in August 2026.
- Dynamic config: the wizard writes inside the container and overwrites the file in full each submission, so UI changes are lost on restart without a volume.
Which should you pick?
Pick AKHQ if:
- the deployment record matters more than the interface
- the estate includes on-premise or factory clusters, or MSK IAM authentication
- a GitOps configuration model is already in place
- an adoption list has to survive an architecture review
Pick Kafbat UI if:
- the access model is the project, at eight resource types with regular-expression subjects
- the audit trail has to be built in rather than bolted on
- an agent needs a documented route in through the MCP server behind
mcp.enabled
On Kafbat, set the audit level to ALL on day one, raise the audit topic’s partition count before the deployment gets busy, and declare clusters in YAML rather than through the configuration wizard. The choice is not really between two feature sets, because those converge. It is between a project whose problems are in the tracker with nobody paid to close them, and a project whose code is healthy and whose release cadence is the thing being bet on.
Kpow: masking that doesn’t wait on someone to remember
AKHQ and Kafbat UI both hand governance to whoever remembers to configure it. AKHQ’s masking lives in global application YAML with one filter per topic, so what’s hidden doesn’t vary by who’s looking, and Kafbat’s audit level defaults to ALTER_ONLY, so reads go unrecorded until an operator sets it to ALL. Kpow by Factor House ships server-side masking built in, so it doesn’t depend on a default nobody changed. It’s self-managed tooling for the cluster you already have, licensed per cluster at a published price, so what you pay doesn’t move when the team does: one stateless JVM container, no external database, and up to 12 clusters from one instance.
Governance shouldn’t depend on who’s staffing it this quarter. Trying Kpow against a cluster you already run shows what it looks like built in instead of remembered.
Sources
- Apache Kafka documentation on authorization
- Apache Kafka documentation on log compaction
- Apache Kafka documentation on monitoring