Best Kafka CLI tools

The Kafka CLI is the set of shell scripts in the bin/ directory of every Apache Kafka distribution, such as kafka-topics.sh and kafka-consumer-groups.sh. The main alternatives are kcat, kafkactl, kaf, kcl, rpk, the Confluent CLI, Zoe, kt and the Kpow CLI, fh. On Amazon MSK, the AWS CLI adds topic commands to the cluster control plane.

They differ on six things: how much of the admin job they cover, whether they can hold contexts for several clusters, which authentication they support, whether their output and defaults are safe for scripts and AI agents, whether anyone still maintains them, and what a year of running them costs. Kpow is Factor House’s product, and I work at Factor House as a Solutions Architect, so it is scored on the same rubric and the same sources as every other option. The complete Kafka guide covers the wider tooling picture.

What the Kafka CLI is

Apache Kafka ships its administration tools as scripts under bin/. The Apache Kafka operations documentation puts it this way: “All of the tools reviewed in this section are available under the bin/ directory of the Kafka distribution and each tool will print details on all possible commandline options if it is run with no arguments.” Each script is a thin wrapper that starts a JVM and calls the official Java Admin, Producer or Consumer client, so the scripts support a new protocol feature on the day it is released.

Since Kafka 4.0 the admin tools connect through --bootstrap-server, because ZooKeeper mode has been removed. A command copied from an older blog post with --zookeeper in it will not run against a 4.x cluster.

The built-in tools

Five scripts do most of the day-to-day work:

• kafka-topics.sh creates, lists, describes, alters and deletes topics.
• kafka-console-producer.sh writes lines from stdin to a topic.
• kafka-console-consumer.sh reads a topic to stdout.
• kafka-consumer-groups.sh lists and describes groups, shows lag per partition and resets offsets.
• kafka-configs.sh describes and alters topic, broker, client and user configs.

Behind them sit kafka-acls.sh, kafka-reassign-partitions.sh, kafka-leader-election.sh, kafka-metadata-quorum.sh and a dozen more. The commands themselves, grouped by the job you are doing and checked against the Kafka 4.3 tool sources, are in Kafka CLI commands for day-2 operations. This page is about choosing the tool that runs them.

Where the built-in scripts fall short

The scripts are complete and they are awkward. A solution architect at a foodservice distributor described life before they adopted any tooling in our published case study: “I remember needing to move an offset and thinking, okay, somebody dig out that shell script and let’s CLI this.” Their Kafka use had grown to a dozen product teams and roughly 130 developers, which CLI scripts and open-source tooling could not keep pace with.

The friction comes from four places:

• Authentication is a properties file (--command-config) holding the principal’s credentials, passed on every call, and whoever holds that file holds that principal’s access.
• The output is a human-formatted table. kafka-topics.sh, kafka-consumer-groups.sh, kafka-configs.sh and kafka-acls.sh have no JSON mode, so scripts parse whitespace.
• Each invocation targets one cluster. There is no notion of a named context, so the difference between staging and production is one flag value in your shell history.
• Access control is Kafka ACLs on the principal and nothing else. There is no approval step, no staged change and no record of who ran what beyond the broker’s view of the client.

How we scored the Kafka CLIs

Each tool is scored 0 to 10 on six criteria. The first five come from the tool’s own documentation or README, read on 22 September 2026. The sixth is our own cost model, set out below.

1. Coverage of the admin job

Coverage means topics, consumer groups and their offsets, ACLs, configs, and producing and consuming test messages, all from one tool. In my talk on Kafka operational incidents two of the recurring fixes were CLI jobs: making offset resets “a deliberate, manual operation”, and auditing running broker configs because “some environments keep a break-glass option for emergency config changes that never quite makes it back into GitOps”. A CLI that covers only produce and consume leaves you back in bin/ for both.

2. Multi-cluster contexts

A context stores a cluster’s address, credentials and defaults under a name, so switching from staging to production is an explicit act rather than an edited flag. Tools that support contexts make the target visible and the credentials reusable without copying them into every command. The same problem in a web UI is covered by the best tools to manage multiple Kafka clusters.

3. Auth and access control

