Why KubeMQ
Move your business forward.
Keep control of your messaging.
Predictable costs. Infrastructure you control. The protocols your applications already use. Choose a messaging platform built for the way your enterprise needs to run.
Battle-tested.
Built for the long run.
KubeMQ has been building enterprise messaging since 2020. That experience informs a platform designed for the operational demands of real organizations: reliability, visibility and control.
From established messaging patterns to native protocol support, the platform continues to evolve with enterprise workloads.
Trusted by S&P 500 companies and governments.
Enterprises across industries.
Electrical Equipment
Consulting & Technology
Enterprise IT
Advanced Materials
Energy & Utilities
Telecommunications
Fixed-Cost Messaging at Scale
Plan for growth. Know what it costs.
Your messaging budget should be something you can plan around.
KubeMQ’s fixed-cost licensing is tiered by package size, not message volume. Match a package to your requirements and evaluate the total cost of operating it on your infrastructure.
- Licensing based on package size
- Infrastructure choices that stay with your team
- A cost assessment based on your actual workload
Keep Control of Infrastructure
Keep your data where it belongs.
Run messaging where your business, security and operational requirements take you.
Deploy KubeMQ in your own Kubernetes environment. Your team controls the infrastructure, deployment lifecycle and access policies, with management and observability tools to support day-to-day operations.
For regulated or isolated environments, assess the deployment against your organization’s specific requirements.
Explore reliability and securityKeep Existing Apps & APIs
Keep familiar protocols. Open up your options.
Changing your messaging infrastructure can start with the clients your developers already know.
KubeMQ supports messaging protocols directly inside the broker, alongside its native APIs and SDKs. This gives teams a path to evaluate a common platform across different applications.
Compatibility is workload-specific. Review supported features, connector settings and protocol limitations before planning a move.
Check protocol compatibilityMigrate with Less Risk
Assess the fit. Validate the behavior. Move in stages.
Start with your current environment. Understand the fit, validate the behavior and plan the cutover around your operations.
Assess your workload
Review costs, deployment requirements and protocol features. For Kafka, the kmq CLI provides a read-only migration-fitness report.
Validate the fit
Test representative applications and confirm the reliability, performance and operating model your team needs.
Plan the cutover
Define migration stages and success criteria. Kafka migration tools support topic record copying, consumer-offset mapping, and controlled cutover.
Start with the platform you use today
From Kafka
Your path
Keep familiar Kafka producers and consumers for supported workloads. Start with a read-only assessment, then validate replication, offsets and cutover using the kmq migration tooling.
Validate before cutover
Use the replicated storage engine used by new installations. Validate transactions, retention, client versions and ecosystem dependencies; share groups remain a preview capability.
From RabbitMQ
Your path
Use standard AMQP 0-9-1 clients with the KubeMQ RabbitMQ connector. Recreate the required queues, exchanges and bindings, then validate publishing and consumption before switching endpoints.
Validate before cutover
Review TTL, dead-letter behavior, priority queues and other queue arguments. Supported wire protocol does not imply identical queue behavior.
From ActiveMQ / JMS
Your path
Identify the wire protocol behind your application. Evaluate the AMQP 1.0 connector with a compatible JMS client, such as Qpid JMS; plan client-provider changes where needed.
Validate before cutover
Validate destination mapping, selectors, settlement and request/reply. A JMS API alone does not establish wire compatibility, so do not assume every ActiveMQ client is an endpoint-only migration.
From MQTT
Your path
Connect a standard MQTT 3.1.1 or 5.0 client and map topics to the appropriate KubeMQ messaging patterns. Test representative devices and reconnect behavior before cutover.
Validate before cutover
Retained messages are not supported. Sessions are in-memory and node-local; applications that depend on durable subscriptions need a different design.
From AWS SQS / SNS
Your path
Evaluate supported SQS and SNS operations using existing AWS SDKs against a KubeMQ endpoint. Map queues, topics and subscriptions, then test producers and consumers together.
Validate before cutover
Review credentials, resource identifiers, visibility timeouts, FIFO and deduplication behavior, filters and AWS service integrations. Plan how existing queued work will be drained or transferred.
From Google Pub/Sub
Your path
Evaluate official client libraries against KubeMQ’s emulator-compatible gRPC interface. Recreate topics and subscriptions and test publishing, pull and streaming-pull workloads.
Validate before cutover
Validate authentication, ordering, acknowledgments, retry policies and integrations. Plan the handling of outstanding messages and retained history before redirecting traffic.
These are application migration paths. Moving existing messages, history and configuration is a separate part of the cutover plan.
KubeMQ vs Kafka
Compare with your own workload.
Measure throughput, latency, storage and operating cost with the same workload, durability settings and hardware. Historical container-size and speed figures do not establish performance for current releases.
Start with the Kafka compatibility reference and migration requirements, then test your clients and retention requirements.
Bring your workload. Compare the economics for your deployment.
Platform fit and further comparisons
KubeMQ vs Kafka
| Kafka | KubeMQ |
|---|---|
| An event-streaming platform with partitioned logs, Kafka Connect and Kafka Streams. Deploy it yourself or choose a managed provider. | Native Kafka protocol support alongside KubeMQ queues, events and request/reply on infrastructure you operate. |
What should guide the decision?
Evaluate the complete streaming ecosystem, retention requirements and client-feature fit. Compare infrastructure, operational work and commercial terms for your deployment.
KubeMQ vs RabbitMQ
| RabbitMQ | KubeMQ |
|---|---|
| A multi-protocol broker with AMQP, queues, streams and additional protocol support through plugins. | A native AMQP 0-9-1 connector alongside other KubeMQ protocols and a common management console. |
What should guide the decision?
Review queue semantics and extensions. KubeMQ documents differences in TTL, dead-lettering, priority and other queue arguments.
KubeMQ vs ActiveMQ
| ActiveMQ | KubeMQ |
|---|---|
| ActiveMQ Classic supports multiple protocols, including OpenWire, AMQP, MQTT and STOMP. | AMQP 1.0, MQTT and STOMP connectors offer paths for supported clients; assess the actual protocol and client provider in use. |
What should guide the decision?
Identify Classic or Artemis and the exact version. Check JMS provider dependencies, destinations, transactions and application-specific behavior.
KubeMQ vs AWS SQS / SNS
| AWS SQS / SNS | KubeMQ |
|---|---|
| AWS-managed queueing and publish/subscribe services integrated into the AWS environment. | Supported SQS/SNS APIs on a self-managed KubeMQ deployment, with control over infrastructure placement. |
What should guide the decision?
Balance managed-service operations and AWS integrations against infrastructure ownership. Compare licensing plus compute, storage, networking and operating effort.
KubeMQ vs Google Pub/Sub
| Google Pub/Sub | KubeMQ |
|---|---|
| Google Cloud’s managed messaging service for asynchronous application and data integration. | A compatible gRPC interface for supported Pub/Sub client-library operations on infrastructure you control. |
What should guide the decision?
Validate the emulator-compatible connection model, API behavior and Google Cloud dependencies. Include the cost and responsibility of operating your own deployment.
Compare your specific versions and workloads. These summaries are not feature-parity guarantees or price quotations.
Let’s see what KubeMQ
can change for you.
Bring your workload, your requirements and your questions. We’ll help you evaluate the fit.
Run 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.