Elegir un broker MQTT para startups es un problema distinto de elegirlo para una gran empresa consolidada: necesitas algo gratuito o casi gratuito hoy, rápido de integrar y fácil de abandonar o escalar si el negocio despega. Esta guía ofrece a los equipos IoT en fase inicial un proceso de decisión práctico, un diseño de firmware que te mantiene portable y un plan por etapas que va de un broker Serverless gratuito de ConnectMQ a la capacidad dedicada.
Qué necesita de verdad una startup de un broker
Las restricciones de una startup, ya sea en Bogotá, Santiago o Barcelona, son el tiempo, el dinero y la incertidumbre. Todavía no sabes si el año que viene tendrás cincuenta dispositivos o cincuenta mil, qué protocolos aceptarán los equipos de TI de tus clientes ni qué funciones de tu producto sobrevivirán al contacto con el mercado. Eso lleva a una lista corta de requisitos:
- Cero operaciones. Cada hora dedicada a parchear la VM de un broker es una hora que no dedicas al producto. Un broker MQTT gestionado elimina ese trabajo.
- Gratis o muy barato a pequeña escala. Tu MVP no debería cargar con costes de infraestructura pensados para flotas en producción.
- Protocolo estándar, sin SDK propietario. MQTT 3.1.1 y 5.0 puros significan que cualquier biblioteca funciona en cualquier dispositivo y que más adelante puedes cambiar de proveedor.
- TLS y credenciales desde el primer día. Añadir seguridad a posteriori sale caro; empieza con conexiones cifradas.
- Un camino de crecimiento visible. Quieres saber qué pasa con 25, 1.000 y 10.000 conexiones antes de llegar ahí.
Comparativa de opciones
| Opción | Esfuerzo inicial | Coste en fase MVP | Riesgo de dependencia | Notas |
|---|---|---|---|---|
| Broker público de pruebas | Ninguno | Gratis | Ninguno | Genial para demos, nunca para datos de clientes |
| Mosquitto autoalojado en una VM | Medio | Bajo coste de VM más tu tiempo | Bajo | Te encargas de parches, TLS, monitorización y caídas |
| Plataforma IoT en la nube con SDK propietario | Medio | Variable | Alto | El código de los dispositivos queda atado a las API del proveedor |
| Broker MQTT serverless gestionado | Bajo | Nivel gratuito disponible | Bajo con MQTT estándar | Las cuotas marcan cuándo subir de plan |
Para la mayoría de los equipos en fase inicial, la respuesta correcta es un broker serverless gestionado para todo lo que sea real y un broker público para experimentos desechables. El servidor MQTT público gratuito en broker.connectmq.com es ideal para una primera prueba rápida: anónimo, con cualquier client ID único y no vacío, y topics bajo un prefijo único como connectmq/demo/k29xq/.... Como allí todo puede leerlo cualquiera, pasa a un broker privado en cuanto haya datos de un cliente piloto de por medio.
Plan por etapas
Etapa 1: prueba rápida (días)
Usa el broker público para demostrar el circuito de dispositivo a panel. Usa mosquitto_pub y mosquitto_sub para comprobar los topics:
mosquitto_sub -h broker.connectmq.com -p 1883 -i spike-sub-k29xq -t 'connectmq/demo/k29xq/#' -v
mosquitto_pub -h broker.connectmq.com -p 1883 -i spike-pub-k29xq \
-t 'connectmq/demo/k29xq/dev1/telemetry' -m '{"temp":22.4}'
Etapa 2: MVP y pilotos (de semanas a meses)
Crea un broker Serverless gratuito de ConnectMQ. Admite hasta 25 conexiones, QoS hasta 1 y mensajes de 256 KB, lo que cubre un puñado de unidades piloto, un worker de backend y un par de paneles. Obtienes TLS en el 8883, WebSocket en el 8083 y el 8084, un cliente en el navegador, un explorador de topics, un panel y reglas de alerta por umbral, que a menudo bastan para hacer una demo a inversores sin construir tu propia interfaz de administración.
Etapa 3: primeros ingresos (cientos de dispositivos)
Pasa a Serverless (Paid): hasta 1.000 conexiones, QoS 2, mensajes de 1 MB y suscripciones compartidas, para que varios workers de backend puedan repartirse un mismo flujo con $share/workers/devices/+/telemetry. Lee los niveles de QoS de MQTT explicados antes de activar QoS 2 en todas partes; la mayor parte de la telemetría funciona bien con QoS 1.
Etapa 4: escala y clientes empresariales
Cuando necesites aislamiento, margen predecible o respuestas para una revisión de seguridad, pasa a un broker MQTT dedicado. Si un cliente grande insiste en que el broker se ejecute en su cuenta en la nube, BYOC cubre ese caso mientras ConnectMQ sigue operándolo.
Diseña para la portabilidad desde el primer día
La dependencia del proveedor rara vez viene del broker en sí. Viene de los atajos en tu firmware y tu backend. Estos hábitos te mantienen libre para moverte.
Mantén los ajustes de conexión fuera del código
Nunca compiles el nombre de host y las credenciales en el firmware como constantes que no puedes cambiar. Aprovisiónalos en fábrica o mediante un flujo de alta seguro y guárdalos en almacenamiento no volátil. Este es un patrón mínimo para un ESP32 con la biblioteca Preferences:
#include <Preferences.h>
struct MqttConfig {
String host;
uint16_t port;
String user;
String pass;
String clientId;
};
MqttConfig loadMqttConfig() {
Preferences prefs;
prefs.begin("mqtt", true); // solo lectura
MqttConfig cfg;
cfg.host = prefs.getString("host", "broker.connectmq.com");
cfg.port = prefs.getUShort("port", 8883);
cfg.user = prefs.getString("user", "");
cfg.pass = prefs.getString("pass", "");
cfg.clientId = prefs.getString("cid", "");
prefs.end();
return cfg;
}
void saveMqttConfig(const MqttConfig& cfg) {
Preferences prefs;
prefs.begin("mqtt", false);
prefs.putString("host", cfg.host);
prefs.putUShort("port", cfg.port);
prefs.putString("user", cfg.user);
prefs.putString("pass", cfg.pass);
prefs.putString("cid", cfg.clientId);
prefs.end();
}
Con esto, pasar de un broker serverless a uno dedicado, o a otro proveedor por completo, es un cambio de configuración y no una nueva versión de firmware.
Usa MQTT puro, no el SDK de un proveedor
Quédate con bibliotecas abiertas y ampliamente usadas: PubSubClient o AsyncMqttClient en ESP32, paho-mqtt en Python, MQTT.js en Node.js y en navegadores. Funcionan con cualquier broker que cumpla el estándar.
Sé dueño de tu estructura de topics
Diseña los topics en torno a tu dominio, no a tu proveedor: acme/{customerId}/{siteId}/{deviceId}/telemetry. Nuestra guía sobre cómo elegir un broker MQTT para IoT cubre más criterios de evaluación, y una buena estructura de topics sobrevive a cualquier cambio de broker.
Mantén las integraciones fuera del broker
Escribe la telemetría en tu base de datos con tu propio servicio suscriptor, un flujo de Node-RED o Telegraf. Esa lógica se mueve contigo. ConnectMQ mantiene deliberadamente el broker como un broker; las integraciones se ejecutan como clientes MQTT normales, que resulta ser exactamente el patrón portable que quieres de todos modos.
Errores habituales de las startups
- Enviar unidades de demo apuntando a un broker público. Funciona hasta que un cliente se da cuenta de que sus datos los puede leer todo el mundo.
- Un único usuario compartido para todos los dispositivos. No puedes revocar una sola unidad comprometida. Usa credenciales distintas o, como mínimo, client IDs distintos por dispositivo.
- Client IDs duplicados. Dos dispositivos con el mismo ID se desconectan mutuamente en bucle.
- Sin backoff en la reconexión. Tras una caída, todos los dispositivos golpean el broker a la vez. Añade backoff exponencial con jitter.
- Tratar QoS 2 como "más fiable, así que siempre mejor". Añade viajes de ida y vuelta y estado; haz idempotentes a los consumidores y usa QoS 1.
- Payloads enormes. Envía imágenes o logs a un almacenamiento de objetos y publica una referencia.
- Sin topic de estado. Usa un mensaje Last Will y un topic de estado retenido para que tu panel sepa qué dispositivos están desconectados.
Una checklist de decisión sencilla
Antes de comprometerte, responde a estas preguntas con tu equipo:
- ¿Podemos crear un broker y conectar un dispositivo por TLS en menos de una hora?
- ¿El protocolo es MQTT 3.1.1 o 5.0 puro, sin SDK obligatorio?
- ¿Están documentados los límites del nivel gratuito y sabemos cuál alcanzaremos primero?
- ¿Hay un camino claro hacia más conexiones y después hacia capacidad aislada?
- ¿Podríamos pasar a otro broker cambiando solo la configuración?
- ¿El portal nos da suficiente visibilidad (explorador de topics, panel, alertas) para no tener que construir la nuestra el primer día?
Si las respuestas son sí, tienes un broker que encaja con una startup. Para una visión más amplia de los modelos de hosting, consulta nuestra guía de broker MQTT en la nube.
Lanza tu MVP en ConnectMQ
Crea un broker Serverless gratuito en app.connectmq.com sin necesidad de tarjeta de crédito. Tendrás credenciales en minutos, endpoints TLS y WebSocket y herramientas del portal para hacer demos de tu producto. Cuando la flota crezca, ConnectMQ ofrece los planes Serverless (Paid), Dedicated y BYOC sobre el mismo protocolo estándar, así que escalar es subir de plan, no reescribir.
Preguntas frecuentes
¿Cuál es el mejor broker MQTT para startups con un presupuesto ajustado?
Un broker gestionado con un nivel realmente gratuito y soporte de MQTT estándar, para no pagar nada durante el MVP y evitar el trabajo operativo. Un plan Serverless gratuito, por ejemplo, admite hasta 25 conexiones con TLS.
¿Debería una startup autoalojar Mosquitto?
Puede hacerlo, pero entonces se encarga de los parches, los certificados, la monitorización y las caídas. La mayoría de los equipos pequeños sacan más partido dedicando ese tiempo al producto.
¿Cómo evitamos la dependencia del proveedor con un broker MQTT?
Usa bibliotecas MQTT estándar, mantén configurables los ajustes de conexión, diseña tu propia estructura de topics y ejecuta las integraciones como suscriptores externos.
¿Cuándo debería una startup pasar a un broker dedicado?
Cuando te acerques a las cuotas de conexión, necesites un rendimiento predecible con carga constante o la revisión de seguridad de un cliente exija infraestructura aislada.
