Best Kafka tools for self-managed Apache Kafka

Tools compared

Rank	Tool	Total (out of 100)	Out of the data path	Production access on request	Audit trail per person	Directory and Kafka sign-in	Many teams, shared clusters	Brokers, Connect and registries	Cost a year, 3 clusters (modelled)
1	Kpow	89	One container, state in your Kafka, not a proxy	Time-boxed temporary policies via API, staged approvals, masking per resource	Every action with the IdP user, data queries included	SAML, OIDC, LDAP; any SASL mechanism or mTLS to brokers	Tenants and per-action RBAC	URP count right with a broker offline; several Connect clusters and registries; no reassignment plan or throttle	$16,380
2	Kafbat UI	66	One stateless container	Per-resource RBAC, no approvals, masking for all viewers	Optional, reads at level ALL, no view	OAuth2, OIDC, LDAP; no SAML	Per-resource roles per cluster	Brokers and running config; Connect and one registry per cluster	$8,640
3	AKHQ	57	One stateless container	Regex groups, UI-only if JWT secret unset	Opt-in, no reads, no view	LDAP, OIDC; no SAML	Groups by resource and cluster pattern	Nodes and configuration; Connect and registry, Protobuf deserialise only	$8,640
4	Lenses	53	HQ on PostgreSQL, agent and database per cluster	Strict global masking, no approvals	In-product audit log from Team tier	SSO incl. Entra ID and Okta	Roles on groups only	Brokers through its agent; strong connector state and alerting	$2,880 plus quoted licence
5	Apache Kafka command-line tools	49	Nothing to deploy	The principal's Kafka ACLs only	Denied requests only by default; allowed ones at DEBUG	Every SASL mechanism; no sign-in for people	ACLs per principal and prefix	Full broker surface incl. throttled reassignment; Connect by hand; no registry	$11,520
6	Redpanda Console	47	One container	None in the free build; RBAC licence-gated	None on Apache Kafka brokers, licensed or not	OIDC only, licence-gated	RBAC licence-gated; no policy across deployments	One broker cluster per deployment; several Connect clusters; reassignment licence-gated	$8,640 plus an unpublished licence for RBAC
7	Conduktor	57	Console on PostgreSQL; Gateway proxy in the data path	Per-viewer masking, cross-team access requests	70+ event types with user, in the UI	LDAP, OIDC	Per user or group, most permissive grant wins	Connect, ksqlDB and registries; no reassignment view recorded	$50,880; $140,880 with Gateway Core and Protect

No tool meets every column, and teams on self-managed Kafka commonly keep the command-line tools or Cruise Control for cluster-wide partition moves alongside whichever UI they choose.

The tools, ranked for self-managed Apache Kafka

What teams on self-managed Apache Kafka need

This page is about teams that run the Apache-licensed Kafka distribution themselves, on virtual machines, bare metal or Kubernetes, rather than a managed service or a vendor’s licensed distribution. For the difference between the two distributions see Apache Kafka vs Confluent Kafka, and for the same question on a managed service see the best Kafka UI tools for Amazon MSK.

Owning the whole stack. A team on open-source Kafka owns the brokers, the controllers, the Kafka Connect workers and whichever schema registry it chose, because the open-source distribution does not include one, and it owns every tool it adds. The joint Factor House and NetApp Instaclustr session Migrating to open source Kafka sets out the case for staying on open source: Kafka Improvement Proposals keep reaching the open-source project, nothing needs to leave the team’s own cloud or VPC, and procurement stays open. The session runs again for European time zones on 6 October 2026, as the webinar Migrating to open source Kafka: cutting TCO without the operational burden.

Running the Apache distribution also means a feature can be used from the release that ships it, with no provider deciding when to expose it. Fetching from the closest replica is an example. KIP-392 has long been part of Apache Kafka, and it lets a consumer read from a replica in its own rack or availability zone once the brokers set replica.selector.class and the consumer sets client.rack, which the AWS Big Data Blog describes as the way to cut the cost of cross-zone traffic from consumers. That matters for the bill, because the same session warns that the true cost of running Kafka is rarely visible on one line item, and Stanislav Kozlovski’s review of Kafka cost calculators works through the reason in numbers, counting cross-zone traffic separately for producers, replication and consumers.

