Fork-owned documentation

Operate Kafka with a sharper, production-first control surface.

UI for Apache Kafka combines cluster visibility, topic tooling, auth controls, schema operations, and message inspection in one place. This fork keeps the documentation in the product repo, so runtime guidance, IAM support, release behavior, and build instructions move with the code instead of drifting in a separate docs system.

Start with Docker EKS and MSK IAM Build from source

Kafka 3.9.1 baseline JDK 21 GHCR releases EKS to MSK IAM on 9098

Demo route Config route Compose route Project route

Cluster visibility, message browsing, consumer offsets, schema operations, and auth-heavy runtime configurations are documented next to the implementation they describe.

fork runtime contract

docker run -it -p 8080:8080 \
  -e DYNAMIC_CONFIG_ENABLED=true \
  ghcr.io/chenrui333/kafka-ui:latest

# EKS + MSK IAM
security.protocol=SASL_SSL
sasl.mechanism=AWS_MSK_IAM
bootstrap.servers=<broker>:9098

Image source GitHub Container Registry

Release model Immutable GitHub releases

Local toolchain mise + JDK 21 + Node 24

Primary target Ops-heavy Kafka environments

Choose your route

Three clean entry points, depending on the job you need to do

The documentation is organized for the workflows operators actually run: stand the UI up quickly, wire it into real infrastructure safely, or work on the fork itself without guessing where the project boundaries live.

Operators

Run it now

Use the GHCR image, get a demo deployment up, then move into persistent config and Helm once you know the shape fits.

Demo run Persistent start Configuration file

Platform

Secure the runtime

Auth, TLS, RBAC, data masking, IAM, and compose labs are grouped so the production-facing controls are easy to reach.

AWS IAM RBAC Kafka with SSL

Contributors

Change the fork deliberately

Build instructions, contribution guidance, and the project roadmap stay in the same repo as the code and release flow.

Build prerequisites Contributing Roadmap

Operational focus

This fork’s runtime guidance is opinionated on purpose

The docs are not trying to be a generic upstream mirror. They call out the actual contract this fork is optimized around: GitHub-hosted releases, GHCR images, JDK 21 builds, Kafka 3.9.1 compatibility, and the EKS to MSK IAM shape on broker port `9098`.

Fork-owned docs Repo-linked compose labs Ambient AWS credential path No separate docs repo

application.yaml sketch

kafka:
  clusters:
    - name: msk-eks
      bootstrapServers: b-1.example.amazonaws.com:9098
      properties:
        security.protocol: SASL_SSL
        sasl.mechanism: AWS_MSK_IAM
        sasl.client.callback.handler.class: software.amazon.msk.auth.iam.IAMClientCallbackHandler
        sasl.jaas.config: software.amazon.msk.auth.iam.IAMLoginModule required;

What this site owns now

Docs, examples, and release behavior now point at the same repo

The main value of this migration is operational integrity. Examples, screenshots, release instructions, and fork-specific behavior now live together, which removes the old split between product code and external docs.

Runtime docs

Configuration and auth stay local

Configuration wizard, file-based config, Helm guidance, RBAC, masking, TLS, and IAM all resolve inside this site.

Scenario examples

Compose labs stay versioned with the code

Compose examples and their supporting SSL, JMX, JAAS, and proto assets are versioned alongside the application.

Release contract

Images and releases match this fork

The docs point at `ghcr.io/chenrui333/kafka-ui` and the repository’s immutable release process, not a generic upstream image lane.

Contributor context

Roadmap and build paths are explicit

Contributors can move from docs to build prerequisites to issues without having to discover a second docs repo or stale project board.

Docs stack MkDocs Material

Pages source GitHub Actions deploy

Container source GitHub Container Registry

Best first stop Getting started or AWS IAM