KubeMQ v3

KubeMQ v3.1.4 · August 2026. KubeMQ v3 is the largest release in the product's history. Since v2.10.1, KubeMQ has been rebuilt around a new replicated storage core and extended to speak the messaging protocols your teams already use — Kafka, RabbitMQ, MQTT, AMQP 1.0/JMS, STOMP, AWS SQS/SNS, Google Pub/Sub, and CloudEvents — directly, with no bridges and no code changes.

Everything your applications rely on today keeps working. The native gRPC, REST, and WebSocket APIs and all four messaging patterns — Queues, Events, Events Store, and Commands/Queries — are unchanged, and in-place upgrades preserve your data and configuration automatically.

Highlights at a glance

• Drop-in protocol support — your existing Kafka, RabbitMQ, MQTT, AMQP 1.0, STOMP, SQS/SNS, and Google Pub/Sub clients connect directly to KubeMQ, unmodified.
• New storage engine — a Raft-based replication and persistence core with a selectable durability contract, alongside the existing engine, which remains fully supported.
• Ten client SDKs — the five you use today (Go, Java, C#/.NET, TypeScript, Python) upgraded for v3, plus five new: C++, Kotlin, Ruby, Rust, and Elixir.
• Framework integrations — Spring Boot, NestJS, Celery, FastStream, MassTransit, .NET Aspire, Ray Serve, Watermill, and KEDA autoscaling.
• Rebuilt management dashboard — per-protocol consoles, live configuration editing, accounts with roles, audit trail, six languages.
• New kmq CLI — messaging, cluster administration, observability, and a guided Kafka migration workflow from one binary.
• OpenTelemetry — distributed traces and metrics exported over OTLP.
• Enterprise security — role-based access control for the management plane, API keys and service accounts, audit logging, and FIPS builds.
• AI-ready — a built-in Model Context Protocol (MCP) server and Agent-to-Agent (A2A) support for agentic workloads.
• New Developer Center — this documentation site.

Protocol connectors — use your existing clients

In v2, connecting non-KubeMQ clients meant deploying separate connector containers next to the broker. In v3, the broker itself speaks each protocol on its native port. The same client that talks to Kafka, RabbitMQ, or SQS today talks to KubeMQ tomorrow. All connectors are disabled by default and enabled per protocol in configuration; CloudEvents is on by default. A migration guide is available for each ecosystem.

The built-in connectors supersede the separate kubemq-targets, kubemq-sources, and kubemq-bridges deployments for the protocols above. The external connector containers remain available for other integrations — databases, caches, and third-party services.

New storage engine

v3 introduces a new replicated storage engine built on Raft consensus, designed for stronger durability guarantees and safer day-2 operations. Full details: Storage engines.

• Two engines, one server. The v2 engine ("legacy", unchanged) and the new engine ("next") ship in the same binary and are selected in configuration. New deployments can adopt the next engine; existing ones stay on legacy until they choose to migrate.
• Selectable durability contract on the next engine. In strict mode, a message is acknowledged only after it is replicated to a quorum and written to disk — zero acknowledged-message loss, even through node crashes. In fast mode (the default), acknowledgment follows quorum replication, with disk sync completing in a bounded background window.
• Engine auto-detection. On upgrade, the server inspects the existing data directory and resolves the correct engine on its own. It never wipes or reinterprets data on a mismatch — ambiguity is a loud startup error, not a silent guess.
• Log compaction and time-based retention on the next engine — the same mechanisms that enable Kafka Connect and Kafka Streams support.
• Engine scope. The Kafka connector requires the next engine. All other connectors and all native messaging patterns run on both engines.

Clustering and operations

Clustering has been rebuilt around the new engine with one focus: predictable failure handling.

• Safe node replacement. A node that returns with lost or empty storage no longer rejoins silently. It stays up, reports the reason on its readiness endpoint, and is restored through an explicit, guided kmq cluster replace procedure that re-adds it as a learner until it has caught up.
• Calmer elections. Pre-vote prevents a rejoining node from disrupting a healthy cluster, and leader changes warm up connector state — Kafka coordinators included — before serving traffic.
• Kubernetes-aware lifecycle. Replica identity derives from the pod name, readiness is decoupled from liveness (a booting node reports live while quorum forms, avoiding restart loops), and shutdown phases are sized to the pod's termination grace period.
• Replication security. Optional mutual TLS on the cluster replication port.

New kmq command-line tool

One installable binary for everything that previously needed scripts, curl, or the dashboard. Full reference: kmq CLI.

• Messaging — send, receive, peek, stream, and purge queues; publish and subscribe to events; replay the Events Store from six starting positions; send commands and queries and run responders.
• Cluster administration — inspect health, members, and nodes; add, promote, remove, and replace members. Mutations are role-gated and confirmation-gated.
• Observability — live connection watch, metrics, audit queries, and connector and agent inspection.
• Kafka migration workflow — kmq assess kafka produces a read-only migration-fitness report of an existing Kafka cluster; kmq migrate replicates topics with exact offset mapping, translates configuration, and manages cutover.
• Automation-friendly — machine-readable output, typed exit codes, dry-run support, and a complete offline schema of every command.

Client SDKs — ten languages

The SDK family has doubled from five languages to ten, all covering the four messaging patterns over the native gRPC API, each documented with working examples per pattern. Start here: Client SDKs.

• Upgraded — Go, Java, C#/.NET, TypeScript (Node.js), and Python: updated and fully compatible with v3.
• New — C++, Kotlin, Ruby, Rust, and Elixir.

Framework integrations

Adapters for the frameworks your teams already use — you keep writing idiomatic framework code; the adapter handles the messaging underneath: Spring Boot, NestJS, Celery, FastStream, MassTransit, .NET Aspire, Ray Serve, Watermill, and KEDA autoscaling on queue depth. Details: Integrations.

Management dashboard — rebuilt

What was a monitoring view in v2 is now a full management console, protected by login and roles. See Web dashboard.

• Cluster overview — health, throughput, storage-engine status, and replication posture per node.
• Per-protocol consoles — dedicated pages for Kafka, RabbitMQ-style queues, MQTT clients, AMQP 1.0 links, STOMP destinations, SQS/SNS, Google Pub/Sub, and CloudEvents, each modeled on the console your team already knows.
• Live configuration — view and change every subsystem's settings from the UI, with revert support and role gating.
• Accounts and roles — user accounts, service accounts, and API keys managed in the UI.
• Audit trail — a searchable log of who changed what, and when.
• Channel monitor — a live, observe-only tap on any channel.
• Six languages — English, Spanish, French, German, Portuguese (Brazil), and Italian, in light and dark themes.

Observability

• OpenTelemetry — distributed traces and metrics exported over OTLP (gRPC or HTTP), with W3C trace-context propagation and configurable sampling. Off by default. Setup: OpenTelemetry guide.
• Metrics that survive restarts — counters are durable; a server restart no longer resets your Prometheus series.
• Per-connector metrics — dedicated metric families for every protocol connector.
• Audit logging — control-plane and data-plane events recorded as CloudEvents with configurable retention, queryable from the API, the CLI, and the dashboard. On by default.

Security and access control

The management plane — dashboard and management API — is now protected by full authentication and role-based access control. Reference: Security.

• Management-plane access control — user accounts with session login and service accounts with API keys; three roles (read-only, read-write, admin); deny-by-default on every management endpoint; hardened credential storage, login throttling, and CSRF protection. Off by default — existing deployments are unaffected until you enable it.
• Safer defaults — the management port binds to localhost unless authentication is enabled or the server runs in a container or Kubernetes; secrets are redacted from configuration views.
• Data-plane security carried forward — TLS/mTLS, JWT and OIDC authentication, and policy-based authorization continue as in v2, extended to the new protocol connectors.
• FIPS builds — a dedicated FIPS image line, cryptographically verified and vulnerability-scan-gated before publication.
• Signed supply chain — release images are vulnerability-scanned before publication; CLI artifacts ship with signed checksums.

AI and agentic workloads

KubeMQ speaks the two emerging standards for AI-agent communication out of the box. Start here: AI Way.

• Model Context Protocol (MCP) server built in — AI assistants and agents send, receive, and inspect KubeMQ messages through standard MCP tools, with no extra infrastructure.
• Agent-to-Agent (A2A) protocol — agent registration and discovery, agent cards, synchronous request/reply, and streaming responses, backed by a cluster-replicated agent registry.
• Dedicated dashboard pages for agent and MCP activity.

Kubernetes and deployment

Install guide: Kubernetes with Helm.

• Helm charts — cluster, controller, CRDs, and an umbrella chart.
• Declarative cluster resource — a zero-configuration KubemqCluster custom resource; every connector and subsystem is configurable in the spec, with per-connector service exposure.
• Guard rails — the operator records the cluster's established storage engine and refuses unsafe changes (engine switches, enabling Kafka on a legacy-engine cluster) instead of applying them silently.
• License visibility — license type, holder, and expiry surfaced directly in kubectl get.
• Escape hatches — an environment-variable overlay and secret projection for tunables the typed spec doesn't cover, with a deny-list protecting settings the operator owns.

Breaking changes at a glance

• Helm installation — the v2 stable chart line is retired. v3 charts are published on the prerelease channel and require --devel on install and upgrade.
• Storage engine choice is per-deployment — there is no in-place migration between the legacy and next engines. A data directory created on one engine cannot be opened by the other; the server fails loudly rather than converting.
• Node-rebuild recovery sets a version floor — cluster nodes rebuilt with the v3 recovery procedure cannot roll back below v3.1.0.
• Kafka requires the next engine — enabling the Kafka connector on a legacy-engine deployment is a configuration error.
• Management API surface changes — some management and statistics endpoints changed between v2 and v3.
• Storage sizing on the next engine — native retention limits (maximum retention, queue size, and message caps) currently apply on the legacy engine only; plan storage for next-engine channels accordingly.
• External connector containers superseded — the separate targets/sources/bridges deployments are replaced by built-in connectors for broker protocols; they remain available for other integrations.

Known limitations

• MQTT retained messages are not supported; the broker advertises this to connecting clients.
• AMQP 0-9-1 transactions are not supported.
• STOMP transactions and selectors are not supported.
• Kafka — replication factor is always cluster-managed; the next-generation consumer protocol (KIP-848) and Kerberos are not supported.
• Native retention limits are not yet enforced on next-engine channels.

Upgrading

In-place upgrades from v2.10.x keep your data and configuration — the server detects your existing storage automatically. Adopting the next storage engine or the Kafka connector is a planned migration; see Storage engines and the per-ecosystem migration guides.

Questions? Reach us at support@kubemq.io.