This guide takes you from an empty workspace to a working private MQTT connection.
1. Create a broker
Open Dashboard → New broker, choose a plan and billing cycle, then name the broker. RunMQTT confirms the subscription before provisioning paid capacity. Keep the setup page open until the broker becomes active.
The broker page shows the secure MQTT and WebSocket endpoints after provisioning completes.
2. Create a policy template
Create a template for one device role, such as factory-sensor. Add the narrowest topic filters that role needs:
factory/line-1/telemetry/+
factory/line-1/commands/+
Assign publish, subscribe, or bidirectional permission to each filter. Avoid # for production devices unless the identity genuinely needs access to the entire topic tree.
3. Create a device
Create a device from the template. RunMQTT generates the client connection details and a secret. Treat the secret like a password:
- copy it only into the intended client;
- do not commit it to source control;
- rotate or delete the device if the secret is exposed.
Use a unique client ID for every simultaneous connection. Reusing a client ID can cause the broker to replace the existing session.
4. Connect securely
Use either endpoint shown on the device page:
mqtts://…:8883for MQTT over TLS;wss://…/mqttfor MQTT over secure WebSocket.
Configure the username, password, and client ID exactly as displayed. Production clients should validate the server certificate, use a bounded reconnect backoff, and set a sensible keepalive.
5. Verify publish and subscribe
Subscribe to an allowed topic, then publish a short non-retained message to the same topic. Confirm that the subscriber receives the payload.
The browser console in RunMQTT is intentionally a lightweight MQTT 3.1.1 verification tool. It is useful for checking credentials and topic access; use your production SDK to test MQTT 5 properties, QoS 2 workflows, persistent sessions, and reconnect behavior.
Before production
- Replace broad test filters with least-privilege policies.
- Confirm retry and duplicate-handling behavior for your chosen QoS.
- Test Last Will behavior by simulating an ungraceful disconnect.
- Estimate billable message volume, including subscriber fan-out.
- Store device secrets outside logs and analytics payloads.