Running an MQTT Broker on Kubernetes vs Using a Managed Service

Running an MQTT broker on Kubernetes is a natural idea if your team already deploys everything else there. This article compares that path with a managed service on effort, upgrades, reliability and cost drivers, and gives you a working manifest to try. You will come away knowing what Kubernetes solves for a broker, what it does not, and which option fits your team.

Why Teams Consider Kubernetes for MQTT

Kubernetes gives you declarative deployments, self-healing pods, rolling updates, secrets management and a consistent toolchain. If your backend services, databases and observability stack already run in a cluster, adding the broker there keeps everything in one place and lets subscribers reach it over the cluster network.

But an MQTT broker is not a typical stateless web service. Understanding what an MQTT broker does explains why: it holds long-lived TCP connections, keeps session state for offline clients, stores retained messages, and fans each message out to every matching subscriber. Those properties collide with several Kubernetes assumptions.

A Minimal MQTT Broker on Kubernetes

Here is a small but working Mosquitto deployment with password authentication. It is suitable for a lab cluster and a good way to feel the moving parts.

First create a password file and store it as a secret:

mosquitto_passwd -c -b passwd device01 'change-this-password'
kubectl create namespace mqtt
kubectl -n mqtt create secret generic mosquitto-passwd --from-file=passwd

Then apply the configuration, deployment and service:

apiVersion: v1
kind: ConfigMap
metadata:
  name: mosquitto-config
  namespace: mqtt
data:
  mosquitto.conf: |
    listener 1883
    allow_anonymous false
    password_file /mosquitto/secret/passwd
    persistence true
    persistence_location /mosquitto/data/
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: mosquitto
  namespace: mqtt
spec:
  serviceName: mosquitto
  replicas: 1
  selector:
    matchLabels:
      app: mosquitto
  template:
    metadata:
      labels:
        app: mosquitto
    spec:
      terminationGracePeriodSeconds: 30
      containers:
        - name: mosquitto
          image: eclipse-mosquitto:2
          ports:
            - containerPort: 1883
          volumeMounts:
            - name: config
              mountPath: /mosquitto/config
            - name: passwd
              mountPath: /mosquitto/secret
            - name: data
              mountPath: /mosquitto/data
          resources:
            requests:
              cpu: 100m
              memory: 64Mi
            limits:
              memory: 256Mi
      volumes:
        - name: config
          configMap:
            name: mosquitto-config
        - name: passwd
          secret:
            secretName: mosquitto-passwd
  volumeClaimTemplates:
    - metadata:
        name: data
      spec:
        accessModes: ["ReadWriteOnce"]
        resources:
          requests:
            storage: 1Gi
---
apiVersion: v1
kind: Service
metadata:
  name: mosquitto
  namespace: mqtt
spec:
  type: LoadBalancer
  selector:
    app: mosquitto
  ports:
    - name: mqtt
      port: 1883
      targetPort: 1883

Test it from outside the cluster once the load balancer has an address:

mosquitto_sub -h <LOAD_BALANCER_IP> -p 1883 -u device01 -P 'change-this-password' -i k8s-sub -t 'test/#' -v

That works, but notice what is missing: TLS, certificate renewal, monitoring, alerting, backups, and any form of high availability. Adding those is where the real effort lies.

What Kubernetes Does Not Solve for MQTT

Long-Lived Connections and Rolling Updates

A rolling update replaces pods one by one. For an HTTP service, that is invisible. For a broker, every pod restart disconnects all of its clients at once, and they reconnect simultaneously. Node drains, cluster upgrades and autoscaler consolidation trigger the same effect. You need devices with randomized exponential backoff, a PodDisruptionBudget, and maintenance windows for broker changes.

State and Storage

Persistent sessions and retained messages need storage that survives pod rescheduling. A StatefulSet with persistent volumes handles that for a single node, but volumes are usually tied to one availability zone, which limits where the pod can move during an outage.

Load Balancing Is Not Clustering