The CLI has to speak the cluster’s authentication: SASL SCRAM, OAUTHBEARER, mutual TLS or AWS IAM. The harder question is what the person or process at the keyboard is then allowed to do. Our team has heard it from prospects directly: letting users create and manage topics took CLI and API workarounds, and what they wanted was the same capability with guardrails. The foodservice team solved it by giving only their two solution architects delete access and everyone else scoped, self-service permissions. The best tools for Kafka RBAC compares how each product enforces that kind of split.

4. Scripting and agent safety

Scripts and AI agents need structured output and safe defaults. When I demonstrated the Kpow CLI, I pointed at the --output json flag and said “that’s what your agents will use”, and the same logic applies to every tool here. Safe defaults matter as much: a destructive command that previews before it applies, or refuses when nobody is at the terminal, stops an agent that misread its instructions. OWASP names the risk Excessive Agency and advises: “Avoid the use of open-ended extensions where possible (e.g., run a shell command, fetch a URL, etc.) and use extensions with more granular functionality.”

5. Maintenance status

Kafka keeps changing its tooling contract. Kafka 4.0 removed ZooKeeper mode, and Kafka 4.2 renamed a set of tool options for consistency (KIP-1147). Share groups are production-ready in 4.2. A CLI with no commits in years will not know about any of it. Last commit dates are from the GitHub API on 22 September 2026.

6. Annual cost, our estimate

An open-source licence costs nothing to hold, which is why the licence column below still matters, and a licence is only one line of what a CLI costs. The figure on each card is our own estimate rather than any vendor’s quote, for one scenario: 100 engineers across three clusters, engineer time at $120 an hour. It adds three lines.

The licence: $0 for the open-source and source-available CLIs, and $13,500 a year for three clusters of Kpow Enterprise at the published $4,500 per cluster with 100 users included.

The tool’s own upkeep, in engineer-hours a month: the glue that turns its output into something a script can read, the work a missing command pushes back into bin/, and what it costs when nobody has committed to the project in years.

The governance a client-side CLI leaves to you, which is 12 engineer-hours a month, or $17,280 a year, for every tool here that holds broker credentials in a local file. That covers one least-privilege principal per engineer per cluster, 300 of them at this size, issued, rotated and revoked, and a record of who ran what, because the CLI keeps none. A consume-only tool carries 5 engineer-hours a month instead, since a read-only principal still has to be issued and there is no change to record.

Two results are worth stating plainly. At six engineers the same sum favours the free tools, because the governance line shrinks with headcount and a licence does not. And a low figure can mean a tool that does less: Zoe’s $17,280 buys searching and reading records, not administration. The score follows the figure mechanically, 10 below $12,500 and one point lower for each $2,500 band above that.

Kafka CLI tools compared