Replacing what a licensed distribution bundled. Teams that leave a licensed distribution lose the console that came with it. Gmarket ran the licensed Confluent distribution with Control Center, decided to move to community Kafka, and needed a replacement for the consumer lag and topic offset views its teams relied on. Control Center documents Confluent Platform clusters only and needs the Confluent Metrics Reporter on each broker, so it does not follow a team onto open-source brokers.

The schema registry is the next piece to choose, and it is a licence decision as well as a technical one. Confluent Schema Registry is free to self-host, and its source repository states that the project is under the Confluent Community License, with only the client modules under Apache 2.0. Karapace, which describes itself as a drop-in replacement for it, and Apicurio Registry are both published under Apache 2.0. A team that moved to the Apache distribution in order to stay on open-source licences therefore has to choose its registry deliberately, and its tool has to work with whichever registry that is.

Kafka Connect raises the same question from the other direction. The framework ships with Apache Kafka and very little else does: the file connectors in the distribution are examples, which the Kafka Connect documentation notes are not on a worker’s plugin path by default. Every connector in production is therefore a plugin the team selects, licenses and upgrades itself, and the open-source counterpart to a vendor’s topic-to-table feature is the Apache Iceberg sink connector running on the team’s own workers.

Outgrowing the first tools. US Foods’ platform team shows how teams outgrow their first tools: it managed the Kafka behind its MOXē e-commerce platform with CLI scripts, stepped up to AKHQ, and then moved to Kpow, which now gives a dozen product teams and roughly 130 developers scoped, self-service access, as the US Foods case study describes.

Open-source tools change hands as well. Kafbat UI exists because development of the original kafka-ui project stopped: the Kafbat project announcement of January 2024 gives six months without a commit and an unaddressed CVE as the reasons for the fork. GitHub Security Lab later published three remote code execution vulnerabilities in that original project, fixed in its 0.7.2 release, and noted that its default configuration required no authentication to read and write data. On a self-managed platform, following and applying fixes of that kind is the team’s own work, which is the work the six hours a month in this page’s cost model for the open-source UIs stands for.

Out of the data path. Where the tool runs matters on a self-managed platform because the team operates the tool as well as the cluster. A tool that is one container next to the cluster, connecting the way any Kafka client does, adds one stateless service. A tool that needs a database of its own adds a stateful service to back up and upgrade, and a tool whose controls are enforced by a proxy that every client connects through puts something the team must size and keep available in front of the brokers. Kpow is one container with no external database, installed in your own environment and out of the data path. It connects to the brokers as an ordinary Kafka client, installs nothing on them and leaves producers and consumers talking to the brokers directly, and its system requirements state that it has no dependency beyond Kafka, because the snapshots, metrics and audit log it needs are held in topics on the team’s own cluster.

Conduktor differs from Kpow in where its controls run. Conduktor Console also connects to clusters directly and masks data in its own UI, with a PostgreSQL database of its own; Conduktor’s data-level controls, such as encryption, masking of the data itself, policy enforcement on client traffic and virtual clusters, run in Conduktor Gateway, which Conduktor’s own documentation describes as a Kafka proxy between client applications and brokers. The trade runs in both directions. Gateway can enforce policy on applications, which a tool beside the cluster does not attempt, and on a self-managed platform the team would run that proxy itself, a trade-off Kai Waehner’s review of Kafka proxies sets out in detail. Kpow gives people RBAC, masking in inspection, temporary access, tenants and an audit log without putting anything in front of the brokers.

A database has a running cost of its own. PostgreSQL’s documentation describes moving to a new major version as a dump and restore, a pg_upgrade run or a switch through replication, so a tool that stores its state in PostgreSQL adds that procedure to the platform team’s upgrade calendar, a step that Kpow and the stateless open-source UIs do not have.

