Releases 1.0–1.3 (before renumbering)

v1.0.0 is the first release published as -next artifacts. These are the names every new installation uses. Newer releases are listed first; the v1.0.0 section records the behavior at that release. From 3.3.0 the same product is numbered above the legacy product; see How KubeMQ versions work. To install, see Choose your path.

v1.3.2

• Evaluation wording now describes a 14-day evaluation. The generic evaluation Docker command also exposes Kafka and RabbitMQ ports.

v1.3.1

• Standalone data survives container recreation across hostname changes. The persisted data and evaluation identity remain available when a standalone container is recreated with a different hostname.

v1.3.0: signup-free evaluation

Fresh standalone installations can start a 14-day evaluation without signup. Keep the named /kubemq/store volume across container recreation and continue with a trial key to preserve messages. Kubernetes and clustering still require a key.

v1.2.0

• Kubernetes pods must be created by the KubeMQ operator. The server refuses a hand-written StatefulSet, Deployment, or Pod. Upgrade the operator before the server, because the operator adds the marker that lets the server start.
• Kafka clusters recover consumer-group routing reliably. Cluster nodes now use their per-node replication addresses for internal forwarding, and a node whose internal mesh is unavailable reports itself not ready.
• Kafka client failures are clearer. Oversized produce requests return MESSAGE_TOO_LARGE, older clients can use ListOffsets version 0, and a login sent to a server without Kafka credentials receives an authentication error instead of a disconnected socket.
• The dashboard shows license status. The home page and Settings show the plan, instance usage, lease status, last check-in, and expiry. Licensing warnings appear as banners.

v1.1.0

• Kafka and RabbitMQ are on by default. A stock server listens on Kafka port 9092 and RabbitMQ / AMQP 0-9-1 port 5672. Their TLS ports open when server TLS is configured.
• Default-on connector failures do not stop the server. A conflicting port or unsupported storage engine disables the default connector for that run and logs the reason. A connector enabled explicitly still stops startup when it cannot run.

v1.0.0 historical notes

What shipped

• New artifact names. All images come from europe-docker.pkg.dev/kubemq/images and need no registry login:

  Artifact	Name
  Server image	kubemq-next
  Server image (FIPS)	kubemq-next-fips
  Operator image	kubemq-operator-next
  Helm chart	kubemq-next from https://kubemq-io.github.io/charts-next

• New Kubernetes API group: next.kubemq.io/v1, with the kinds KubemqCluster and KubemqConnector. In kubectl, use the full resource names kubemqclusters.next.kubemq.io and kubemqconnectors.next.kubemq.io.

• One Helm chart. kubemq-next installs the CRDs, the operator, and one cluster in a single release. Correction — September 27, 2026. Current charts install the operator and the cluster as two releases; see Install on Kubernetes.

• Versions restart at v1.0.0. The server, the operator, the chart, and the kmq CLI all carry v1.0.0. These numbers are not comparable with any earlier KubeMQ version number.

• Tags. Every image is published as an immutable release tag (:v1.0.0) plus the moving tag :latest. There is no other channel tag.

• The kmq CLI keeps its name. Its image stays europe-docker.pkg.dev/kubemq/images/kmq; its version becomes v1.0.0.

• Licensing at v1.0.0. Every server then needed a license to start. An online server used a license key (KUBEMQ_LICENSE_KEY), while air-gapped servers used a signed license file (KUBEMQ_LICENSE_FILE / KUBEMQ_LICENSE_DATA). Kubernetes gained licenseKey, licenseFile, licenseKeySecretRef, and licenseFileSecretRef. Current standalone evaluation behavior is documented above.

Known limitations at v1.0.0

• linux/amd64 only. Images are not yet built for other architectures.
• Dashboard license status arrived in next v1.2.0. The home page and Settings show licensing state; GET /api/v1/license and kmq license remain available for automation (Check license status).
• Connector images ship in next v1.1. The Targets, Sources, and Bridges images (kubemq-targets-next, kubemq-sources-next, kubemq-bridges-next) are not part of v1.0.0. Until then, set spec.image explicitly on every KubemqConnector. Connectors are installed by applying a next.kubemq.io/v1 manifest — there are no connector Helm charts. Correction — September 27, 2026. No default connector image is published. Set spec.image on every KubemqConnector.

Coming from legacy KubeMQ

Moving from the older kubemq image or chart: Move from legacy KubeMQ.