KubeMQ
Release notes

Release 3.5.4

KubeMQ 3.5.4 fixes kmq's Kafka loopback advertising and Kubernetes status reads, isolates subcommand flags, and closes Kubernetes migration real-run gaps.

Released September 27, 2026. kmq advertises the Kafka address a deployed container actually publishes, reads a Kubernetes cluster's license status the way the operator writes it, and no longer lets its subcommands inherit the server's startup flags. The Kubernetes migration path also closes a broad round of failures found running it for real. The operator and the Helm chart are unchanged from 3.5.3.

Artifacts

ArtifactVersion
kmqv3.5.4
Server imageeurope-docker.pkg.dev/kubemq/images/kubemq-next:v3.5.4, for linux/amd64 and linux/arm64
Server image (FIPS)europe-docker.pkg.dev/kubemq/images/kubemq-next-fips:v3.5.4, for linux/amd64 and linux/arm64
Operator imageeurope-docker.pkg.dev/kubemq/images/kubemq-operator-next:v3.4.0 (unchanged)
Helm chart kubemq-next3.4.0 (unchanged; it installs server v3.5.0)

Before you upgrade

  • Nothing new to prepare. The operator and the Helm chart are the same as in 3.5.3.

Changes

  • kmq advertises the Kafka loopback address a deployed container actually publishes. A container started by kmq deploy publishes the Kafka port on 127.0.0.1 only, while kmq previously advertised localhost; kcat and other librdkafka clients resolve that to IPv6 first and were refused. kmq now sets the advertised host and port to match, so a client can connect right after deploy.
  • kmq reads a Kubernetes cluster's status and operator Deployment the way the operator actually writes them. A field-name mismatch meant a fully licensed, converged cluster could still report itself cluster_not_ready, and an operator installed outside kmq's own release was invisible to it and risked a second install attempt.
  • kmq subcommands no longer inherit the server's startup flags. --config, --clean, --clean-accounts and --reset-admin-password used to appear in every subcommand's --help and be silently accepted, doing nothing; the server's own --help is unchanged.
  • kmq's Kubernetes migration path closes a broad round of real-run failures. kmq migrate now runs a Kafka-to-KubeMQ migration end to end from inside the cluster, provisioning the target and worker profiles and running the probe, plan, prepare and cutover stages as in-cluster Jobs. Fixes found running the trial and migration journeys for real include Podman-backed Docker identity, Helm 4 support, reviewed failure categories instead of one opaque error, retried transient Kubernetes errors, and consistent messages wherever a credential, license, lock or saved plan sits in a directory kmq will not trust.

Known issues

  • No default connector image is published. Set spec.image on every KubemqConnector.

Was this page helpful?

On this page