RunMQTT Launch Checklist: From Pilot to Production

Moving an MQTT project from a working demo to a production fleet is mostly an exercise in removing ambiguity. Every device needs an owner, every topic needs a contract, every credential needs a lifecycle, and every failure mode needs a response.

Use this checklist as a go/no-go review for a new RunMQTT broker. It is intentionally operational: complete the items with the people who own firmware, backend services, security, support, and billing.

1. Define the first production workload

Start with a bounded fleet rather than the eventual vision.

• List the device models and firmware versions included in the first rollout.
• Estimate concurrent connections, average payload size, steady publish rate, and expected bursts.
• Identify commands or events that cannot be lost or duplicated.
• Write down the latency and availability targets that matter to the product.
• Name an owner for the broker, device registry, downstream consumers, and incident response.

Turn these assumptions into a test profile. If the numbers are guesses, capture real traffic from a pilot and replay it before choosing capacity.

2. Freeze the topic and payload contract

Write representative publish and subscribe examples before provisioning devices. A topic hierarchy should expose stable ownership and message direction:

prod/{tenant}/{site}/{deviceId}/telemetry
prod/{tenant}/{site}/{deviceId}/state
prod/{tenant}/{site}/{deviceId}/command

Document payload fields, units, timestamps, schema versions, maximum size, QoS, retained-message behavior, and expiry. Add negative authorization tests: one device must not publish as another device or subscribe outside its assigned prefix.

The MQTT topic design guide covers the contract in more detail.

3. Prepare secure device access

Treat device credentials as infrastructure, not form data copied into a spreadsheet.

1. Create a dedicated production broker rather than reusing a public or staging endpoint.
2. Issue a unique identity to each device or narrowly defined client.
3. Assign the minimum publish and subscribe filters required by that identity.
4. Use TLS with certificate verification for every production connection.
5. Store secrets in a hardware-backed store or protected application storage where the device supports it.
6. Test rotation and revocation before the first field deployment.

Shared credentials increase the blast radius of one compromised unit and make individual revocation impossible. The MQTT security guide explains the surrounding TLS, identity, and topic-authorization model.

4. Rehearse the message path

Validate the whole path, not just a successful broker connection:

• connect with the same client library and TLS settings used by production firmware;
• publish representative payloads at QoS 0 and QoS 1 where applicable;
• verify every downstream subscriber, transform, database, alert, and dashboard;
• disconnect devices abruptly and confirm Last Will behavior;
• test duplicate QoS 1 messages and consumer idempotency;
• reconnect after an outage and verify session, retry, and expiry behavior;
• attempt forbidden topics and confirm they are rejected.

The free public MQTT broker is useful for basic client validation. Use an isolated managed broker for load tests or any message that resembles production data.

5. Set operational guardrails

Create alerts before the system needs them. At minimum, monitor:

• current and peak connections;
• connection churn and authentication failures;
• publish rate, payload size, and processing latency;
• queued or expired messages;
• downstream consumer lag and error rate;
• broker health and billing state.

Each alert needs an owner, a threshold grounded in the workload profile, and a short runbook. Define rollback criteria for the launch window and confirm who can rotate credentials, disable a client, or pause a rollout.

6. Run a controlled production launch

Roll out in cohorts so a firmware or policy error stays contained.

1. Connect an internal canary fleet.
2. Observe a complete business cycle, not just a few minutes of traffic.
3. Expand to a small customer or site cohort.
4. Compare actual connections, throughput, latency, and failures with the forecast.
5. Pause automatically when an agreed threshold is breached.
6. Continue only after the previous cohort is stable.

Record the deployed firmware, policy template, broker plan, and topic schema for each cohort. That record makes rollback and later incident analysis far faster.

7. Review within 48 hours

After launch, compare assumptions with observed behavior. Capture unexpected reconnect patterns, noisy topics, authorization denials, payload growth, and gaps in the runbook. Convert the findings into owned work rather than leaving them in a meeting document.

If the pilot is ready for an isolated runtime, compare MQTT broker pricing and plans or create an account to provision the first managed broker.