# Release 3.5.4 (/release-notes/v3-5-4)



**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](/release-notes/v3-5-3).

## Artifacts [#artifacts]



| Artifact                 | Version                                                                                            |
| ------------------------ | -------------------------------------------------------------------------------------------------- |
| kmq                      | `v3.5.4`                                                                                           |
| Server image             | `europe-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 image           | `europe-docker.pkg.dev/kubemq/images/kubemq-operator-next:v3.4.0` (unchanged)                      |
| Helm chart `kubemq-next` | 3.4.0 (unchanged; it installs server `v3.5.0`)                                                     |

## Before you upgrade [#before-you-upgrade]

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

## Changes [#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 [#known-issues]

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