Replace Kafka with KubeMQ

Your Kafka client keeps its library, its code, and the real Kafka wire protocol — only bootstrap.servers changes, from your Kafka cluster to a local KubeMQ server.

Drop-in level: endpoint-only (legend)

1 · Enable the connector

The Kafka connector is disabled by default — enable it and publish its ports:

docker run -d \  --name kubemq \  -p 9092:9092 \  -p 9093:9093 \  -p 50000:50000 \  -e KUBEMQ_TOKEN=YOUR_LICENSE_KEY \  -e CONNECTORS_KAFKA_ENABLE=true \  europe-docker.pkg.dev/kubemq/images/kubemq:next

2 · Point your client at KubeMQ

# Before (Kafka)
bootstrap.servers=your-kafka-cluster.example.com:9092

# After (KubeMQ)
bootstrap.servers=localhost:9092

Same client library, same producer/consumer code — only the seed broker address moves.

3 · Smoke test

Produce and consume one record with kcat (the librdkafka CLI needs no client code at all):

echo "hello kubemq" | kcat -b localhost:9092 -t orders -P

kcat -b localhost:9092 -G orders-group -o beginning -c 1 orders

-o beginning reads from the start of the topic, so a brand-new consumer group still sees the record you just produced (without it, a fresh group starts at the latest offset and the consumer would block waiting for the next message).

The producer is silent on success; the consumer prints the record body (kcat also logs consumer-group rebalance lines to stderr). You should see:

hello kubemq

This is the same round-trip as Getting Started, which also covers the same produce/consume flow in Go, Python, Java, JavaScript, C#, Ruby, and Rust — no kcat required.

What carries over — and what doesn't

Your client library, code, topic and consumer-group names, and produce/consume semantics all carry over unchanged — only the broker address moves. Bringing an existing cluster's topic history and consumer offsets across (rather than starting fresh) is a separate step covered by the migration guide's kmq migrate tool.

Didn't work?