Rank	Tool	Coverage	Multi-cluster contexts	Auth	Scripting and agent safety	Maintained	Licence and annual cost	Source
1	Kpow CLI (fh)	Topics, brokers, groups and offset resets, Connect, schemas, quotas, reassignments, transactions. No produce, consume or ACLs	Named contexts, tenant and cluster switching	Kpow’s single sign-on (OIDC), RBAC and tenancy, or basic auth	--output json or yaml on every command, staged writes reported as staged. No dry run stated	Released 22 Sep 2026	Needs Kpow: $13,500/yr for 3 clusters, about $16,380 all in on our estimate	Demo page
2	kcl	Everything, plus transactions, quotas, share groups and a schema registry client	Named profiles	TLS, SASL PLAIN, SCRAM and AWS_MSK_IAM	Stable --format json, --help-json, prompts answer no without a terminal, --dry-run	Last commit 18 Sep 2026	BSD-3-Clause, $0 licence, about $20,160/yr on our estimate	GitHub: twmb/kcl
3	kafkactl	Topics, groups, offsets, ACLs, broker configs, SCRAM users, produce and consume with Avro, JSON Schema and Protobuf	Named contexts, project config files, Kubernetes	TLS, SASL including OAuth token providers for Azure and AWS, OS keyring	-o json or yaml on describe and consume, offset reset previews until --execute	Last commit 30 Jul 2026	Apache-2.0, $0 licence, about $21,600/yr on our estimate	GitHub: deviceinsight/kafkactl
4	Confluent CLI	Confluent Cloud and Platform: clusters, topics, API keys, produce and consume, Flink	--context	Confluent Cloud login and API keys, REST Proxy credentials on-premises	-o json or yaml	Last commit 21 Sep 2026	Confluent Community License, $0 licence, about $23,040/yr on our estimate	Confluent’s documentation, “Confluent CLI Overview”
5	rpk	Topics, ACLs, produce and consume, cluster config, framed for Redpanda	Profiles	SASL, TLS	--format json or yaml	Last commit 20 Aug 2026	Source-available (BSL), $0 licence, about $23,040/yr on our estimate	Redpanda’s documentation, “Introduction to rpk”
6	Apache Kafka bundled scripts	Everything: topics, groups, offsets, ACLs, configs, reassignment, quorum, produce and consume	None, one --bootstrap-server per call	Every mechanism the Java client supports, through a properties file	No JSON output. Offset reset is a dry run until --execute, ACL removal prompts unless --force	Yes, ships with each release	Apache-2.0, $0 licence, about $28,800/yr on our estimate	Apache Kafka docs
7	kaf	Topics, groups, produce and consume, offset commits	Named clusters	Configured per cluster, see its examples	JSON lines for consume only, offset commits apply immediately	Last commit 19 Apr 2026	Apache-2.0, $0 licence, about $24,480/yr on our estimate	GitHub: birdayz/kaf
8	Zoe	Filtered consume, group offsets, Avro schema upload	Cluster aliases in config	Not documented in its README	Table output shown	Last commit 1 Dec 2024	MIT, $0 licence, about $17,280/yr on our estimate	GitHub: adevinta/zoe
9	kcat	Produce, consume, metadata. No admin	One config file	Any librdkafka property	-J JSON for consume and metadata	Last commit 17 Nov 2022	BSD-style, $0 licence, about $25,920/yr on our estimate	GitHub: edenhill/kcat
10	kt	Produce, consume, topic info, offsets, topic create and delete	Environment variables	TLS only	JSON in and out	Last commit 26 Oct 2023	MIT, $0 licence, about $27,360/yr on our estimate	GitHub: fgeller/kt

The rank column runs in the order of the cards further down the page: the Kpow CLI first because it is our product, then every other tool by total, highest first. The annual figures are our estimate of what a year of running each tool costs at 100 engineers across three clusters, built from the model in criterion 6, and not a price any vendor charges.

How the options score

Totals out of 60: kcl 51, kafkactl 49, the Kpow CLI 46, the Confluent CLI 45, rpk 43, the bundled scripts 37, kaf 34, Zoe 32, kcat 27 and kt 25. The Kpow CLI sits third on total because it gives up coverage points for the strongest access control on the list. The cards below list the Kpow CLI first because it is our product, then every other tool by total, highest first. No total has been adjusted to put it there.

On coverage, the bundled scripts and kcl are the only two tools that do the whole job, and kafkactl comes close. kcat, kt and Zoe are message tools with little or no administration. The Kpow CLI covers the administration but not message data yet. As I said in the demo, “The only thing we don’t support at the moment is data consumption and data production”. It also has no ACL command.

On contexts, kafkactl leads, with named contexts, config files that live in a project repository, and a mode that runs inside Kubernetes. kcl, rpk and the Kpow CLI all hold named contexts or profiles. The bundled scripts and kcat have none.

On auth and access control, every client-side tool is only as safe as the credentials in its config file. The Kpow CLI works differently: a server-side policy in Kpow’s RBAC decides what each signed-in person can do, rather than whichever Kafka principal a file holds. On Amazon MSK, the AWS CLI’s topic commands are governed by IAM policy in a similar way.

On maintenance, kcat, kt and Zoe have gone quiet. kcat is still everywhere and still useful for a quick consume, but it has had no commits since November 2022.

On annual cost, the Kpow CLI comes out lowest at about $16,380 a year on our estimate, in spite of being the only option with a licence to pay for, because the 300 per-engineer Kafka principals and the hand-kept record of who ran what that every client-side CLI needs at this size are already in the deployment. Zoe is next at about $17,280, and that figure buys searching records with no administration at all. kcl is about $20,160, and the bundled scripts are the most expensive on the page at about $28,800, because nothing they print is machine readable. The web UIs that do the same jobs are scored the same way in the best Kafka management tools, and the free tiers on their own in the best free Kafka UI tools.

Which Kafka CLIs are safe to hand to an AI agent

An agent with shell access runs whatever the CLI and its credentials allow. Three properties decide whether that is acceptable:

1. Structured output, so the agent reads JSON instead of guessing at column boundaries. kcl, kafkactl, rpk, the Confluent CLI, kt and the Kpow CLI all provide it. The bundled scripts do not.
2. Safe defaults on destructive commands. kcl is the strongest: its README says that “When stdin is not a terminal the prompt answers no and the command prints the plan it would have carried out and exits 0”. The bundled kafka-consumer-groups.sh --reset-offsets and kafkactl’s reset offset both preview until told to execute.
3. Permissions that belong to the person, not the file. A client-side CLI acts as whichever principal its config holds, so the only control is a least-privilege Kafka principal, and Kafka’s own ACL documentation is explicit that a resource with no matching ACL is restricted to super users. The Kafka ACL page covers designing that principal. The Kpow CLI calls the Kpow API as the signed-in user, so an RBAC policy can allow, deny or stage each action for that user.

No single tool wins all three. kcl has the best client-side safety, the Kpow CLI has the only server-side approval step on this list, and the bundled scripts have neither structured output nor per-user control. For an agent on a production cluster, pick either a read-only Kafka principal with kcl, or the Kpow CLI with an RBAC policy that stages writes. The rest of an agent’s setup, from its identity to its audit trail, is in how to let an AI agent operate Kafka safely. The best tools to control destructive Kafka operations compares approval workflows beyond the CLI.

1. Kpow CLI (fh)

The Kpow CLI, fh, is a client for the Kpow API rather than a Kafka client of its own, so it needs a Kpow deployment and inherits that deployment’s single sign-on, RBAC and tenancy. Version 0.7.0 was published on 22 September 2026, and it scores 46 out of 60 on the rubric above, third on total and the lowest annual cost on the page at about $16,380.

2. kcl

kcl tops the rubric at 51 out of 60, with full marks for coverage and the highest score on this page for scripting and agent safety. It is the tool to reach for when a script or an AI agent will be running the commands rather than a person.

3. kafkactl

kafkactl follows at 49 out of 60 and takes the best score here on multi-cluster contexts. It suits engineers who move between many clusters, Kubernetes networks and Avro or Protobuf payloads in the same afternoon.

4. Confluent CLI

The Confluent CLI scores 45 out of 60, on continuous maintenance and structured output against a narrower coverage score and the work of running it next to a cluster it was not built for. It is the right tool on Confluent Cloud and the wrong one on a plain Apache Kafka cluster with no REST Proxy in front of it.

5. rpk

rpk scores 43 out of 60. Its coverage score is capped because its documentation does not state general Apache Kafka support, so the total says more about fit than about quality.

6. Apache Kafka bundled scripts

The scripts under bin/ score 37 out of 60, with full marks on coverage and maintenance, the lowest score on this page for contexts, and the highest annual cost of any option here at about $28,800 on our estimate. They are already present on most brokers and jump hosts, which is why the rest of this page is measured against them.

7. kaf

kaf scores 34 out of 60, and at 2,442 GitHub stars it is the most starred of the community Go CLIs here, ahead of kafkactl’s 1,070 and kcl’s 232, which matters when you are searching for help with one of them. Its gaps are on the administration side rather than in everyday inspection.

8. Zoe

Zoe scores 32 out of 60, with its highest marks on cost and contexts, because it does not attempt cluster administration at all, and the cost score reflects a tool that reads records and nothing more. Its last commit was on 1 December 2024.

9. kcat

kcat scores 27 out of 60, with the lowest maintenance score on this page and one of the highest on authentication, because any librdkafka property works and nobody has committed to it since November 2022.

10. kt

kt is last on the rubric at 25 out of 60, on TLS-only authentication, no named contexts and a maintenance score of 3. Its JSON contract is the reason it is still worth knowing.

Other Kafka CLIs worth knowing

A few more tools come up in the same searches. They are narrower, so they are listed rather than scored:

