Deployment and licensing
Run on infrastructure you control. Licensing is quoted by package tier; infrastructure and operating costs are separate. Compare total costs.
KubeMQ
Your messaging.
Your infrastructure.
Bring queues, event streaming, and request/reply together on one enterprise messaging platform. Connect through familiar protocols and run on infrastructure you control.
KubeMQ product overview Check release notes for version-specific changes.
The clients you already use
KafkaRabbitMQMQTTAMQP / JMSSTOMPSQS / SNSGoogle Pub/SubCloudEvents
Direct protocol connections
KubeMQ
Messaging · Replication · Management
Your Kubernetes environment
On-premises · Private cloud · Hybrid · Edge
KubeMQ at a glance
Self-managed enterprise messaging for queues, event streaming and request/reply. Check the release notes and linked compatibility references for the version you deploy.
Protocol support
Connect supported Kafka, RabbitMQ, AMQP 1.0, MQTT, STOMP, SQS/SNS and Google Pub/Sub clients. Support has protocol-specific boundaries. Read capabilities and limitations.
Persistence and recovery
Storage engine, acknowledgment policy and replication configuration affect durability. Select and test these settings for your workload. Review storage and security.
Security requires configuration
Messaging authentication, authorization and management access controls are independently off by default. Configure applicable transport encryption and access controls before production use. Review security prerequisites.
Protocol Compatibility
Familiar clients. A new foundation.
KubeMQ speaks messaging protocols directly inside the broker. Explore the capabilities and constraints that matter to your workloads.
KafkaNative wire protocol
Connect existing Kafka clients directly to KubeMQ. Support includes consumer groups, offset management, multi-partition topics, idempotent producers, and transactions for supported workloads. Log compaction and time-based retention are supported.
Requires the replicated storage engine, the replicated storage used by new installations. The older storage engine is retained for older installations. Check tested client versions and workload coverage, including Kafka Connect, Streams, and newer transaction protocols. Byte-based retention is not enforced. Share groups are preview; KIP-848 and Kerberos are unsupported. Replication factor is cluster-managed.
Check Kafka compatibility ↗RabbitMQAMQP 0-9-1
Use direct, fanout, topic and headers exchanges, queues, bindings, publisher confirms, dead-letter routing, prefetch and virtual hosts through supported AMQP 0-9-1 clients.
Transactions are not supported. Wire-protocol support does not imply compatibility with every management tool or extension. dead-letter routing handles rejected messages; expired messages are dropped without dead-letter routing. Queue-length and overflow settings are not enforced.
Check RabbitMQ compatibility ↗AMQP / JMSAMQP 1.0
Credit-based flow control, settlement, durable subscriptions, dynamic nodes, request/reply and JMS selectors. Supported clients include Qpid JMS, go-amqp and AMQP.Net Lite.
Transactions are not supported. Durable subscription identity and temporary nodes have node-local constraints. AMQP 1.0 and 0-9-1 share a port with automatic detection.
Check AMQP / JMS compatibility ↗MQTT3.1.1 / 5.0
QoS 0, 1 and 2, shared subscriptions, last-will messages, MQTT 5 user properties and request/response.
Retained messages are not supported; MQTT 5 advertises this capability limit. Sessions are in memory and node-local, so plan reconnection and routing accordingly.
Check MQTT compatibility ↗STOMP1.0 / 1.1 / 1.2
All three acknowledgment modes, receipts, heartbeats and request/reply. Destinations map to KubeMQ messaging patterns.
Transactions and selectors are not supported.
Check STOMP compatibility ↗AWS SQS / SNSExisting AWS SDKs
Use supported SQS queue operations, long polling, visibility timeouts and FIFO behavior, alongside SNS topics, subscriptions and filter policies. Signature-V4 authentication is supported.
Receipt handles are node-local: related operations must reach the serving node. SNS topic deduplication and SQS queue deduplication have distinct semantics. This is supported API compatibility, not complete AWS managed-service equivalence.
Check AWS SQS / SNS compatibility ↗Google Pub/SubCompatible gRPC surface
Connect supported official client libraries through the emulator-compatible interface. Publish, pull, stream, filter and replay, with snapshots and Avro/Protobuf schema validation.
Ordered subscriptions require sticky node routing because ordering state is node-local. this emulator-compatible listener has no built-in authentication or transport encryption. Place it behind an external authenticated, encrypted access boundary.
Check Google Pub/Sub compatibility ↗CloudEvents1.0
Publish structured or binary CloudEvents over HTTP, route by content with CESQL, and consume structured JSON through server-sent events.
Resume applies to persistent Events Store replay, not transient events or request/reply. The native CloudEvents endpoint is enabled by default.
Check CloudEvents compatibility ↗Other protocol connectors are enabled individually. Protocols retain their own semantics; external connector containers remain available for integrations such as databases and caches.
Messaging Patterns
More ways to message.
One platform.
Distribute work, broadcast events, replay history or coordinate services. Native gRPC, REST and WebSocket APIs give you access to all four patterns.
Durable Queues
Distribute jobs between workers, with controls for delivery, retries and failed messages.
Delivery & workflow controls
Schedule delivery, set expiration and retry limits, route failed messages to a dead-letter queue, and manage visibility. Peek and batch operations support job processing. Delivery is at-least-once, subject to policy and storage-engine limits.
Pub/Sub Events
Broadcast real-time events to active subscribers, from live updates to service notifications.
Live delivery
Events are transient and are not stored for later replay. Use Events Store when subscribers need persisted history.
Events Store
Persist events and replay from a chosen point to rebuild state or reprocess history.
Replay & retention
Read from the beginning, latest message, a sequence, timestamp, relative time, or new messages only. On the next engine, legacy age, size and count limits do not bound native persistent-channel backlogs; plan storage accordingly.
Commands & Queries
Request an action or retrieve data with a response, connecting services through KubeMQ.
Responses & query caching
Set bounded response waiting and distribute requests across responders. Queries can use cached responses; commands do not use the query cache. Requests are transient, not a persistent job queue.
Route once. Reach multiple destinations.
Route messages between channels and fan out to multiple destinations. Cross-protocol routes require compatible message semantics.
Kubernetes Operations
Simple to operate.
Deploy with Helm, manage through a visual console, and automate everyday tasks with the KubeMQ CLI. Familiar Kubernetes workflows keep operations straightforward.
Easy to deploy
Use Helm charts and a KubemqCluster resource to configure your deployment.
DeployEasy to manage
Inspect cluster health and manage configuration through the visual console.
ManageEasy to automate
Bring the CLI into your existing Kubernetes workflows and everyday operations.
AutomateControlled rollouts & node recovery
Readiness and liveness probes, pod-aware identity and graceful shutdown support controlled rollouts; behavior depends on the engine. A replacement node joins as a learner, catches up and requires explicit promotion before full membership.
Scale workers with demand
Use KEDA to scale consumer workloads based on KubeMQ queue depth. This scales the workers processing messages, not the broker nodes themselves.
Reliability & Security
Protect your messages.
Control your platform.
Choose how persistent writes are acknowledged, and configure access for your environment.
Next storage engine: Strict & Fast acknowledgment modes
Strict
Persist before acknowledgmentSynchronizes the replication log before acknowledging persistent writes. In a cluster, acknowledgment also requires a quorum.
Receive→Sync log + quorum*→Acknowledge
*Cluster deployments. A single node provides local disk sync, not independent replica protection.Fast
Default modeAcknowledges before background disk synchronization. A crash or power loss can lose recently acknowledged writes.
Replicate→Acknowledge→Background sync
Lower-latency acknowledgment with a different durability trade-off.Storage engines, retention & durability scope
Strict applies to persistent message writes, not transient events, request/reply or connector sessions, and is not a guarantee against every failure. The older storage engine remains supported; Kafka requires the next engine. Other connectors and native patterns work on both.
On the next engine, native persistent-channel backlogs are not bounded by legacy age, size or count settings. Kafka supports time-based retention; byte-based retention is not enforced. Startup detects existing storage and refuses mismatched data. Engine changes require a planned migration; this does not guarantee every upgrade is in-place.
Enterprise security
Define access.
Trace activity.
Configure authentication and access controls for both messaging and management to match your organization’s security requirements. Each is enabled separately.
- Management roles, service accounts and API keys
- TLS/mTLS and JWT/OIDC support on applicable interfaces
- Audit search through the console, API and CLI
Security configuration & build scope
Messaging authentication, messaging authorization and management RBAC are independently off by default. Enable transport encryption on supported listeners and configure replication encryption separately. Google Pub/Sub requires an external encrypted transport boundary.
Dedicated FIPS builds are available; this is not a claim of product-wide certification. Verify scan results and signature/checksum availability for the specific release artifact. A private deployment alone does not establish compliance.
Management & Observability
See clearly.
Act with control.
One set of tools for understanding activity, managing changes and automating operations.
Your KubeMQ operations
Cluster healthConfigurationMetrics & tracesAudit events
ConsoleAPIkmq CLI
Management console
Inspect cluster health, use per-protocol views and manage settings in a console available in six languages.
Configuration changes
Edit and revert server configuration with role gating and restart handling where required. Saving or reverting settings can restart the server.
Metrics & tracing
Use Prometheus monitoring and opt-in OpenTelemetry tracing and metrics over OTLP.
Counters & live measurements
Durable counters survive restarts. Live gauges represent current state and should not be interpreted as persisted history. Connector metrics reflect each protocol’s operating model.
Auditable operations
Search audit events through the console, API or CLI. Audit logging is enabled by default.
Built for developers. Ready for coding agents.
Configure, run and test KubeMQ through the CLI, with machine-readable output, bounded streams, schema discovery and embedded agent instructions.
AI Agents / Aiway
One fabric for agents, LLMs and messaging.
KubeMQ Aiway connects AI agents through an enterprise messaging foundation. Register capabilities and discover the right agent. Stream agent responses through A2A and invoke tools through MCP.
HTTP agents⇄Agent Bridge⇄KubeMQ Aiway⇄Applications & LLMs
A2A / MCP
A2A / MCP
Keep your agents simple
Agents remain HTTP services using JSON-RPC 2.0, with optional server-sent events. The Agent Bridge handles broker communication, so agents need no KubeMQ SDK or special runtime.
Two ways into one fabric
A2A supports agent registration, discovery and invocation. MCP gives LLM hosts access to agent orchestration and messaging through one endpoint.
Operate with control
Agent registry data is replicated, but agent-serving subscribers are node-local in the current product line. Plan agent re-registration after the registering node is lost. Request limits support controlled operation. Configure authentication to establish identities and apply meaningful ownership controls.
See every interaction
Per-agent request, error, latency and active-stream metrics, together with a live dashboard, help teams monitor their agents.
Build with KubeMQ
Build with the tools
you already use.
Native SDKs across 10 languages, plus integrations with familiar application frameworks.
Explore the SDKs ↗
Go
Java
C#
Python
TypeScript
C++
Kotlin
Ruby
Rust
Elixir
Connect your framework
Check the documentation for package versions and adapter compatibility.
Explore integrations ↗Try KubeMQ in one command
No signup. One standalone container. A 14-day evaluation on an empty data volume.
docker run -d --name kubemq -p 50000:50000 -p 9090:9090 -p 8080:8080 -p 9092:9092 -p 5672:5672 -v kubemq-data:/kubemq/store europe-docker.pkg.dev/kubemq/images/kubemq-next:latestOpen the dashboard and connect Kafka clients to localhost:9092. Keep the named volume when replacing the container.
Kubernetes and clusters require a license key. Starting a new evaluation on existing data also requires a key. Request a 30-day trial key. Both evaluation and trial servers need outbound HTTPS to license.kubemq.io; they refresh a 24-hour lease hourly.
By running, you accept the evaluation terms, including required usage reporting. Send your first Kafka message →
Bring your protocols.
Let’s check the fit.
Tell us what you run and where it needs to live. We’ll help assess compatibility, economics and the path to KubeMQ.