The command-line tools score highest on this criterion because nothing is deployed at all, and that has a network cost. A Kafka client connects to each broker at the address the broker advertises to clients, so every workstation or jump host that runs the scripts needs a network route to every broker, where a tool running beside the cluster needs those routes from one place and gives engineers a single HTTPS address.

Production access on request. Kafka ACLs authorise principals, and when forty engineers share one tool, the principal is the tool’s. Production access for a task, an approval before an offset reset or a topic deletion, masking of sensitive fields, and an audit record of which engineer did what all have to come from the tool, and on a shared platform they have to scope each team to its own topics, consumer groups and connectors.

Kafka’s own access model has no notion of time. An ACL is a standing rule that kafka-acls.sh adds and removes, and nothing in it expires, so access granted by ACL for one task lasts until someone remembers to remove it. A tool can put the time limit into the grant itself, which is what the temporary policies described further down this page do.

Audit trail per person. Apache Kafka has no audit log of its own. KIP-567, the proposal to add one, was still under discussion when read on 2 October 2026. What the broker offers is the authorizer log, which the distribution’s default logging configuration writes to a kafka-authorizer.log file on each broker and rolls every hour. Turning that into an audit trail means collecting and parsing those files from every broker, and each entry is about a principal, which for work done through a shared tool is the tool’s. The record of which engineer inspected a topic, changed an ACL or reset a consumer group’s offsets therefore has to come from the tool people sign in to, and an offset reset during an incident, a decision to skip or replay data, is the kind of action that record exists for, as the Kafka UI guide sets out.

Directory and Kafka sign-in. On self-managed Kafka the team chooses how clients authenticate, and Apache Kafka supports Kerberos through SASL/GSSAPI, SASL/PLAIN, SCRAM-SHA-256 and SCRAM-SHA-512, OAUTHBEARER and TLS client certificates. Two details of the open-source implementation matter when a tool is added. The default OAUTHBEARER implementation creates and validates unsecured JSON Web Tokens and is documented as suitable only for non-production installations, so a production cluster on OAuth is configured against a real identity provider and the tool needs the same client settings. SCRAM credentials are stored in the cluster’s metadata log and created with kafka-configs.sh, so the tool’s SCRAM user is created the way any application’s is.

Once an authorizer is enabled, Apache Kafka restricts a resource that has no ACLs to super users, unless the team sets allow.everyone.if.no.acl.found. A tool therefore shows nothing until its principal is granted ACLs. Kpow’s minimum ACL permissions page lists the grants it needs to operate and maps each further ACL to the Kpow action that depends on it, such as Alter on the cluster for editing ACLs. When an action is refused, that mapping lets an operator tell a role that lacks the permission in Kpow from a principal that lacks the ACL on the broker, which decides whether the fix belongs in the role file or in the cluster’s ACLs.

Many teams, shared clusters. Apache Kafka’s own multi-tenancy guidance isolates tenants on one cluster with a hierarchical topic naming structure, prefixed ACLs and quotas, and gives the example of a team that may only create topics whose names start with payments.teamA.. A tool’s view of a shared cluster works when it follows the same prefixes. Kpow tenants include or exclude topics and consumer groups by name, prefix or suffix, so a team’s tenant can be drawn along the prefix its ACLs already use.

Quotas are the other half of that guidance, and the Apache default is that clients receive an unlimited quota, so on a shared self-managed cluster no team is capped until the platform team sets one. ACLs are also stored per cluster, so development, staging and production each carry their own set, where a tool’s roles are one policy across every cluster it manages. At larger scale some organisations stop writing ACLs by hand altogether: Uber’s engineers describe plugging a custom authorizer into the brokers to delegate authorisation to the company’s central policy store.

Teams that provision topics and ACLs from Git commonly do it with the open-source Terraform provider for Kafka, which manages topics, ACLs and quotas. A UI sits beside that pipeline and does not replace it: the pipeline owns the declared state, and the tool is where people inspect data, read lag and handle exceptions under a role.

