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 compatibilityRabbitMQAMQP 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 compatibilityAMQP / 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 compatibilityMQTT3.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 compatibilitySTOMP1.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 compatibilityAWS 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 compatibilityGoogle 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 compatibilityCloudEvents1.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 compatibilityOther 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.
Use kmq to plan, install, verify, and maintain KubeMQ in Kubernetes. Helm charts and the visual console remain available when they fit your workflow.
Easy to deploy
Start with kmq to plan and install a deployment, then verify its health. Helm charts and a KubemqCluster resource remain available.
DeployEasy to manage
Inspect cluster health and manage configuration through the visual console.
ManageEasy to automate
Use kmq commands and machine-readable output in coding-agent 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.
Start with kmq to plan and install a deployment, verify it, and handle day-to-day operations. Its command schema and built-in agent instructions let coding agents work through the same reviewed steps.
Your KubeMQ operations
Cluster healthConfigurationMetrics & tracesAudit events
kmq CLIConsoleAPI
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.
kmq for the full workflow
Plan, install, connect, verify, inspect and maintain a deployment through kmq. Coding agents can discover its commands and use machine-readable output while you keep control of targets and credentials.
Set up with kmq →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 integrationsRun a 14-day Docker evaluation with kmq
Install kmq for macOS, Linux or Windows, start Docker, then run:
kmq onboard --goal evaluation --name kubemq --platform linux/amd64 --pullUse the returned installation identifier to authenticate and verify. Enter your password locally when prompted.
kmq auth setup --installation INSTALLATION_ID --username admin
kmq deploy verify --installation INSTALLATION_IDSee installation and verification steps →
Use Podman or ask a coding agent to help
For Podman, add the --runtime podman option. The server image is Linux x86-64; Apple Silicon needs x86-64 emulation in the container runtime. Coding agents can read the installed kmq command schema and skills before planning changes.
Help me deploy KubeMQ using kmq. Read https://docs.kubemq.io/deploy/cli and inspect `kmq version`, `kmq schema -o json` and `kmq skills get core`. Ask whether I want evaluation, trial or production and which runtime/context to use. Explain missing prerequisites. Inspect before changing resources. Use saved plans and explicit targets. Keep passwords, email codes and license keys out of chat, command arguments and logs; let me enter them through protected local input. Preserve existing data and installation identity. Verify license adoption, authenticated access and an exact message round trip before reporting success. If anything fails, show the actual state and a bounded recovery step.Run Docker manually
This single-line evaluation command works in macOS and Linux shells and Windows PowerShell. Replace Docker with Podman when using Podman.
docker run -d --platform linux/amd64 --name kubemq --hostname kubemq -p 127.0.0.1:8080:8080 -p 127.0.0.1:50000:50000 -p 127.0.0.1:9090:9090 -v kubemq-data:/kubemq/store europe-docker.pkg.dev/kubemq/images/kubemq-next:v3.5.0Open the local dashboard to create your administrator account. Verify the installation and send a message →
The evaluation starts on a fresh standalone data volume. Keep that volume if you later add a trial or paid license. Online evaluation needs outbound HTTPS to license.kubemq.io. By running it, you accept the evaluation terms, including required usage reporting.
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.