Brokers MQTT públicos vs privados: cuándo dar el salto

Casi todos los proyectos MQTT empiezan en un broker público. Copias broker.hivemq.com o broker.emqx.io de un tutorial, te conectas sin credenciales y los mensajes fluyen en segundos. Esa rapidez es justo la razón de ser de los brokers públicos. Pero la misma apertura que los hace tan fáciles también los hace inadecuados para cualquier cosa más allá de los experimentos. Esta guía expone los pros y contras con honestidad para que sepas cuándo quedarte y cuándo dar el salto.

Qué es realmente un broker MQTT público

Un broker público es un servidor MQTT compartido que acepta conexiones anónimas de cualquiera en internet. Fabricantes y proyectos open source los mantienen como demos y sandboxes de interoperabilidad. Nuestra lista de brokers públicos recoge los más populares. Sus características definitorias:

• Sin registro y normalmente sin usuario ni contraseña.
• Un único espacio de nombres de topics compartido por todos los usuarios del mundo.
• Funcionamiento “best effort” para pruebas, no un servicio con soporte.

Los riesgos reales de los sandboxes públicos

1. Cualquiera puede leer y escribir en tus topics

Sin autenticación ni control de acceso, quien se suscriba a # recibe todos los mensajes del broker — incluidos los tuyos. Cualquiera puede también publicar en tus topics de comandos. Si un dispositivo escucha en home/garage/door/set, un desconocido puede abrirlo. Los nombres de topic rebuscados reducen las colisiones, pero no son seguridad: cualquiera suscrito a # los ve.

2. Basura retenida y estado obsoleto

Los mensajes retenidos persisten hasta que alguien los borra. En un broker público, los topics están llenos de payloads retenidos de otros usuarios y de pruebas antiguas, y cualquiera puede sobrescribir tu estado retenido. Un dashboard que confía en el valor retenido al suscribirse puede mostrar datos que nunca fueron tuyos. Consulta los mensajes retenidos de MQTT para ver cómo funciona la retención.

3. Colisiones de topics y de client ID

Los topics genéricos como test/temperature se comparten con todos los que siguieron el mismo tutorial. Los client ID genéricos son aún peores: cuando otra persona se conecta con tu ID, el broker te desconecta, y ambos clientes acaban en un bucle de reconexión. Más detalles en errores de conexión MQTT.

4. Sin SLA, sin soporte, sin previo aviso

Los brokers públicos pueden reiniciarse, actualizarse o limitarse en cualquier momento. Algunos ejecutan versiones de desarrollo a propósito. Eso está bien para un sandbox, pero significa que una demo puede fallar delante de un cliente por motivos que no puedes ver ni arreglar.

5. Límites de tasa y funciones que faltan

Los operadores protegen la infraestructura compartida con límites de conexiones, de mensajes por segundo y de tamaño de payload, que pueden no estar documentados. Tampoco puedes probar las funciones de las que depende producción: autenticación, permisos por topic, certificados de cliente, bridging o ajustes de persistencia.

Cuándo un broker público está perfectamente bien

• Aprender conceptos de MQTT como el QoS, los comodines y el Last Will.
• Comprobar que una nueva librería cliente o un firmware puede conectarse y publicar.
• Demos rápidas con datos ficticios y un prefijo de topic aleatorio.
• Reproducir un bug contra un broker neutral y conocido.

Si usas uno, mantén algunos hábitos:

# Random prefix + random client ID = fewer collisions
PREFIX="testmqtt/$(openssl rand -hex 4)"
mosquitto_sub -h broker.emqx.io -i "sub-$(openssl rand -hex 4)" -t "$PREFIX/#" -v

Prueba un broker público de forma segura

Señales de que es hora de cambiar

1. Tus mensajes contienen algo que no publicarías abiertamente.
2. Los dispositivos aceptan comandos por MQTT.
3. Alguien además de ti depende de ello — un compañero, un cliente piloto, una demo.
4. Necesitas probar autenticación, ACL o certificados de cliente TLS.
5. Te has topado con desconexiones inexplicables, throttling o mensajes extraños.

Tus opciones para un broker privado

Autoalojar es una opción sólida y te da control total; el coste es el trabajo continuo — renovación de certificados, parches del sistema operativo, copias de seguridad y alertas. Un broker gestionado cambia algo de control por no tener que hacer ese trabajo.

Un camino sensato: público para aprender, privado para todo lo demás

No tienes que elegir una vez y para siempre. Muchos equipos usan un sandbox público la primera tarde — confirmando que una librería funciona y que el diseño de topics tiene sentido — y pasan a un broker privado en cuanto entran en juego dispositivos reales o compañeros. A partir de ahí, desarrollo, staging y producción tienen cada uno su propio broker o sus propias credenciales, de modo que un script de prueba nunca pueda publicar por accidente en topics de producción.

Guarda los datos de conexión (URL, usuario, contraseña) en la configuración o en variables de entorno desde el primer día. Así cambiar de broker es un cambio de despliegue y no de código, y puedes apuntar la misma build a un broker público para una demo o a uno privado para un piloto.

Qué buscar en un broker privado o gestionado

• Aislamiento: tu propia instancia o espacio de nombres, no un árbol de topics compartido.
• Autenticación: como mínimo usuario/contraseña por cliente; idealmente credenciales por dispositivo.
• Autorización: control de acceso por topic para que un sensor solo pueda publicar en sus propios topics.
• Cifrado: TLS en el 8883 y WebSockets seguros para las aplicaciones web. Consulta los puertos MQTT.
• Soporte de protocolo: MQTT 3.1.1 y MQTT 5, para que convivan dispositivos antiguos y funciones nuevas.
• Endpoints estándar: host y puerto normales, para que migrar más adelante solo signifique cambiar la configuración.
• Visibilidad: una forma de ver los clientes conectados y por qué se rechazó una conexión.

Migrar es sobre todo configuración

Como MQTT es un protocolo estándar, pasar de un broker público a uno privado rara vez toca la lógica de la aplicación:

// Before: public sandbox
mqtt.connect('wss://broker.emqx.io:8084/mqtt');

// After: private broker with credentials over TLS
mqtt.connect(process.env.MQTT_URL, {
  username: process.env.MQTT_USERNAME,
  password: process.env.MQTT_PASSWORD,
  clientId: `sensor-${deviceSerial}`,
});

Aprovecha el cambio para ordenar también tu jerarquía de topics — una estructura coherente hace que las reglas de acceso sean mucho más fáciles de escribir. Topics y comodines MQTT cubre patrones de nombres que escalan, y puedes comprobar filtros con el probador de topics.

Preguntas frecuentes