Brokers, Connect and registries. Self-managed teams also handle the broker failures a managed service takes care of for its customers. Claritev’s team saw Kubernetes report every pod healthy and Prometheus raise no alert while a cluster was degraded, and found the out-of-sync broker in Kpow. A tool that reads cluster state through the Kafka Admin API has to count under-replicated partitions correctly even when the broker that is down no longer answers, the problem described in Enhanced URP detection. Broker monitoring options are compared in the best tools to monitor Kafka broker health.

The configuration file in Git is not always what a broker is running. Some broker settings can be changed without a restart, and Apache Kafka applies them in a documented order of precedence: a dynamic per-broker value first, then a dynamic cluster-wide default, then the static value in server.properties. A setting altered with kafka-configs.sh during an incident therefore keeps overriding the file until someone removes it, which is why this criterion scores a view of the running broker configuration.

KRaft changes what there is to look at. Apache Kafka 4.0 is the first major release to run entirely without ZooKeeper, so a tool that reads ZooKeeper for metadata cannot manage a 4.x cluster, and on a cluster with a dynamic quorum the controllers themselves can change, added and removed with kafka-metadata-quorum.sh. Decommissioning a broker also has a last step that is easy to miss: the Apache operations documentation ends the procedure by unregistering the broker with kafka-cluster.sh unregister, after its partitions have been moved and it has been shut down. Kafka 4.0 also made the new consumer rebalance protocol generally available and introduced share groups in early access. The command-line tools gain each new group type in the release that ships it and every UI adds it on its own schedule, so a tool’s release notes are worth reading before a team relies on it for a new group type.

Partition moves are where the scripts keep their lead. Apache Kafka can apply a throttle to replication traffic so that a rebalance limits its impact on producers and consumers, Cruise Control generates rebalance proposals against goals such as rack awareness and disk and network balance, and teams on Kubernetes get it through Strimzi, whose operators use Cruise Control for partition reassignment.

Consumer lag is the last gap in what the brokers report. In Apache Kafka’s monitoring documentation lag is a metric published by each consumer about itself and not by the broker, so the brokers’ JMX has no figure for a group as a whole, and a view across every group comes from comparing committed offsets with the end of each partition. That is what Burrow does, and what Kafka Lag Exporter did until its repository was archived in March 2024, so on open-source Kafka lag monitoring is one more component for the team to choose and keep current unless its management tool computes it.

Who runs Kpow on self-managed Apache Kafka

Two Kpow customers have described in public running Kpow on Kafka they operate themselves: Gmarket, after moving from a licensed distribution to community Kafka, and Claritev, which runs its own Kafka on Kubernetes and brought support in-house. Each card is tagged with the rubric criteria its evidence speaks to, and the grey tags name the other things each case study covers.

How a team runs self-managed Apache Kafka with Kpow

The workflows below are how a platform team puts Kpow to work on Kafka it runs itself. Each one is built from documented Kpow features.

Installing it beside the brokers. Kpow runs as one Docker container or Java JAR, or on Kubernetes with the Helm charts, and teams running Strimzi use its Strimzi build. It needs no external database: the first cluster it connects to is the primary cluster, which holds its snapshots, metrics and audit records in topics. The self-managed Kafka quickstart brings up an apache/kafka broker in KRaft mode, a Connect worker and Kpow with Docker Compose. The documented starting point for production is 2 CPU and 8GB of memory. On Kubernetes the Helm guide recommends setting resource requests equal to limits, which puts the pod in the Guaranteed quality of service class, and a hardened cluster can run Kpow with a read-only root filesystem once the chart’s temporary volume is enabled, because Snappy compression needs one writable directory.

Connecting with the cluster’s own security. Kpow connects to Kafka with the same configuration as a producer or consumer: SECURITY_PROTOCOL, SASL_MECHANISM and SASL_JAAS_CONFIG, with GSSAPI as the default mechanism and the Kerberos settings available as environment variables, or SSL keystores for mutual TLS. On a cluster with ACLs enabled, the principal Kpow connects as is granted the minimum ACLs first, and each further ACL only for the actions the team wants to allow. Clusters on Kafka 1.0 and later are supported, which matters on self-managed platforms because brokers and client libraries age at different rates. Apache Kafka 3.2.0 made producers idempotent by default, and Factor House’s account of that change records production failing with a misleading ClusterAuthorizationException on brokers older than 2.8 whose ACLs did not grant IDEMPOTENT_WRITE, a failure that appears only when a new client library meets an old broker.

