Getting Started with RunMQTT: Validate Your First 100 Devices

A pilot should answer whether the system is ready to scale, not merely prove that one device can publish a message. Before the fleet grows beyond the first 100 devices, the team needs evidence about identity, authorization, delivery, recovery, and operations under realistic conditions.

Use this worksheet to turn a RunMQTT pilot into a pass-or-fail decision. Complete it with the people who own firmware, backend services, security, support, and the product outcome that depends on device data.

Define the pilot exit scorecard

Write the acceptance criteria before running the test. A useful scorecard measures outcomes rather than activity:

Do not accept “connected successfully” as a gate. Each criterion needs a threshold, evidence source, owner, and date.

1. Bound the pilot 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. Prove device isolation

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. Exercise the complete 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 testing-only free public MQTT broker is useful for basic client validation with synthetic data. Use an isolated managed broker for load tests or any message that resembles production data.

5. Make failures diagnosable

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. Scale by evidence-backed cohorts

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. Record the scale decision within 48 hours

After the pilot, compare every acceptance criterion with observed behavior. Capture unexpected reconnect patterns, noisy topics, authorization denials, payload growth, and gaps in the runbook. Classify each gate as passed, failed, or accepted with a named risk owner.

The output is a scale decision, not a retrospective slide deck: expand the cohort, extend the pilot to collect missing evidence, or stop and fix a failed boundary.

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.