A k9s for Redpanda
The sagacious reader will have noticed this blog’s fondness for Redpanda by now. My homelab keeps everything in its topics (part I), I patched the broker itself to read them by key (part II), and the serialization experiment that became parco was born streaming trades through it. Today the streak continues with something smaller: I’ve released readpanda, a terminal UI for looking inside those topics.
The itch
My inspection loop was rpk topic consume piped through jq. That
works until the topic is Avro, where the payload is a magic byte, a
schema id and bytes jq won’t touch. Then the loop grows a curl to the
schema registry and a decode script, multiplied by however many topics
I’m watching. k9s solved this shape of problem for Kubernetes years
ago: stop composing the inspection by hand, put the operator inside the
cluster. I wanted the same seat for my broker.
What it does
readpanda is a Bubble Tea TUI over any Kafka-compatible cluster. It
draws the topics as a tree, folding the dot hierarchy
(shop.orders.v1, iot.sensors.temperature) into branches you expand
and filter. Drill into a topic and you get a live tail that decodes
Avro, JSON Schema and Protobuf inline through the schema registry, so
the wire bytes come out as the JSON you actually wanted. The other tabs
cover consumer groups with their lag, partitions, topic config and
brokers. The keys are k9s keys, because my fingers already knew them.

Try it
The repo ships a demo: a docker-compose with a single-node Redpanda, a seed script that creates nine topics in a dot hierarchy, and a traffic generator that publishes Avro orders and JSON telemetry while a deliberately slow consumer builds up lag. Two terminals and you’re in:
just demo-up
just demo-traffic
go run ./cmd/readpanda --brokers localhost:19092 --sr-url http://localhost:18081
It’s early and it’s read-only, which for a tool you point at production is less a limitation than a promise. If it breaks on your cluster, I’d rather hear about it than not.