Adding the Connect clusters and the registry you run. A Connect cluster is added with its REST URL, and several Connect clusters per Kafka cluster are listed under CONNECT_RESOURCE_IDS. Kpow works with Confluent-compatible registries, Confluent Schema Registry, Apicurio Registry and Karapace, and with several registries per cluster; the trade-offs between those registries are covered in Integrate Confluent-compatible registries in Kpow. A team that deploys connectors through its own pipeline can still use the connector form, which shows the connector’s documentation and form errors and offers export options that create the connector with a call to the Connect REST API. For failed connectors, Kpow can restart a named list automatically, limited by default to 50 restarts in each one-minute pass and one attempt per connector every ten minutes, so a mass failure is retried in batches; the Strimzi operator applies a growing back-off to its own automatic restarts for the same reason.

Watching the brokers. The brokers view shows and edits broker configuration, shows the voters and observers of the KRaft quorum and unregisters a broker that has been removed, and counts under-replicated partitions from the replication factor, so the total stays correct while a broker is offline. Unregistering a broker does not move its partitions, so, as in the Apache procedure, the reassignment comes first. Partition moves made from a topic’s details page are tracked, and can be cancelled, in the Reassignment view.

Managing ACLs and quotas. On a cluster with ACLs enabled, Kpow creates, clones and deletes ACLs by principal, host or resource, and records each change in its audit log. Client and IP quotas are created and edited from the same UI on brokers from version 2.6. Apache Kafka enforces two types of client quota, on network bandwidth and on request rate, and Kpow lists those in one table and the connection-rate quotas set per IP address in another.

Signing people in and scoping teams. Engineers sign in through LDAP, SAML or OpenID, and directory groups map to roles. RBAC sets Allow, Deny or Stage per action and resource, and tenants limit which topics, groups and connectors each role can see on a shared cluster.

Granting production access for one task. A temporary policy gives a role extra actions on a named resource for a fixed time and expires on its own, and a change system can create one through the Kpow API. The policy can run for a set duration or end at a date and time an administrator picks, is capped at seven days unless the team changes the limit, and can be removed before it expires. Staged mutations hold an offset reset or a topic deletion until an administrator approves it, and data policies mask sensitive fields in data inspect results on the server.

Keeping the record and the metrics. The audit log records each action with the user from the identity provider, and a webhook sends those records to Slack, Microsoft Teams or any endpoint. Consumer group lag and other computed metrics are exported on Prometheus endpoints, next to the JMX metrics a self-managed team already collects from its brokers. Kpow computes lag for each group from offsets, so the figure the brokers’ JMX lacks reaches the same Prometheus server without a separate lag exporter.

No tool here leads on every criterion. Kpow reassigns one partition at a time with no generated plan and no throttle, so the command-line tools or Cruise Control do a cluster-wide rebalance better, and it does not read JMX, so request latency, thread idle ratios and broker JVM metrics stay with a JMX pipeline. It governs people working through Kpow, not services connecting to brokers, so Kafka ACLs stay the control for applications. Kafbat UI and AKHQ are free with RBAC included, and Lenses has the stronger query model with SQL over topics.

To run these workflows against your own cluster, install Kpow from its container image or JAR; tenants, RBAC, temporary policies, staged mutations, masking and the audit log are Kpow Enterprise features, and Community Edition is free for 3 clusters and 10 users.

To check the rubric against the product, open the demo and work through brokers, consumer groups, topics and the Kafka Connect cluster on MSK Primary, then open the __oprtr_audit_log topic on MSK Secondary to see what the audit trail records. The demo has no SSO and no data policies configured, so sign-in and masking are the two things to test on your own cluster.

Kpow live demo

Open Kpow before you install it

