# Kafbat UI keeps the Apache Kafka project's console lineage, and ships Swagger enabled

> kafbat's kafka-ui is a Java and TypeScript web console for Apache Kafka clusters, offering topic and consumer inspection, pluggable authentication, RBAC, data masking and an MCP server. Two details are worth reading before the copy paste command: the quick start publishes port 8080 with only two feature flags set and no authentication configured, and the persistent example tracks a latest tag.

**kafbat/kafka-ui** — Open-Source Web UI for managing Apache Kafka clusters

- Repository: https://github.com/kafbat/kafka-ui
- Website: https://kafbat.io
- Stars: 2,751 · Forks: 427
- Language: TypeScript
- License: Apache-2.0
- Published: 2026-09-28 · Updated: 2026-09-28 · Language: en
- Canonical page: https://hysenlabs.com/projects/kafbat-kafka-ui

## The page names its own ancestor instead of claiming to be original

The most honest paragraph on the page is the italic one near the top. Kafbat UI, developed by Kafbat, carries forward the legacy of the UI Apache Kafka project, and the team is described as key contributors from that project's inception. The page also extends gratitude to Provectus for past support in groundbreaking work. That is the whole history section: there is no migration guide, no comparison table against the earlier project, and no changelog summary. The version numbers are the other signal. The newest release is v1.5.0 from 20 April 2026, the two before it are v1.4.2 and v1.4.1, both from 12 November 2025, and the last commit on the default branch is dated 28 September 2026, so roughly five months of work sit on the branch with no tag to point at.

## The demo command publishes 8080 with no authentication configured

The quick start is one line, and it is the line most people copy:

```bash
docker run -it -p 8080:8080 -e DYNAMIC_CONFIG_ENABLED=true -e SWAGGER_UI_ENABLED=true ghcr.io/kafbat/kafka-ui
```

Two feature flags, one published port, and nothing else. No authentication variable appears anywhere in it, while the feature list advertises OAuth 2.0 with GitHub, GitLab and Google, LDAP, basic authentication, role based access control, cloud IAM integration and data masking for sensitive values in topic messages. SWAGGER_UI_ENABLED is what turns on the built in Swagger specification of the full API, so the same command that gives you topic creation also documents every endpoint that topic creation goes through. Fine on a laptop, worth changing before the port faces a network you do not control.

## The persistent example follows a latest tag and mounts a yml onto a yaml path

The persistent installation is a compose file, and it repeats the demo's two flags while changing almost nothing else:

```yml
services:
  kafbat-ui:
    container_name: kafbat-ui
    image: ghcr.io/kafbat/kafka-ui:latest
    ports:
      - 8080:8080
    environment:
      DYNAMIC_CONFIG_ENABLED: 'true'
      SWAGGER_UI_ENABLED: 'true'
    volumes:
      - ~/kui/config.yml:/etc/kafkaui/dynamic_config.yaml
```

Three things stand out. The tag is latest and no pull policy is set, so what you run is whatever the registry served most recently. The host path ends in .yml while the container path ends in .yaml, which makes grepping for the file by name harder than it needs to be. And the environment block carries the same two flags as the demo, so the persistent install is also a Swagger enabled install, not a hardened one. The page does point onward for the rest: a configuration file explanation, a page of miscellaneous configuration properties, compose examples, Helm charts and a devcontainer.

## Dynamic config and Swagger are the two switches the examples turn on

Strip the examples down and two variables carry all the behaviour. DYNAMIC_CONFIG_ENABLED turns on changing configuration at runtime rather than only at build or start, which is convenient for a cluster browser and means the running container's settings are not the same thing as its file. SWAGGER_UI_ENABLED exposes the API specifications through a built in Swagger interface. Everything else is described as environment variables and configuration properties documented on a separate site, which is a deliberate split: this page holds two commands and links, and the reference material lives elsewhere. Build tooling follows the same pattern, with a quick start for prerequisites for building from source and a Helm chart quick start, plus a web UI cluster configuration wizard for setting up a cluster from inside the browser. An MCP server is listed among the features, alongside the Swagger interface, which puts two machine readable entry points on the same deployment.

## The message browser decodes Avro and filters with CEL expressions

Reading messages is the reason most people open a Kafka console. The browser handles JSON, plain text and Avro encodings, supports a live view, and takes user defined message filters written in CEL, the Common Expression Language, so filtering happens on message content rather than by offset guesswork. Encoding support extends past reading. The schema registry section names three schema types, Avro, JSON Schema and Protobuf, and requires a schema to be registered for a topic before Avro or Protobuf encoded messages are produced. Deserialisation is pluggable: built in serializers and deserialisers include AWS Glue and Smile, and the page states you can supply your own custom plugins, which is how an internal Avro registry or a non standard codec gets read in the browser.

## Identity is the widest surface: OAuth, LDAP, basic, cloud IAM and RBAC

