Una alternativa a Mosquitto en la nube es lo que muchos equipos empiezan a buscar cuando su primer servidor Mosquitto autoalojado se convierte en algo de lo que dependen los clientes. Este artículo explica qué conservas, qué ganas y qué pierdes al pasar de Mosquitto autoalojado a un broker MQTT 3.1.1/5.0 gestionado, y muestra una configuración de bridge que te permite migrar instalación por instalación.
Por qué Mosquitto es tan popular
Eclipse Mosquitto se ha ganado su lugar. Es open source, ligero, está bien documentado y funciona en casi cualquier cosa, desde una Raspberry Pi hasta una VM grande. Admite MQTT 3.1.1 y 5.0, TLS, WebSockets, archivos de contraseñas, archivos ACL y bridging. Sus herramientas de línea de comandos, mosquitto_pub y mosquitto_sub, son la forma habitual en que muchos ingenieros prueban cualquier broker.
Para un laboratorio, una única vivienda o una red de planta que nunca toca Internet, Mosquitto suele ser todo lo que necesitas. La cuestión de buscar una alternativa solo surge cuando la parte operativa empieza a pesar más que la comodidad. Para una visión más amplia del panorama open source, consulta la comparativa de brokers MQTT open source.
Dónde se complica Mosquitto autoalojado
El broker rara vez es el problema. Lo es el trabajo que lo rodea:
- Exponerlo a Internet de forma segura. Necesitas una IP pública o un nombre DNS, reglas de firewall, certificados TLS y su renovación, y la seguridad de que no se ha quedado abierto ningún listener anónimo.
- Gestionar usuarios.
mosquitto_passwdy un archivo ACL de texto funcionan para diez dispositivos. Con cientos, necesitas scripts de aprovisionamiento y una forma de revocar credenciales con rapidez. - Monitorización. Debes recoger las estadísticas de
$SYSo los logs, almacenarlos y avisar a alguien cuando caen las conexiones. - Actualizaciones. Las actualizaciones de versión mayor pueden cambiar los valores por defecto. Mosquitto 2.0, por ejemplo, cambió los valores por defecto de los listeners y del acceso anónimo, lo que sorprendió a muchas instalaciones existentes.
- Diseño de un solo nodo. Mosquitto open source se ejecuta como un único proceso de broker. Si esa máquina falla, todos los clientes se desconectan hasta que vuelva.
Nada de esto es una crítica a Mosquitto. Es simplemente el coste de operar cualquier broker por tu cuenta, que se trata con más detalle en broker MQTT autoalojado vs gestionado.
Lo que conservas con un broker MQTT gestionado
Como un broker MQTT gestionado habla el mismo protocolo estándar, casi todo lo que has construido sigue sirviendo:
- Código cliente. Paho, MQTT.js, PubSubClient, Node-RED y las herramientas CLI de Mosquitto funcionan sin cambios, salvo el host, el puerto y las credenciales.
- Estructura de topics. Tu árbol de topics se traslada tal cual.
- Funciones de MQTT 5. En ConnectMQ están disponibles las suscripciones compartidas (planes de pago), retained messages, caducidad de sesión, topic aliases, caducidad de mensajes, response topics y reason codes.
- Tus hábitos con las herramientas. Puedes seguir usando
mosquitto_subpara depurar.
Lo que ganas
- Ningún servidor que mantener. TLS en el 8883 y Secure WebSocket en el 8084 con un certificado de Let's Encrypt están listos desde el primer día.
- Credenciales desde un portal en lugar de archivos de contraseñas. Cada broker recibe un usuario, una contraseña y un client ID generados.
- Visibilidad integrada. El portal de ConnectMQ incluye un cliente MQTT en el navegador, un explorador de topics en vivo, un dashboard y reglas de alerta por umbral, para que veas el tráfico sin instalar herramientas adicionales.
- Protecciones que de otro modo tendrías que construir tú, como cuotas por plan, protección contra inundaciones y bloqueo de IP tras inicios de sesión fallidos repetidos.
- Extras industriales si te interesan: detección de topics ISA-95 / Unified Namespace y decodificación de payloads Sparkplug B.
Lo que pierdes
Sé honesto con las contrapartidas antes de migrar:
| Capacidad de Mosquitto | Consideración con un broker MQTT gestionado |
|---|---|
| Plugins personalizados de autenticación o ACL | Usas en su lugar el modelo de autenticación del proveedor |
| Archivos ACL detallados por topic | Comprueba qué control de acceso ofrece el servicio; ConnectMQ aísla a los tenants y vincula los client IDs a las credenciales, pero no ofrece ACL por topic |
| Control total de cada opción de configuración | Solo se pueden ajustar los parámetros que expone el servicio |
| Funcionar totalmente sin conexión | Un broker en la nube necesita acceso a Internet; mantén un broker local para las instalaciones sin conexión |
| Tamaño de mensaje ilimitado a tu elección | Se aplican los límites del plan, por ejemplo 256 KB en Serverless gratuito y 1 MB en Serverless de pago |
Si las ACL por topic o los plugins personalizados son centrales en tu diseño, mantén Mosquitto en el edge y usa el broker en la nube para las partes que se benefician de él.
Preguntas que conviene plantear antes al equipo
Antes de comparar proveedores, poneos de acuerdo internamente en algunos puntos. ¿Qué dispositivos deben seguir funcionando cuando cae el enlace a Internet? ¿Quién se ocupa ahora del servidor Mosquitto y a qué preferiría dedicarse? ¿Qué topics transportan comandos que cambian equipos físicos y quién debería poder publicar en ellos? ¿Cuántas conexiones simultáneas esperas dentro de un año, no solo hoy? Las respuestas deciden si necesitas un broker puramente en la nube, uno híbrido con un broker local en el edge o un despliegue dedicado, y mantienen la evaluación centrada en tus requisitos y no en listas de funciones.
Cómo evaluar una alternativa a Mosquitto en la nube
Sea cual sea el proveedor que consideres, comprueba lo siguiente en su documentación actual:
- Versiones del protocolo. ¿Admite MQTT 3.1.1 y 5.0, incluidas las funciones de MQTT 5 que usas?
- Puertos y transportes. TLS en el 8883, WebSocket y Secure WebSocket para aplicaciones de navegador.
- Niveles de QoS y límites de tamaño de mensaje en el plan que realmente contratarías.
- Comportamiento de los retained messages y de la caducidad de sesión.
- Modelo de autenticación. Usuario y contraseña, certificados de cliente o ambos.
- Nivel gratuito. ¿Puedes probar con dispositivos reales antes de pagar?
- Modelos de despliegue. Compartido, dedicado, en tu propia nube o autogestionado.
- Vía de salida. ¿Puedes irte sin reescribir el firmware de los dispositivos? El artículo sobre vendor lock-in en MQTT explica qué vigilar.
Migrar de forma gradual con un bridge de Mosquitto
No tienes que cambiarlo todo de golpe. La función de bridge de Mosquitto puede reenviar topics seleccionados desde tu servidor actual a un broker gestionado. Añade esto a tu mosquitto.conf (Mosquitto 2.x):
# Bridge local Mosquitto to a ConnectMQ broker over TLS
connection connectmq-bridge
address broker.connectmq.com:8883
bridge_protocol_version mqttv50
bridge_capath /etc/ssl/certs
remote_clientid YOUR_CLIENT_ID
remote_username YOUR_USERNAME
remote_password YOUR_PASSWORD
cleansession false
restart_timeout 10 60
# Forward plant telemetry to the cloud, receive commands back
topic plant1/+/+/telemetry out 1
topic plant1/+/+/cmd in 1
Reinicia Mosquitto y comprueba en el log que el bridge se ha conectado correctamente:
sudo systemctl restart mosquitto
sudo journalctl -u mosquitto -n 50 --no-pager
Después verifica que los datos llegan a la nube suscribiéndote con las credenciales del broker:
mosquitto_sub -h broker.connectmq.com -p 8883 --capath /etc/ssl/certs \
-u YOUR_USERNAME -P YOUR_PASSWORD -i YOUR_CLIENT_ID-debug \
-t "plant1/#" -v
Ten en cuenta que el broker MQTT gestionado vincula los client IDs a las credenciales emitidas, así que para una segunda conexión simultánea como esta sesión de depuración usa un client ID que se te haya emitido para ello, o utiliza en su lugar el cliente del navegador del portal.
El patrón de bridge permite que los dashboards y los usuarios remotos pasen al broker en la nube mientras los dispositivos locales siguen hablando con la instancia de Mosquitto que ya conocen. Cuando tengas confianza, puedes apuntar los dispositivos directamente al broker MQTT gestionado. El proceso completo se describe en migrar Mosquitto a MQTT en la nube.
Solución de problemas del bridge
- El bridge se conecta y se cae una y otra vez. Otro cliente está usando el mismo client ID. Cada conexión necesita su propio ID.
- Errores en el handshake TLS. Confirma que
bridge_capathapunta al almacén de CA del sistema, o usabridge_cafilecon un bundle que incluya la cadena de Let's Encrypt. - Los mensajes no se reenvían. Revisa el patrón del topic y la dirección (
outenvía de local a remoto,inrecibe de remoto a local). - QoS 2 rechazado. Los planes Serverless gratuitos admiten QoS hasta 1, así que configura el bridge con QoS 1 o cambia de plan.
Prueba un broker MQTT gestionado junto a Mosquitto
Puedes probar la parte gestionada sin tocar producción. Crea un broker Serverless gratuito en ConnectMQ sin tarjeta de crédito, añade el bloque de bridge anterior a una instancia de Mosquitto de pruebas y observa cómo aparecen tus topics en el explorador de topics en vivo. Para entender las opciones con más detalle, lee la guía de brokers MQTT en la nube o descubre de qué te libera un broker MQTT gestionado. Si prefieres probar sin registro, el servidor MQTT público gratuito de broker.connectmq.com sirve para pruebas y prototipos, nunca para datos de producción. Tienes más información sobre la plataforma en connectmq.com.
Preguntas frecuentes
¿Existe una versión alojada de Mosquitto?
Algunos proveedores ofrecen Mosquitto alojado o con soporte comercial. Como alternativa, cualquier broker MQTT gestionado que cumpla el estándar funciona con clientes y bridges de Mosquitto, ya que el protocolo es el mismo.
¿Funcionarán mis clientes de Mosquitto con un broker MQTT gestionado?
Sí. Los clientes que hablan MQTT 3.1.1 o 5.0 solo necesitan un nuevo host, puerto, credenciales y client ID.
¿Puedo mantener Mosquitto en el edge y usar también la nube?
Sí. Un bridge reenvía topics seleccionados desde un Mosquitto local al broker en la nube, un patrón habitual en plantas e instalaciones con conectividad poco fiable.
¿Pierdo las ACL al dejar Mosquitto?
Depende del proveedor. ConnectMQ aísla a los tenants y vincula los client IDs a las credenciales, pero no ofrece ACL por topic, así que mantén Mosquitto en el edge si dependes de ellas.



