La decisión entre un broker MQTT autoalojado o gestionado determina qué parte de tu semana se va en infraestructura en lugar de en el producto. Este artículo compara ambas opciones en esfuerzo operativo, costes ocultos y responsabilidad en seguridad, y después te da una matriz de decisión para que elijas con confianza el modelo adecuado para tu proyecto.
Si necesitas repasar qué hace un broker MQTT antes de comparar modelos de alojamiento, empieza por ahí.
Qué significan realmente "autoalojado" y "gestionado"
Un broker autoalojado es software que instalas y operas tú: Mosquitto, EMQX, VerneMQ, NanoMQ u otro broker open source o comercial ejecutándose en una VM, una Raspberry Pi, un clúster de Kubernetes o un servidor en tu planta. Tú eres responsable del sistema operativo, la configuración del broker, los certificados TLS, la base de datos de usuarios, las copias de seguridad y las guardias.
Un broker gestionado es un servicio. El proveedor ejecuta el broker, lo mantiene actualizado, renueva los certificados y expone los endpoints; tú recibes un nombre de host, puertos y credenciales. Sigues siendo responsable del diseño de topics, del código cliente y de tus datos, pero no de los servidores que hay debajo. Un broker MQTT gestionado como ConnectMQ te entrega un broker listo en pocos minutos.
Entre ambos existe un modelo híbrido: bring your own cloud (BYOC), en el que el broker se ejecuta en tu cuenta cloud pero lo opera el proveedor. Ese modelo se explica en la guía de broker MQTT BYOC.
El trabajo real de mantener tu propio broker
Instalar Mosquitto lleva un minuto. Operarlo bien exige un esfuerzo continuo. Una instalación autoalojada lista para producción suele necesitar:
# Minimal production mosquitto.conf - every line is something you now maintain
per_listener_settings true
listener 8883
certfile /etc/mosquitto/certs/fullchain.pem
keyfile /etc/mosquitto/certs/privkey.pem
allow_anonymous false
password_file /etc/mosquitto/passwd
acl_file /etc/mosquitto/acl
listener 8084
protocol websockets
certfile /etc/mosquitto/certs/fullchain.pem
keyfile /etc/mosquitto/certs/privkey.pem
allow_anonymous false
password_file /etc/mosquitto/passwd
persistence true
persistence_location /var/lib/mosquitto/
max_queued_messages 1000
message_size_limit 1048576
Ese archivo es solo el principio. A su alrededor necesitas:
- Ciclo de vida de los certificados: obtenerlos, renovarlos antes de que caduquen y recargar el broker sin desconectar a los clientes.
- Parches del sistema operativo y del broker: seguir los avisos de seguridad del kernel, de OpenSSL y del propio broker.
- Gestión de usuarios y credenciales: crear, rotar y revocar credenciales de dispositivos, idealmente sin editar archivos a mano.
- Monitorización: vigilar el número de conexiones, la tasa de mensajes, la memoria y el disco, y avisar a una persona cuando algo se desvía.
- Protección contra abusos: límites de tasa, límites de conexiones y bloqueo de intentos de inicio de sesión por fuerza bruta.
- Copias de seguridad y recuperación: archivos de persistencia, configuración y base de datos de contraseñas.
- Planificación de capacidad: saber cuándo un nodo ya no basta y qué hacer al respecto.
- Guardias: alguien que responda cuando el broker se cae a las 3 de la madrugada.
Ninguna de estas tareas es difícil por sí sola. Juntas se convierten en un trabajo a media jornada que rara vez aparece en la estimación inicial.
Broker MQTT autoalojado vs gestionado: comparación lado a lado
| Factor | Autoalojado | Gestionado |
|---|---|---|
| Tiempo hasta la primera conexión | De horas a días (servidor, TLS, autenticación) | Minutos (registrarse, crear el broker) |
| Coste de infraestructura | Servidor o VM, almacenamiento, ancho de banda | Cuota del plan o nivel gratuito |
| Coste de personal | Operación continua, parches, guardias | Asumido en gran parte por el proveedor |
| Certificados TLS | Los emites y renuevas tú | Incluidos y renovados |
| Endurecimiento de seguridad | Responsabilidad tuya de principio a fin | Compartido: el proveedor endurece, tú proteges las credenciales |
| Personalización | Control total del broker y los plugins | Limitada a lo que expone el servicio |
| Ubicación de red | En cualquier lugar, incluidas instalaciones aisladas (air-gapped) | Endpoint en Internet (o tu nube con BYOC) |
| Escalado | Lo diseñas y operas tú | Cambias de plan o nivel |
| Control de los datos | Totalmente en tu hardware | Depende del proveedor y del modelo de despliegue |
Ninguna columna gana en todo. La pregunta es cuáles de sus puntos débiles perjudican menos a tu proyecto.
Costes ocultos que la mayoría de los equipos pasa por alto
El coste visible del autoalojamiento es la factura de la VM. Los costes ocultos suelen ser mayores:
- Tiempo de ingeniería. Cada hora dedicada a renovar certificados, depurar un disco lleno o actualizar un broker es una hora que no dedicas al firmware de tus dispositivos ni a tu aplicación.
- Coste de los incidentes. Una caída del broker detiene todos los dispositivos a la vez. El coste es el tiempo de inactividad más la carrera por diagnosticar bajo presión un sistema que no conoces bien.
- Deuda de seguridad. Un listener de pruebas olvidado en el puerto 1883 con
allow_anonymous truees una vía habitual por la que los brokers acaban expuestos en Internet. - Concentración del conocimiento. A menudo solo una persona sabe cómo está configurado el broker. Cuando se va, el conocimiento se va con ella.
Para ponerles cifras de forma estructurada, consulta el artículo sobre el coste total de propiedad de un broker MQTT. Usa tus propios salarios y datos de incidentes; las cifras genéricas rara vez coinciden con la realidad.
Responsabilidades de seguridad: quién se ocupa de qué
La seguridad es compartida en ambos modelos, pero el reparto es distinto.
Con un broker autoalojado, todo depende de ti: reglas de firewall, configuración TLS, elección de cifrados, hash de contraseñas, archivos ACL, endurecimiento del sistema operativo, retención de logs y respuesta ante intrusiones.
Con un broker gestionado, el proveedor se ocupa de la capa de plataforma. En ConnectMQ, por ejemplo, la plataforma ofrece TLS en el puerto 8883 y Secure WebSocket en el 8084 con un certificado de Let's Encrypt, aislamiento multi-tenant, cuotas por plan, protección contra inundaciones, bloqueo de IP tras inicios de sesión fallidos repetidos y client IDs vinculados a las credenciales que emite. Tú sigues siendo responsable de:
- Mantener usuarios y contraseñas fuera de repositorios públicos y volcados de firmware.
- Usar TLS (8883 u 8084) desde los dispositivos en lugar del 1883 sin cifrar en producción.
- Diseñar los topics de forma que los datos sensibles no se publiquen donde no deben.
La guía de buenas prácticas de seguridad MQTT cubre en detalle la parte del cliente.
Cuándo conviene autoalojar
El autoalojamiento encaja bien cuando:
- La red está aislada. Una planta air-gapped, como una operación minera remota en Chile o Perú, o un buque sin conectividad fiable necesita un broker local.
- Necesitas funciones del broker que un servicio no expone, como un plugin de autenticación personalizado o una configuración de bridge específica.
- Ya cuentas con un equipo de plataforma maduro con monitorización, parches y guardias en marcha, de modo que un servicio más añade poco esfuerzo marginal.
- La normativa exige procesamiento on-premises y un despliegue operado por el proveedor en tu entorno no es una opción.
Incluso en estos casos, muchos equipos combinan un broker local en el edge con un broker en la nube para el acceso remoto, mediante un bridge MQTT o una aplicación de gateway.
Cuándo es mejor opción un broker gestionado
Un broker gestionado suele ganar cuando:
- Tu equipo es pequeño y nadie quiere estar de guardia por la infraestructura.
- Estás prototipando o lanzando y la rapidez para tener el primer dispositivo funcionando importa más que una personalización profunda.
- Los dispositivos están repartidos por Internet (hogares, vehículos, ubicaciones remotas) y necesitan un endpoint público estable con TLS.
- Tu carga crece por escalones. Pasar de un nivel gratuito a uno de pago o a un clúster dedicado es más sencillo que rediseñar un servidor.
ConnectMQ cubre estos escalones con un plan Serverless (Free) gratuito (hasta 25 conexiones, QoS hasta 1, mensajes de 256 KB), un plan Serverless (Paid) de pago (hasta 1.000 conexiones, QoS 2, mensajes de 1 MB, suscripciones compartidas), clústeres aislados Dedicated, BYOC y una opción Self Managed Enterprise.
Una matriz de decisión que puedes usar hoy
Puntúa cada fila de 0 a 2 para tu proyecto y suma cada columna.
| Pregunta | Puntos a favor de autoalojar | Puntos a favor de gestionado |
|---|---|---|
| ¿Debe funcionar el broker sin acceso a Internet? | 2 si la respuesta es sí | 0 |
| ¿Tienes ya un equipo de operaciones con guardias? | 2 si es sí | 2 si es no |
| ¿Necesitas plugins de broker personalizados? | 2 si es sí | 0 |
| ¿Es crítico el time to market? | 0 | 2 si es sí |
| ¿Están los dispositivos repartidos por la Internet pública? | 0 | 2 si es sí |
| ¿Mantendrán el sistema menos de dos personas? | 0 | 2 si es sí |
| ¿Importa más un gasto mensual predecible que el menor coste bruto de servidor? | 0 | 2 si es sí |
Si la columna de gestionado suma más, empieza con un broker gestionado y mantén tus clientes estándar para poder migrar más adelante si cambian las necesidades. El artículo sobre vendor lock-in en MQTT explica cómo mantener la portabilidad.
Prueba el modelo gestionado en cinco minutos
Puedes notar la diferencia de inmediato. Con los clientes de línea de comandos de Mosquitto instalados, suscríbete y publica en el servidor MQTT público gratuito, pensado solo para pruebas y prototipos, nunca para datos de producción:
# Terminal 1: subscribe (use your own unique prefix)
mosquitto_sub -h broker.connectmq.com -p 1883 -i sub-7f3a9 -t "connectmq/demo/7f3a9/#" -v
# Terminal 2: publish
mosquitto_pub -h broker.connectmq.com -p 1883 -i pub-7f3a9 -t "connectmq/demo/7f3a9/temp" -m "21.4"
Después haz lo mismo contra tu propio broker privado sobre TLS, con las credenciales generadas en el portal:
mosquitto_pub -h broker.connectmq.com -p 8883 --capath /etc/ssl/certs \
-u YOUR_USERNAME -P YOUR_PASSWORD -i YOUR_CLIENT_ID \
-V mqttv5 -t "plant1/line1/temp" -m "21.4"
Sin certificados que emitir ni archivos de configuración que editar. Compáralo con la lista anterior y tendrás el núcleo de la decisión.
Empieza con un broker MQTT gestionado
Si la matriz apunta a gestionado, prueba ConnectMQ con dispositivos reales antes de comprometerte. Crea un broker Serverless gratuito sin tarjeta de crédito, conecta un dispositivo por TLS y usa el cliente MQTT en el navegador y el explorador de topics en vivo para ver llegar tus mensajes. Para una visión más amplia de las opciones de alojamiento, lee la guía de brokers MQTT en la nube.
Preguntas frecuentes
¿Es más barato un broker MQTT autoalojado que uno gestionado?
El servidor en sí suele ser más barato, pero el coste total incluye parches, certificados, monitorización y tiempo de guardia. En equipos pequeños, el coste de personal suele superar el ahorro en servidores.
¿Puedo empezar con uno gestionado y pasar a autoalojado más adelante?
Sí, si tus clientes usan MQTT 3.1.1 o 5.0 estándar y evitas funciones propias del proveedor. Cambiar de broker consiste entonces en actualizar host, puerto y credenciales.
¿Pierdo el control de mis datos con un broker gestionado?
Mantienes el control de lo que publicas y de quién tiene credenciales. Si necesitas el broker dentro de tu propia cuenta cloud, un despliegue BYOC mantiene allí la infraestructura mientras el proveedor la opera.
¿Qué pasa con los brokers en redes aisladas (air-gapped)?
Una red aislada necesita un broker local. Un patrón habitual es un broker local en el edge para la planta más un broker gestionado en la nube para los dashboards remotos, conectados mediante un bridge o un gateway.