• kcctl manages Kafka Connect connectors with kubectl-style commands. Last commit 26 June 2025.
• Strimzi Kafka CLI (kfk) gives kafka-script-style commands for Strimzi resources on Kubernetes.
• plumber reads, writes and relays messages across Kafka, RabbitMQ, GCP Pub/Sub and others. Last commit 24 December 2024.
• Trubka consumes and publishes Protobuf and plain text. Last commit 18 April 2025.
• Conduktor CLI applies Conduktor Console and Gateway resources declaratively, so it needs Conduktor.
• The AWS CLI’s aws kafka commands manage Amazon MSK clusters and, through list-topics, describe-topic, create-topic, update-topic and delete-topic, MSK topics. It has no consumer group, offset, ACL or message commands, so it sits beside a Kafka client rather than replacing one.

If you would rather have a keyboard-driven view than a command line, the Kpow CLI also launches a terminal UI with fh tui, which the best Kafka terminal UIs scores against the open-source ones. For the web UI side of the same decision, see the best Kafka management tools.

How Factor House approaches the CLI

The Kpow CLI, fh, is a client for the Kpow API rather than a Kafka client of its own. “The CLI uses the Kpow API to let you access almost anything you can do from the Kpow web application,” as I put it in the CLI and agentic skills demo. Version 0.7.0 was published on 22 September 2026 as a Homebrew cask in the factorhouse/homebrew-tap repository and as archives for macOS, Linux and Windows.

The design choice that matters is identity. From the demo: “it runs with your existing single sign-on (OIDC) setup, your existing RBAC rules, and your existing tenancy configuration, if you have one set up. So your CLI users, terminal UI users, and agentic users all get the same control and governance in place”. Kpow’s RBAC documentation shows the effect options a policy can take: allow, deny or stage. A write that a policy stages comes back from the CLI as “Mutation staged for admin approval” instead of being applied. That puts the approval step on the server, where the person or agent running the command cannot switch it off.

The trade-offs are the ones in the scores. It needs a Kpow deployment, it cannot produce or consume messages yet, it has no ACL commands, and offset resets take explicit offsets per partition. For those jobs, the bundled scripts or kcl sit alongside it. The per-job comparisons for resetting consumer group offsets and managing Kafka ACLs go deeper on each.

Kpow live demo

Watch the Kpow CLI and terminal UI

See the fh CLI inspect brokers and topic assignments, switch to JSON output for scripts and agents, and sign in through the same single sign-on as the Kpow web UI.

Built for platform engineers who run Kafka from a terminal.

Watch the demo→

Which one to choose

• On any Apache Kafka cluster, for one-off admin with nothing to install beyond Kafka: the bundled scripts.
• For scripts and AI agents on a client-side CLI: kcl, for its JSON contract and its refusal to run destructive commands without a terminal.
• For engineers juggling many clusters, Kubernetes access and Avro or Protobuf data: kafkactl.
• For a quick consume or metadata check: kcat, accepting that it is unmaintained.
• On Confluent Cloud: the Confluent CLI. On Redpanda: rpk. On Amazon MSK, for cluster and topic control: the AWS CLI, with one of the Kafka clients above for groups and data.
• When the people or agents running commands should be governed by the same single sign-on, RBAC and approval rules as your Kafka UI: the Kpow CLI, alongside a message tool until produce and consume arrive.

FAQ

What is the Kafka CLI command to list topics?

bin/kafka-topics.sh --bootstrap-server localhost:9092 --list lists every topic the principal can describe. Add --exclude-internal to hide internal topics such as __consumer_offsets. The equivalents are kafkactl get topics, kcl topic list and fh kafka topic list.

Is there a GUI for Kafka?

Yes. Web UIs such as Kpow, AKHQ and Kafbat UI, and desktop tools such as Offset Explorer, cover the same jobs as the CLI with a browser or desktop interface. The best Kafka management tools compares them, and the top Kafka UI tools for engineering teams scores the wider field on governance and deployment.

What are Kafka tools?

Kafka tools are the programs used to operate a cluster: the command-line scripts that ship with Kafka, third-party CLIs such as kcat, kafkactl and kcl, and UIs and monitoring tools built on the Admin API. The CLI tools are compared on this page.

How do I install the Kafka CLI?

Download an Apache Kafka binary release, extract it, and run the scripts from its bin/ directory. They need a Java runtime, and they only need network access to a broker, not a local Kafka server. Most third-party CLIs install as a single binary through Homebrew or a release download.

Related reading

• Kafka: the complete guide
• Kafka CLI commands for day-2 operations
• Kafka consumer groups
• Kafka ACL
• Kafka security architecture for production
• How to let an AI agent operate Kafka safely