Kafka-King puts a desktop UI on franz-go and covers Kafka 0.8 to 3.8

The architecture is a Go backend and a web view

Kafka-King is based on Wails and franz-go, and the README also acknowledges naive UI and xicons. That combination explains most of its behaviour.

Wails puts a Go binary behind a native window with a web view, so the application is a single executable rather than a server plus a browser tab. There is no deployment, no port to expose and nothing to host. For an administrator sitting in front of a cluster, that is the difference between a tool you run and a service you stand up.

franz-go is the Go Kafka client library doing the protocol work, which explains the version range: the README states support for Kafka 0.8.0 to 3.8 and later, across desktop systems except Windows 7.

That range is the practical differentiator. Client libraries accumulate breaking changes across Kafka versions, and a GUI that only supports recent brokers is useless for the clusters that are actually hardest to look at, namely the old ones nobody wants to touch.

The default branch is `wails`, not master or main, which tells you the development line is named after the framework and that the older architecture lived elsewhere.

There is an `AGENTS.md` at the repository root, indicating the project keeps coding-agent instructions in the repository.

Beyond the topic list

Most Kafka GUIs do the same four things: list brokers, list topics, peek at a message, show consumer lag. Kafka-King's feature list is much wider, and the extra items are the ones that tell you what it is for.

The cluster and configuration side covers viewing the node list and dynamically configuring broker and topic settings, topic creation with batch operations specifying replicas and partitions, partition detail with offsets and the ability to add partitions, and enhanced node inspection including a broker controller indicator, LogDirs disk usage analysis and client quota management.

The message side is where it becomes more than a viewer. You can consume from a topic with group, size and timeout parameters and see the messages in a table. You can simulate producer behaviour, sending in batches with headers and explicit partition selection. There is multi-instance streaming consumption with reverse ordering, tab management and manual or automatic offset commit. Messages can be replayed to other topics, exported as JSON or CSV, and purged with DeleteRecords up to a target offset, for specific partitions or all of them.

Offsets get first-class treatment: statistics per topic covering total message count, committed offset and lag per consumer group, offset inspection reports introduced in v0.33, and consumer group offset reset to start, end, a specific timestamp or an explicit offset.

Partition replica reassignment is the item that stands out. Visual inspection and adjustment of partition replicas with cancellation support is an operation with real consequences, and having it in a GUI means an operator can do it without a bespoke script.

Authentication and Schema Registry

The authentication list is broad enough to cover most real deployments: PLAIN, SSL, SASL, Kerberos, sasl_plaintext, plus extended support for OAUTHBEARER with a static token, AWS MSK IAM, and multi-broker SSH tunneling.

SSH tunneling per broker is the feature that matters for restricted networks. A managed Kafka cluster reachable only through a bastion means the client needs a tunnel per broker, and support for that inside the GUI removes the most common reason people give up and go back to scripts.

AWS MSK IAM matters for anyone on AWS managed Kafka, since IAM-based auth is not the same as SASL username and password and tools that do not implement it are simply unusable there.

Schema Registry support covers subject and version management, compatibility configuration, and decoding for Avro, JSON and Protobuf messages. Message decoding is the part that changes usability: without it, a Protobuf payload is bytes, and inspecting whether a message is correct becomes guesswork.

Connection management is also worth noting. Connections can be exported to YAML and imported from YAML or JSON, with what the README calls smart deduplication. For someone who maintains a saved list of cluster connections, being able to move that list between machines, and share it with a team, is a real convenience.

Getting it running, and the four things that will bite

Binaries are published on the releases page as assets for Windows, macOS and Linux, so there is no build step for ordinary use.

The README's important notes cover four failure modes, and each is the kind of thing that costs an afternoon.

First, `advertised.listeners` must be correctly configured on your cluster. If it is not configured, or domain names are used, you need matching domain name resolution entries in the hosts file of the machine running the client, otherwise the connection fails on an unresolved name even though you typed IP addresses into the app. That is a Kafka client behaviour rather than a Kafka-King bug, but this app surfaces it.

Second, TLS. Enable TLS and ignore verification unless you have a certificate, in which case enable TLS verification and give the certificate path.

Third, SASL users must enable SASL and pick the right protocol, usually plain, then supply the credentials.

Fourth, on Windows, webview2 runtime errors are fixed by reinstalling the WebView2 runtime from Microsoft.

On macOS there is an extra step. The app is unsigned and blocked by Gatekeeper, so it shows as damaged on open, and the fix is:

xattr -dr com.apple.quarantine /Applications/Kafka-King.app

That is a routine workaround for unsigned applications, and worth reading as a signal about how the project distributes: there is no notarisation and no signature, so the security assessment is on the person running it.

Development, translations and release cadence

To work on the project you need Go, Node.js and npm, plus the Wails CLI installed with `go install github.com/wailsapp/wails/v2/cmd/wails@latest`. Development runs from the `app` directory with `wails dev`.

The `app/` directory is therefore the application itself and the rest of the repository is documentation, which matches the top-level entries of `.github/`, `.gitignore`, `AGENTS.md`, `LICENSE`, `README-CN.md`, `app/` and `docs/`.

Localisation is the other visible effort. The README header links twelve language versions including Chinese, Japanese, Korean, Russian, Spanish, French, German, Portuguese, Italian, Vietnamese and Indonesian, stored under `docs/readme/`, and there is a dedicated issue for fixing or adding a language.

The release cadence is high. The recent tags are v0.47-beta, v0.47-beta.2 and v0.47 all on 2026-09-09, and the last push was the same day. Publishing two betas and the final within a few hours of each other is what a pre-release channel looks like when the maintainer wants feedback before tagging.

The repository is not archived, and the licence is Apache-2.0.

The homepage links to an AI Doc at zread.ai, and the maintainer lists an Elasticsearch client, an HDFS client and an AI coding assistant as related projects.

Editorial conclusion

Adopt Kafka-King if you administer Kafka clusters from a desktop and want topic, consumer group and message inspection without a web console, especially if your clusters speak a Kafka version an older GUI dropped. Do not adopt it as a production pipeline component or as an access-control boundary, since it is an unsigned desktop app holding cluster credentials. Verify first that your cluster's advertised.listeners resolves on the machine running the app, that your SASL mechanism and TLS setup match what the app expects, and that you are comfortable with the macOS quarantine workaround, since the app is not signed.

Frequently asked questions

Official sources

1. Bronya0/Kafka-King on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases