DEV Community: Kafma

A New Kafka Viewer for a Better Debugging Workflow

KafmaKarma — Fri, 07 Aug 2026 01:40:40 +0000

Kafma is a new Kafka UI client for macOS, Windows, and Linux, built to keep the debugging workflow in one workspace. Each topic opens as a persistent Console tab that keeps its message stream, producer, topic details, schema context, and consumer state together.

A Kafka browser can help you find and read a record, but debugging usually continues beyond it. You need to inspect its metadata and schema, check what a consumer group has processed, reproduce the input, and observe what happens next.

Each step is straightforward on its own. The friction comes from moving between separate consumer, producer, Schema Registry, topic, and consumer-group views and rebuilding the same context each time. Kafma keeps those parts of the investigation together, so the debugging loop becomes shorter: find the records, inspect their context, create a controlled test, and watch the result.

Kafka debugging loses context easily

Consider a common debugging sequence:

Consume a bounded set of records around the time an issue occurred.
Find the relevant key or payload and inspect its headers, partition, offset, and timestamp.
Resolve the schema and check whether the record was encoded as expected.
Check the consumer group’s position and whether the record is still in its backlog.
Reuse the record as a test case or produce a modified version.
Watch the new input arrive, then check whether the target consumer group processes it and advances its committed position.

This is one investigation, but it is often spread across several commands and screens. Copying only the payload between them is not enough: message keys, headers, schemas, partitions, and consumer positions are all part of the context.

The missing piece is not another isolated view. It is a workspace that keeps the message, schema context, topic details, consumer state, and producer together throughout the investigation.

A persistent workspace for each topic

In the Console, each topic opens in its own tab. The message stream occupies the upper part of the tab, the producer stays available below it, and a topic-details drawer opens beside them. Several topic tabs can remain open at once, so one investigation does not need to replace another.

The Console also remembers the open tabs for each cluster connection. If you switch from a production cluster to a local cluster and later return, the topics you were investigating are still open. Each cluster has its own tab set, which helps prevent local and production work from being mixed together while keeping both workspaces ready.

This matters when a problem crosses environments: you can keep the source cluster’s context intact while reproducing the issue in a local cluster.

Find and inspect the relevant messages

A busy topic may contain far more data than one investigation needs. Start with a bounded snapshot from the newest records, the beginning, a specific offset, or a timestamp. Then narrow the loaded records by key, value, or partition.

Kafma reads these records directly from the brokers. Opening or refreshing a Console tab does not join an application consumer group, trigger a rebalance, or commit offsets, so inspection does not change the consumer state you are trying to understand.

Expand a record to see its key, value, headers, partition, offset, timestamp, size, and compression. When Schema Registry is connected, Kafma resolves the schema ID and automatically decodes Avro, Protobuf, and JSON Schema records. The original bytes remain available in the Raw view, which is useful when the serializer, schema, or wire format may be part of the problem.

For the individual controls and decoding behavior, see Consuming messages and Decoding Avro and Protobuf messages.

Inspect the topic without leaving the Console

A suspicious record often raises questions about the topic around it. Is a partition unhealthy? What is the retention policy? Which consumer groups use the topic? How much data is currently retained?

The topic-details drawer answers those questions without replacing the message stream. It shows topic health, message count, retention, partitions, and the consumer groups associated with the topic. This keeps the topic details, selected record, and producer visible in the same tab.

Keeping the details beside the stream avoids a common break in the debugging flow: navigating to a separate topic or consumer page, finding the same resource again, and then returning to the original message.

Watch a consumer group in the message stream

Lag is more useful when you can connect it to the records waiting to be processed. In Watch Group mode, the Console shows a bounded window around a selected consumer group’s committed positions and marks records as consumed, pending, or unassigned.

The same view includes member status, total lag, and the lag trend. A divider separates the remaining backlog from the most recently consumed record, so you can inspect the messages at the front of the lag rather than looking at a number in isolation.

Kafma reads the group’s committed positions without joining the group. Watching it therefore does not add a member or trigger a rebalance in the application you are debugging.

This closes an important gap in the workflow: the message contents and the consumer’s progress are visible in the same investigation.

Reuse messages across topics and clusters

Once you find a representative record, you should not have to reconstruct it by hand.

Replay to topic opens a producer for the current topic or another topic in the same cluster and fills in the record’s key, value, and headers. The result is an editable draft, not an immediate write. You can change the payload, choose a partition or schema version, and review everything before producing it.

For a quick cross-cluster test, Forward to cluster sends one record or the currently loaded, filtered set to the same topic name on another cluster. Kafma blocks forwarding to clusters marked as Production. Schema-backed records are forwarded as decoded JSON or text rather than retaining their original Schema Registry encoding. Export is also available when the current records need to be saved as JSON or CSV for a test or shared investigation.

Replay and forwarding solve different problems. Replay creates a controlled, editable test case; forwarding moves messages directly. Forwarding does not copy Schema Registry subjects or topic configuration. When the destination needs the topic’s schemas, configuration, and a selected range of source data, use Data Clone instead.

See Replay and export Kafka messages for the exact behavior of each action.

Keep a producer loop running while you debug

Some consumer behavior is difficult to test with a single record. An application may aggregate a stream, process periodic events, or fail only after several inputs arrive.

The Console producer can send one message manually or run on a timed Loop. A loop can repeat the current key, value, and headers at a fixed interval. If the key or value is bound to a Schema Registry subject, the loop can regenerate that field on every tick with a fresh schema-compatible payload.

The loop continues while you switch to other Console tabs or pages in the same cluster. You can keep generating test traffic while inspecting another topic, checking a consumer group, or following a different part of the debugging flow. Return to the source tab to see the sent count or stop the loop. Closing the source tab stops the loop.

This makes Loop useful for simulating a producer that reports continuously while you work on the consumer side. It is intended for repeatable functional testing, not throughput benchmarking.

See Producing messages for payload encodings, schema generation, partitions, acknowledgments, and Loop controls.

More than a Kafka viewer

The value of one workspace is not simply that several controls fit on one screen. It is that the investigation remains intact:

The topic stays open as a tab.
The message stream and producer share the same context.
Topic details and consumer state are available without leaving the Console.
A producer loop can continue while you inspect other resources.
Each cluster preserves its own set of open investigations.

A conventional Kafka viewer can show which records are in a topic. For debugging, the useful unit is larger: Kafma keeps the topic, message metadata, schema context, consumer state, producer, and active investigation together even when you switch between clusters.

Download Kafma for macOS, Windows, or Linux, or read the Console documentation for a complete reference.

Introducing Kafma: A Desktop Kafka UI for Faster Debugging

KafmaKarma — Sat, 01 Aug 2026 13:55:37 +0000

Kafma is a desktop Kafka GUI client and IDE for macOS, Windows, and Linux. It keeps the consume–inspect–produce loop in one workspace and lets you clone remote topics—with their configurations, schemas, and a selected range of messages—into a local cluster for testing, with optional field masking.

Disclosure: I'm the creator of Kafma. It is closed-source software with Free and Pro plans.

Debug Kafka in one workspace

A topic opens as a tab in Kafma. Messages appear at the top, while the producer stays open at the bottom. You can send a message, inspect the result, change the payload, and send it again without leaving the topic tab.

Each topic keeps its own state, so several investigations can remain open at the same time. Live tails new messages as they arrive. Watch Group opens a bounded window around a consumer group's committed positions, showing consumed and pending records alongside member status, lag, and backlog.

Kafma automatically decodes Avro and Protobuf records using the configured Schema Registry. Expand a record to inspect its decoded key and value, headers, timestamp, partition, offset, and schema metadata. From there, you can replay it to a topic in the same cluster. Pro also supports forwarding records to another cluster and exporting results as JSON or CSV.

The producer handles JSON, text, Avro, and Protobuf. It can send a single record or run on a timed loop. With schema-based auto-generation enabled, each interval creates a fresh schema-compatible payload. That makes it possible to exercise a consumer and inspect the results from the same topic tab.

Clone remote topics for local testing

Some failures depend on the configuration, schemas, and records in a remote environment. Recreating that context locally often requires exports, scripts, and manual setup.

With Pro, Kafma's Data Clone makes a one-time, bounded copy between connected clusters. The Free plan supports same-cluster clones. Select one or more topics, choose a time window or offset range, and copy the topic structure, the schema versions required by the selected records, and the records themselves. You can also copy structure and schemas without data when you want to produce your own test records.

This is intended for focused debugging and test setup, not continuous cluster replication. Data Clone does not join a consumer group, commit offsets, or modify topics, messages, or schemas on the source. On the target, Kafma can create missing topics and register the required schemas; copied records are appended rather than overwriting existing records.

Optional masking rules transform selected fields in schema-backed message values before records are written to the target cluster. A pre-flight plan shows the selected range, schemas, masking rules, and planned target operations before the clone begins. Together, those controls make it practical to bring the context around a remote failure into a local or test cluster without writing back to the source.

Review schema changes before publishing

Kafma includes a Schema Registry workspace for Avro, JSON Schema, and Protobuf. When you create a new version, the selected registered version appears beside an editable draft. The diff updates as you type, making added and removed lines visible before the new version reaches the registry.

You can browse version history, generate mock data from a registered schema, and validate a JSON payload against a selected version in Schema Lab. When you publish a draft, Kafma runs the Schema Registry compatibility check as part of the same workflow and shows the result alongside the changes.

More than a message browser

The same desktop app also covers the operational work around a debugging session. You can inspect consumer-group members, assignments, committed offsets, and partition lag; reset or delete offsets; and manage topics while viewing broker and topic configuration.

Connections can be marked read-only to block Kafka and Schema Registry writes. Selecting Production turns on read-only mode automatically, though you can turn it off when writes are required. A Data Clone into a writable production target also requires typed confirmation. Kafma keeps a local activity log for operations performed in the app and can revert supported configuration and offset changes.

Kafma connects to self-hosted Kafka, Confluent Cloud, and Amazon MSK, with support for SASL, mTLS, OAuth, and AWS IAM authentication.

Available on macOS, Windows, and Linux

Kafma connects directly from your device to the Kafka clusters and Schema Registries you configure. Kafka data does not pass through Kafma's servers, and the app has no accounts, analytics, or telemetry.

The Free plan includes the core produce, consume, live-tail, schema-decoding, topic and consumer-group management, Schema Registry workflows, and same-cluster cloning. Pro adds unlimited clusters and tabs, cross-cluster cloning and forwarding, message export, and a higher Console message limit. Download Kafma to get started with the Free plan, or see pricing for Pro.

The Kafma 1.0 changelog contains the complete feature list and more screenshots.

What is the most frustrating part of your Kafka debugging workflow today?