Authentication is described as pluggable, with OAuth 2.0 covering GitHub, GitLab and Google, plus LDAP and basic authentication. On top of that sit cloud IAM integrations for GCP, Azure and AWS, and support for the managed Kafka services themselves: Azure EventHub, Google Cloud Managed Service for Apache Kafka, and AWS Managed Streaming for Apache Kafka, in both server based and serverless forms. Authorisation is separate from login: role based access control manages granular UI permissions, and a data masking feature obfuscates sensitive data in topic messages for privacy and compliance. Read that pair together with the message browser and you can see the intended shape, which is a console shared across a team where not everyone should see every payload, rather than a single operator's dashboard.

## Consumer lag is shown as parked offsets, per partition and combined

The inspection features are specific about the numbers they show, which is what makes them useful during an incident. Topic insights cover partition count, replication status and custom configurations, and topics can be created and configured from the browser with your own parameters. The brokers view shows partition assignments and which broker is controller. Consumer group details list parked offsets per partition and track lag both combined and per partition, so a stalled consumer is visible as a parked offset rather than as a throughput dip. Navigation ties the three together, letting you move from a connector to its topics and from a topic to its consumer groups and back. Orchestration hooks are named concretely too: the liveness and readiness endpoint is /actuator/health, and the info endpoint, described as build info, is /actuator/info. Both sit on the same port as the interface, so whatever fronts the container has to route them, and an endpoint reporting build information deserves a thought before it faces a wider network.

## A Gradle backend, a TypeScript frontend and a TypeSpec contract layer

The repository is not one application. The top level carries build.gradle, settings.gradle, gradle.properties, gradlew and gradlew.bat plus a .java-version file for the server side, a frontend directory for the TypeScript UI, api and serde-api directories, and both contract and contract-typespec directories, the second naming the TypeSpec layer that describes those contracts. There is an e2e-playwright directory for browser level tests, a documentation directory, a devcontainer directory and a .dev directory, and also a directory literally named etc at the root. Two smaller observations about the page itself: the Interface heading is followed straight away by the Features heading with nothing between them, and the Support section at the bottom begins a sentence and stops, so the support policy is not stated here.

## Conclusion

This console is a reasonable default for anyone who needs to see what a Kafka cluster is doing without writing code against the admin APIs, and the parts that matter operationally are named rather than implied: probes on actuator health, a Swagger toggle, RBAC, data masking and a documented configuration surface. Three things to settle first. The quick start is a demo, not a deployment: it binds 8080, leaves authentication unconfigured and turns on the full API specification, so anything you copy from it into a shared network needs an auth method and a firewall first. The persistent example follows a latest tag with no pull policy, so restarts quietly change versions and you should pin a tag and read the release notes. And the lineage note is worth reading as history rather than marketing: this is the successor to the older Apache Kafka project UI, with a 1.x line whose newest tag predates the last commit by months.

## FAQ

### what is kafka ui

The repository is kafbat/kafka-ui, whose product is Kafbat UI, a free and open source web UI to monitor and manage Apache Kafka clusters. It tracks brokers, topics, partitions, production and consumption, browses and produces messages, and carries RBAC, data masking and pluggable authentication.

### What are the differences between Kafbat UI and Kafka UI?

The page does not list differences; it describes lineage. It says Kafbat UI carries forward the legacy of the UI Apache Kafka project, that the team is made up of key contributors from that project's inception, and that it thanks Provectus for past support. It is licensed Apache-2.0 and the version line is 1.x, with 1.5.0 published on 20 April 2026.

### Does the Kafbat UI quick start command configure authentication?

No. It sets only DYNAMIC_CONFIG_ENABLED and SWAGGER_UI_ENABLED and publishes port 8080, while the authentication options listed as features are OAuth 2.0 with GitHub, GitLab and Google, LDAP, basic authentication, cloud IAM and role based access control. Swagger being enabled also publishes the full API specification.

### What health and info endpoints does Kafbat UI expose?

The liveness and readiness endpoint is /actuator/health and the info endpoint, described as build info, is /actuator/info. Both sit on the same port as the web interface, so whatever fronts the container has to route them.

### Which message formats and filters does the Kafbat UI message browser handle?

JSON, plain text and Avro, with a live view and user defined message filters written in CEL. The schema registry supports Avro, JSON Schema and Protobuf, and serialisation is pluggable, with built in support including AWS Glue and Smile plus the option of custom plugins.

### What does the Kafbat UI persistent compose example mount and which tag does it use?

It mounts the host file ~/kui/config.yml onto /etc/kafkaui/dynamic_config.yaml, publishes 8080, and sets DYNAMIC_CONFIG_ENABLED and SWAGGER_UI_ENABLED to true. The image reference is the latest tag with no pull policy set, so a restart can change the version under you.

## Sources

- [kafbat/kafka-ui on GitHub](https://github.com/kafbat/kafka-ui)
- [License: Apache-2.0](https://github.com/kafbat/kafka-ui/blob/main/LICENSE)
- [Project website](https://kafbat.io)
- [README](https://github.com/kafbat/kafka-ui/blob/main/README.md)
- [Releases](https://github.com/kafbat/kafka-ui/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/kafbat-kafka-ui