# Supported deployments (/deploy/supported-deployments)



KubeMQ supports two deployment shapes.

* **Docker:** one non-clustered server for development and testing. Use the
  [Docker guide](/deploy/docker). The self-service trial covers this one-server shape.
* **Kubernetes:** an operator-managed cluster with at least three servers. Use the
  [Helm guide](/deploy/kubernetes-helm). Request a multi-server trial or license from
  KubeMQ before installing the cluster.

The server's single-binary architecture describes how KubeMQ is packaged. It does not make
native broker processes running directly on hosts, virtual machines, or bare metal; Podman
broker deployments outside Kubernetes; Docker clusters; or standalone Kubernetes installations supported.

Kubernetes uses the container runtime supplied by Kubernetes, such as containerd. The Podman
restriction applies to broker deployments outside Kubernetes.

## Kubernetes requirements [#kubernetes-requirements]

The KubeMQ operator must create and manage every server pod. A hand-written StatefulSet,
Deployment, or Pod is rejected by the server.

Each Kubernetes cluster must have at least three servers. The operator requires
`spec.replicas` to be at least `3`; when it is omitted or set to `0`, the operator defaults it
to `3`. The cluster must provide three distinct routes so servers can reach each other.
Setting `standalone: true` is rejected.

The self-service trial permits one server, so it cannot start a supported Kubernetes cluster.
Request a multi-server trial or license from KubeMQ for Kubernetes.

Use an odd server count such as 3, 5, or 7 for quorum. For local work, use Docker instead of
a one-server Kubernetes deployment.

## Moving an existing installation [#moving-an-existing-installation]

An unsupported installation must migrate to one of the supported shapes before upgrading.
For migration steps and data boundaries, see [Coming from legacy v2](/deploy/coming-from-legacy-v2).