The live Kpow demo needs no signup. It runs on two Amazon MSK clusters, and the brokers, topics, consumer groups and Kafka Connect views are the ones Kpow shows on any Kafka cluster it connects to, self-managed Apache Kafka included.

For platform teams running open-source Apache Kafka themselves.

Try the Kpow demo→

FAQ

What is the best Kafka UI for self-managed Apache Kafka?

On this page’s rubric, Kpow, with 89 of 100 points: it runs as one container with no external database and nothing in the data path, grants time-boxed production access and records every action with the person from your directory, scopes teams with tenants, keeps an accurate under-replicated partition count with a broker offline, and manages several Kafka Connect clusters and Confluent-compatible registries per cluster. Kafbat UI is the highest-scoring free option.

Does a Kafka management tool need to sit in the data path to govern access?

No. Kpow runs as one container beside the cluster with no dependency beyond Kafka, connects to the brokers like any Kafka client and applies roles, masking, approvals and the audit trail to the people working through it, so producers and consumers keep connecting straight to the brokers. Conduktor Console also connects directly, while Conduktor’s data-level controls, such as encryption, masking of the data itself and Virtual Clusters, run in Conduktor Gateway, a Kafka proxy that client applications connect through. On a self-managed platform that proxy is one more service the team sizes and keeps available.

Is there a free Kafka UI for open-source Apache Kafka?

Kpow Community Edition is free on up to 3 clusters and 10 users and covers topic search and inspection, consumer groups and offsets, schema registry and Kafka Connect management. Kafbat UI and AKHQ are open source under Apache 2.0, with RBAC in the free build. Redpanda Console’s free build has no access control. More free options are compared in the best free Kafka UI tools.

What replaces Confluent Control Center after moving to open-source Kafka?

Control Center documents Confluent Platform clusters only and needs the Confluent Metrics Reporter on each broker, so a team moving to the Apache-licensed distribution needs another console. Gmarket replaced it with Kpow when it moved to community Kafka, for consumer lag, topic offsets, data inspection, reassignment and offset resets across 10 clusters. The broader field is compared in the best Kafka management tools.

What should a team check before moving from Confluent Platform to open-source Apache Kafka?

The joint Factor House and NetApp Instaclustr session Migrating to open source Kafka places the real risk of a migration in schema registries, connector licensing and authentication choices, and recommends running the payback math on the migration cost against the expected annual saving before committing. The open-source distribution has no schema registry, so the team runs one, and Control Center does not follow the team off Confluent Platform. Kpow works with Confluent Schema Registry, Apicurio Registry and Karapace, and Gmarket replaced Control Center with Kpow when it moved to community Kafka.

Does Kpow need anything installed on the Kafka brokers?

No. Kpow connects to the brokers with the same settings as a Kafka producer or consumer and keeps its own state in topics on the primary cluster it connects to, so there is no broker plugin, no metrics reporter and no external database.

Does Kpow work with Strimzi on Kubernetes?

Yes. Kpow publishes a Strimzi build that carries the OAuth libraries Strimzi needs, with documented settings for mutual TLS, SCRAM-SHA-512 and OAuth 2.0, and installs on Kubernetes with its Helm charts.

Which Apache Kafka versions does Kpow support?

Kpow’s documentation states compatibility with Apache Kafka 1.0 and later. On clusters in KRaft mode it also shows the quorum’s voters and observers. KRaft became available in Kafka 3.3 and reached feature parity in 3.9; the background is in Kafka KRaft.

Which Kafka UI works with Kafka 4.0 and KRaft?

Apache Kafka 4.0 is the first major release to run entirely without ZooKeeper, so a UI that still depends on ZooKeeper stops working at the upgrade. Kpow supports Apache Kafka 1.0 and later and shows the KRaft quorum’s voters and observers in its brokers view, so one install covers clusters still in ZooKeeper mode and clusters already on KRaft. CMAK has not shipped a release since April 2022 and does not support KRaft or Kafka 4.0, and three reports of Kafdrop’s topic view failing against KRaft clusters were closed as not planned. The replacements are compared in Kpow vs CMAK and Kpow vs Kafdrop.

