KubeMQ product facts

Deployment and responsibilities

KubeMQ is self-managed enterprise messaging for queues, event streaming and request/reply. Run it on infrastructure your organization controls, including on-premises and private or hybrid environments.

Your organization operates

Infrastructure, capacity, storage, networking, upgrades, monitoring and the security configuration appropriate to your environment.

Ways to operate

The kmq CLI supports deployment and operational workflows. Helm charts and the management console provide additional workflows; check the supported setup for your chosen release.

Sources: Operations overview · Deployment with kmq

Interfaces and messaging patterns

The product provides durable queues, live pub/sub events, persistent event replay, and commands and queries. Native APIs include gRPC, REST and WebSocket.

Protocol interfaces include Kafka, RabbitMQ / AMQP 0-9-1, AMQP 1.0, MQTT, STOMP, AWS SQS/SNS, Google Pub/Sub and CloudEvents. Each has its own supported capabilities and limitations. A protocol name does not imply support for every feature of the original platform.

Use the SDK and integration documentation to check available packages and compatible versions.

Sources: Protocol capabilities · Messaging patterns · Client SDKs · Framework integrations

Kafka compatibility has a defined scope

Supported Kafka clients connect through the Kafka wire protocol. The published product overview describes consumer groups, offset management, multi-partition topics, idempotent producers, transactions for supported workloads, log compaction and time-based retention.

Storage requirement

Kafka support requires the replicated storage engine. Replication factor is managed at cluster level.

Published limits

Byte-based retention is not enforced. KIP-848 and Kerberos are unsupported; share groups are preview. Check tested client versions and specific dependencies such as Kafka Connect and Streams.

Before migration

Assess the actual workload and run a representative producer/consumer test. Protocol compatibility does not replace all services, integrations or operational features of a managed Kafka platform.

The kmq migration CLI supports assessment, copying, validation and consumer-position mapping. The published migration guide blocks assessment of compacted topics and topics with more than 256 partitions. Validate the plan and target settings before cutover; a local evaluation is not a production migration.

Sources: Kafka compatibility reference · Kafka comparison · Migration overview · Migration instructions

Durability and security depend on settings

Fast acknowledgment

The product overview identifies Fast as the default mode: persistent writes are acknowledged before background disk synchronization. A crash or power loss can lose recently acknowledged writes.

Strict acknowledgment

Strict synchronizes the replication log before acknowledging persistent writes. Cluster acknowledgment also requires a quorum. A single node provides local disk sync, not independent replica protection.

Migration target

Use strict acknowledgment for a migration target and verify the effective configuration using the instructions for your released version.

Production access

Messaging authentication, authorization and management access controls require configuration and are independently off by default in the published product guidance. Configure applicable encryption and access controls before production use.

Storage mode, replica placement and failure conditions all matter. These settings are not a universal guarantee against data loss.

Sources: Acknowledgment modes and security · Migration prerequisites

Evaluation and trial are different paths

Local evaluation

The published website offers a 14-day Docker evaluation using kmq. A fresh standalone data volume starts the evaluation. Online evaluation requires outbound HTTPS to the licensing service and acceptance of evaluation terms, including required usage reporting.

Licensed trial

Use the trial journey to request a trial for the applicable deployment. The request, verification and issuance steps are separate; follow the current instructions and approved terms.

After evaluation

Keep the existing data volume when applying a trial or paid license. Verify a real message round trip and production prerequisites before using the deployment for live workloads.

Sources: Local evaluation · Trial options · Evaluation terms · License and deployment workflow

Licensing and cost boundaries

Licensing is quoted by package tier rather than message volume. Confirm the capacity, availability, retention, support and services included in your written proposal.

Infrastructure and operational costs are separate from the software license. A total-cost comparison should include those costs and transition work, including any parallel-running period.

The homepage cost chart is an illustrative annual scenario, not a public price quote or customer result. Use your own workload and a written proposal to assess savings.

Sources: Licensing scope · Cost methodology