Redpanda Console: a Kafka and Redpanda web UI for topic, consumer group and schema work

The gap Redpanda Console fills between kafka-topics.sh and a dashboard

Operating a Kafka cluster without a UI means a rotation of shell tools. Checking whether a consumer group has stalled, reading a specific message to see why a deserializer failed, or confirming that an ACL actually landed all become separate commands with separate output formats. Redpanda Console puts those operations behind one web application. The README describes it as a developer-friendly UI for managing Kafka and Redpanda workloads, and lists message viewing, consumer groups, topic overview, cluster overview, security (ACLs and SASL-SCRAM users), schema registry, Kafka Connect and Redpanda Transforms as the covered areas.

The audience is narrower than "anyone with a Kafka cluster". The prerequisites state Redpanda or any Kafka deployment at v1.0.0 or later, plus a browser. There is no mention of a hosted service, no account model, and no multi-tenant story in the README. This is a tool a platform team runs next to the cluster it already operates, usually on an internal network. It was previously known as Kowl, which matters if you are searching for older documentation or issues under that name.

One detail worth noting: the README does not describe role-based access control for Console itself. Security features listed are about managing Kafka ACLs and SASL-SCRAM users, not about restricting what a Console visitor can see. Anyone who can reach the port can use whatever credentials the deployment was configured with.

How the message viewer and the rest of the backend are put together

The repository is split into backend/ and frontend/, with proto/ holding the interface definitions and buf.gen.*.yaml files generating code for the backend, the frontend and an OpenAPI description. That layout tells you the shape of the system: a Go backend speaks the Kafka protocol and exposes an API, and a TypeScript/React frontend consumes it. The topics list includes both go and typescript, and the generated OpenAPI artifact is the contract between them.

The message viewer is the part with the most mechanism behind it. According to the README, you explore topic messages through ad-hoc queries and dynamic filters, and you can write JavaScript functions to filter messages. Supported encodings are JSON, Avro, Protobuf, CBOR, XML, MessagePack, Text and Binary with a hex view. The README states that the encoding is recognized automatically except for Protobuf and CBOR, which means those two require you to tell Console what you are looking at. That is a real constraint: an unrecognized Protobuf payload will not decode into readable fields on its own.

Time-travel debugging, named in the project description, is the payoff of that design. Because Console can page back through a partition rather than only tailing the latest offsets, you can reconstruct what a consumer saw at a given point. The README does not spell out retention or how far back the viewer can seek, and the practical limit is whatever your broker still holds on disk.

Topic documentation can be embedded from a git repository, per the feature list. That is a small thing that changes how a team uses the tool: the meaning of a topic lives next to the topic in the UI instead of in a wiki nobody opens.

Installing Redpanda Console and pointing it at a local broker

The README points to dedicated installation documentation and says prebuilt Docker images, binary builds and a Helm chart are offered. The quick start assumes a cluster already exists and uses Docker. The container has its own network scope, so a broker on your host is reached through host.docker.internal, and the README warns that the advertised listener must match, for example PLAINTEXT://host.docker.internal:9092, because brokers return a list of all brokers' DNS to a connected client.

docker run -p 8080:8080 -e KAFKA_BROKERS=host.docker.internal:9092 docker.redpanda.com/redpandadata/console:latest

After this, Console listens on port 8080. Open http://localhost:8080 in a browser and you should see the cluster overview with your brokers listed.

On Linux, Docker supports --network=host, and the README recommends using localhost:9092 as the advertised listener with the host network namespace so Console runs as if executed on the host machine.

docker run --network=host -p 8080:8080 -e KAFKA_BROKERS=localhost:9092 docker.redpanda.com/redpandadata/console:latest

For a remote cluster protected by SASL_SSL, the README gives this form, with the Confluent Cloud example as the illustration:

docker run -p 8080:8080 -e KAFKA_BROKERS=pkc-4r000.europe-west1.gcp.confluent.cloud:9092 -e KAFKA_TLS_ENABLED=true -e KAFKA_SASL_ENABLED=true -e KAFKA_SASL_USERNAME=xxx -e KAFKA_SASL_PASSWORD=xxx docker.redpanda.com/redpandadata/console:latest

If you have no cluster to test against, the README points at a docker-compose file under /docs/local that launches Redpanda and Console together. That is the lowest-friction way to see the message viewer before touching production.