Does Kpow work with a Kerberos-secured Kafka cluster?

Yes. GSSAPI is Kpow’s default SASL mechanism, and the Kerberos settings, including the service name and kinit command, are set as environment variables, as its Kafka cluster configuration documents. Kpow connects with the same client properties a Kafka producer or consumer uses, so no proxy or broker change is needed.

Does Apache Kafka include a schema registry?

No. The open-source distribution includes Kafka Connect but no schema registry, so teams run one alongside it. Kpow works with Confluent Schema Registry, Apicurio Registry and Karapace, and with several registries per Kafka cluster. The registries themselves are compared in Kafka schema registry tools.

Does Apache Kafka have an audit log?

Not one of its own. KIP-567, the proposal to add a cluster audit, was still under discussion when read on 2 October 2026. The broker writes an authorizer log to a file on each broker, and its entries are about principals, so when engineers work through a shared tool the log names the tool. A record of which person did what comes from the tool people sign in to; Kpow records every action, data inspect queries included, in an audit topic on the team’s own cluster.

Do Kafka ACLs expire?

No. An ACL stays in force until kafka-acls.sh or the Admin API removes it, so temporary access given by ACL depends on someone taking it away again. Time-boxed access comes from the tool: a Kpow temporary policy expires on its own after a set duration or at a chosen date and time.

Is Confluent Schema Registry open source?

Its source is public and it is free to self-host, and its repository states that the project is under the Confluent Community License, with the client modules under Apache 2.0. Karapace and Apicurio Registry are published under Apache 2.0. Kpow works with all three.

Does a Kafka UI replace Kafka ACLs?

No. Kafka ACLs still control what applications can do on the brokers. A tool such as Kpow adds per-person roles, masking, approvals and an audit trail for the engineers who work through it, and can manage the ACLs themselves, with each change recorded in its audit log.

How these tools were scored

Six criteria, each taken from what a team running open-source Apache Kafka owns itself, are listed here in order of weight. Each criterion is scored 0 to 10: 10 where a tool is the only one here doing it or clearly the best, 8 for a clean documented pass, 5 or 6 for partial support or support that needs work the reader must verify, 1 to 4 for a weak or indirect form, and 0 where it is absent.

1. Out of the data path (counts three times). The tool should run inside your own environment, reach the brokers over the same network your applications use as an ordinary Kafka client, and keep no data outside your own cluster. Scored lower: tools that need an external database of their own, and tools whose controls work only when application traffic passes through a vendor’s proxy. A self-hosted container with no external database and no proxy scores 9, a tool with a database of its own 6, one with several databases or a component on the brokers 4, and one that needs both a database and a proxy for its controls 3; 10 is kept for an option with nothing to deploy at all, here the command-line tools that ship with Kafka. This criterion is scored the same way on every Factor House page that uses it, and only its weight changes with the reader.

2. Production access on request (counts twice). Can an engineer be given read access to a production topic for a task, approved and time-boxed, without a standing grant? Can production writes be held for a second person’s approval? And is sensitive data masked for the people who do get in? The wider set of controls over deletes and offset resets is compared in Kafka destructive operations tools.

3. Audit trail per person (counts twice). When people work through a shared tool, the broker only sees the tool’s principal, so only the tool’s own log can name the person. That log should include data reads as well as changes, and be readable without building a consumer first. Kafka audit logging tools compares the layers in detail, and the controls regulated teams add on top are covered in Kafka governance tools for financial services.

4. Directory and Kafka sign-in (counts once). People should sign in through the company directory, whether LDAP directly or SAML and OIDC in front of it, with directory groups mapped to roles. On the cluster side the tool has to connect the way the team’s own listeners authenticate clients, which on self-managed Kafka can be any SASL mechanism or mutual TLS. Kafka SSO tools covers the protocol detail.

5. Many teams, shared clusters (counts once). Several teams on a handful of clusters need each team scoped to its own topics, consumer groups and connectors, so the platform team can onboard a team with a policy rather than a cluster.