Scaling a single-node broker to three replicas behind a load balancer does not create a cluster. Each replica would be an independent broker, and a publisher on one would not reach a subscriber on another. True horizontal scaling needs a broker designed for clustering, typically deployed with its vendor's Helm chart or Kubernetes operator. The open source MQTT broker comparison shows which projects support that.

TLS at the Edge of the Cluster

You can terminate TLS at the cloud load balancer or at the broker. Terminating at the broker keeps encryption end to end but means mounting certificates and reloading them on renewal, typically with cert-manager. Terminating at the load balancer is simpler but needs care if you rely on client certificates.

Observability

You will need to export broker metrics into your monitoring stack, build dashboards, and define alerts on connection drops, message rates and resource usage. See MQTT broker monitoring for the metrics that matter.

Kubernetes vs Managed Service: Side by Side

Understanding the Cost Drivers

Comparing costs honestly means looking beyond the compute bill. For a Kubernetes-hosted broker, the cost includes:

1. Infrastructure: node capacity reserved for broker pods, persistent volumes, and load balancers with public IPs.
2. Data transfer: egress from your cloud provider for messages delivered to clients outside the cloud.
3. Engineering time to build: manifests or Helm values, TLS automation, authentication, dashboards and alerts.
4. Engineering time to run: upgrades, security patches, capacity reviews, incident response and on-call coverage.
5. Risk: the cost of an outage or security incident caused by a misconfiguration.

For a managed broker such as a Dedicated cluster, most of items 3 to 5 move into the subscription, and you pay for the plan instead of the underlying infrastructure. A useful exercise is to estimate the hours your team would spend per month on items 3 and 4, multiply by a loaded hourly rate, and add it to the infrastructure line. Then compare that total with the plan cost or quote for a managed option, such as ConnectMQ Dedicated. Our MQTT broker total cost of ownership guide walks through this calculation.

When Kubernetes Is the Right Choice

Running the broker yourself on Kubernetes makes sense when:

• You have a platform team that already operates stateful workloads well.
• You need broker plugins or customizations a managed service does not offer.
• The broker must run in an air-gapped or on-premises cluster.
• Your device count is stable and well understood.

A managed service is usually the better fit when your team is small, MQTT is critical but not your core product, or you need production readiness quickly.

The Middle Ground: Managed, but in Your Cloud

If what attracts you to Kubernetes is keeping the broker inside your own cloud environment, there is a third option. ConnectMQ BYOC runs the broker in your cloud account and ConnectMQ manages it, so the infrastructure stays yours while upgrades, certificates and monitoring of the broker are handled for you. A Dedicated plan offers an isolated cluster without any infrastructure work on your side. Both expose standard endpoints: TCP 1883, TLS 8883, WebSocket 8083 and Secure WebSocket 8084 at /mqtt, with Let's Encrypt certificates, for MQTT 3.1.1 and 5.0 clients.

Get Started with ConnectMQ

Before you write another Helm values file, try a managed MQTT broker for free. Create a Serverless broker at app.connectmq.com, no credit card required, and point the same clients you tested on Kubernetes at it. You can also experiment instantly on the public MQTT test broker, and read the cloud MQTT broker guide for a broader view of hosting models.

Frequently Asked Questions

Can I scale Mosquitto on Kubernetes by adding replicas?

No. Each replica would be an independent broker, so messages would not flow between them. Horizontal scaling requires a broker built for clustering.

Why do my MQTT clients disconnect during Kubernetes upgrades?

Pod restarts and node drains close every connection on that pod. Use PodDisruptionBudgets, maintenance windows and client-side reconnect backoff with jitter.

Should I terminate TLS at the load balancer or the broker?

Terminating at the broker keeps encryption end to end and preserves client-certificate authentication; terminating at the load balancer is simpler to manage. Choose based on your authentication model.

Is a managed broker more expensive than Kubernetes?

Compare total cost, including engineering time for setup, upgrades and on-call, not just compute. For many small teams, the managed option costs less overall.