The frontend has its own quality gate: the README says it uses react-doctor to statically analyze React components for performance anti-patterns, run with bun run doctor from the frontend/ directory, and that it also runs in CI on every push and pull request. That is relevant only if you plan to modify the frontend.

Where Redpanda Console stops being the right tool

The README describes visibility and workload management, not cluster administration. There is no mention of creating topics with replication assignments, rebalancing partitions, changing broker configuration, or provisioning a cluster. If your problem is that a broker is undersized or a partition is skewed, Console will show you the symptom through the cluster overview and partition details, and then you go elsewhere to fix it.

The authentication model is the second boundary. Console connects to Kafka with the credentials you hand it through environment variables such as KAFKA_SASL_USERNAME and KAFKA_SASL_PASSWORD. The README lists creating, listing and editing Kafka ACLs and SASL-SCRAM users as features, which is management of the cluster's own security objects. It does not describe per-user login for the Console UI. On a shared internal network that may be acceptable. Exposed more widely, it is a single shared view of every topic the configured principal can read.

Encoding support has a sharp edge too. Automatic detection covers JSON, Avro, XML, MessagePack, Text and Binary, but Protobuf and CBOR need to be specified. Teams whose entire event backbone is Protobuf will find the viewer works, but not without configuration per topic or message.

Finally, the README does not document rollback, downgrade paths or compatibility guarantees between Console releases and specific broker versions. The stated floor is Kafka v1.0.0 or later, and that is the only version guidance in the README.

Redpanda Console against AKHQ and kafdrop

The obvious comparison is AKHQ, another open source Kafka web UI. The practical difference is breadth of integrations rather than the topic browser, which both provide. Redpanda Console's feature list reaches into Schema Registry management for Avro, Protobuf and JSON schemas, Kafka Connect clusters with connector config patching and task restarts, and Redpanda Transforms for clusters that are actually Redpanda. AKHQ covers similar ground for Kafka Connect and schema registries, but Redpanda Transforms is specific to this project's vendor.

kafdrop sits at the other end. It is a lighter topic browser with a smaller surface, and it does not attempt consumer group offset editing, ACL editing or connector management. If all you want is to look at messages in a topic, the extra surface of Console is extra deployment to maintain.

The honest framing: Console is built by Redpanda Data and its feature set tilts toward Redpanda clusters, with Kafka compatibility as the stated baseline. If you run Apache Kafka and nothing else, you get the full topic, consumer group, schema and Connect functionality, but the Transforms section will have nothing to show you.

Maintenance cadence, licence and the cost of upgrading

The project is not archived. The last push to the default branch was on 2026-09-22, and releases have arrived steadily: v3.12.0 on 2026-09-16, v3.11.0 on 2026-08-25, v3.10.0 on 2026-08-10. That is roughly a monthly minor cadence with patch releases between, which for an operations tool means you should expect to move versions rather than pin one for years.

Upgrade cost is mostly in configuration drift. Console is configured through environment variables such as KAFKA_BROKERS, KAFKA_TLS_ENABLED, KAFKA_SASL_ENABLED, KAFKA_SASL_USERNAME and KAFKA_SASL_PASSWORD, and the deployment options are Docker, a single binary or a Helm chart. Docker and Helm make a version bump a tag or chart-version change. A single binary on a host means you own the restart and the config file. The README does not document a migration procedure between major or minor Console versions, so treat the CHANGELOG.md at the repository root as the thing to read before upgrading rather than after.

The licence is not stated in the README, and the repository carries a licenses/ directory. That directory is where the answer lives, and it is worth reading before you build Console into a product or redistribute the binary. This is not legal advice; it is a pointer to where the actual terms are recorded. The README also points to CONTRIBUTING.md and a code of conduct for anyone intending to send patches.

Editorial conclusion

Adopt Redpanda Console if you already operate a Kafka v1.0.0+ or Redpanda cluster and want a browser surface for message inspection, consumer group offsets, schema registry entries and ACLs without writing scripts for each lookup. Skip it if you need a UI that provisions clusters or manages broker configuration, since the README scopes it to visibility and management of workloads rather than cluster lifecycle. Before rolling it out, verify two things: that your advertised listener resolves correctly from inside the Console container, because the brokers return their own advertised addresses to the client, and that the licence file under licenses/ covers your deployment model, since the README does not state a licence identifier.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. redpanda-data/console on GitHub
5. Releases