6. Brokers, Connect and registries (counts once). A self-managed team owns the brokers, the Kafka Connect workers that ship with Apache Kafka, and the schema registry that does not. This criterion scores a broker view that stays accurate while a broker is offline, running broker configuration and the KRaft quorum, moving partitions with a plan, a throttle and a way to cancel, and managing several Connect clusters and Confluent-compatible registries per Kafka cluster. A tool scores 10 here only when it also plans, throttles and cancels partition moves. The reassignment tools are compared in the best tools to reassign Kafka partitions, and connector tooling in Kafka Connect monitoring tools.

The cost figures model a team running 3 clusters (development, staging and production) for 40 engineers at $120 an engineer-hour, using the same hours per tool class as Factor House’s other comparison pages. Tools with a licence carry the published price plus 2 hours a month to run. The open-source UIs carry 6 hours a month, $8,640 a year, to run, secure and keep current, and the command-line tools, with no access control of their own, 8 hours a month, $11,520. Kpow’s $16,380 is $4,500 per cluster with 100 users included, plus running time; Kpow Community Edition is free for 3 clusters and 10 users, so a 40-engineer team is on Enterprise.

The criteria map onto the parts of a self-managed cluster in the figure below.

F1 From a self-managed Kafka cluster to what the tool has to do

What the team runs What the tool has to do

Brokers Brokers and controllers in KRaft mode, or ZooKeeper mode on clusters older than Kafka 4.0 Show broker configuration, the KRaft quorum and under-replicated partitions, and stay accurate while a broker is offline

Cluster security Listeners secured with SASL (GSSAPI, SCRAM, PLAIN or OAUTHBEARER) or mutual TLS Connect with the same client properties any Kafka producer or consumer uses

Kafka Connect Connect ships with Apache Kafka and runs as the team's own worker clusters Manage several Connect clusters per Kafka cluster through the Connect REST API

Schema registry The open-source distribution has no schema registry, so the team picks and runs one Work with the Confluent-compatible registry the team runs, such as Confluent Schema Registry, Karapace or Apicurio

People Kafka ACLs authorise principals, and a shared tool connects as one principal Add per-person roles, production access on request, masking and an audit trail that names the person

Where the tool runs Producers and consumers connect to the brokers directly Run beside the cluster as an ordinary Kafka client, not as a proxy in front of it, and need no database of its own

Every option is scored from 0 to 10 on each criterion, from the evidence and sources this page cites, and the reason for each score is on its card. The criteria are weighted: Out of the data path counts three times, Production access on request counts twice, Audit trail per person counts twice, Directory and Kafka sign-in counts once, Many teams, shared clusters counts once and Brokers, Connect and registries counts once, for a total out of 100. Out of the data path counts three times because a team running its own Kafka also runs everything it adds to it: a tool that needs its own database is one more stateful service to back up, patch and keep available, and a tool whose controls work only through a proxy puts a component the team must operate in front of every producer and consumer. Production access on request and the per-person audit trail count twice, because broker ACLs authorise the principal a tool connects as, so once several teams share a tool these are the only controls on who could read or change production and the only record of who did. Directory and Kafka sign-in, many teams on shared clusters, and the brokers, Connect clusters and schema registries the team runs count once. This page is published by Factor House, which makes Kpow. Every option is scored on the same rubric and the same sources: Kpow's per-criterion scores are set the same way as every other option's and are not adjusted, and the weights apply to every option alike. Kpow ranks first on its total of 89 out of 100. The other options follow by total. Conduktor is listed last whatever its total; on its total of 57 it would place third.

Related reading

• Kafka: the complete guide
• Apache Kafka vs Confluent Kafka
• Migrating to open source Kafka: cutting TCO without the operational burden
• How Gmarket replaced Control Center with Kpow
• How Claritev cut Kafka support costs with Kpow
• Best Kafka UI tools for Amazon MSK
• Best Kafka management tools for banks
• AKHQ vs Kafbat UI
• Run Kpow in Kubernetes with Helm
• Best Kafka UI tools for OCI Streaming with Apache Kafka