El hosting de un broker MQTT va desde un único servidor virtual que configuras tú mismo hasta un broker MQTT gestionado que se ejecuta dentro de tu propia cuenta en la nube. Esta comparativa recorre las cinco opciones habituales, muestra el trabajo real que implica cada una y termina con una checklist que te ayuda a elegir la adecuada para tu proyecto de hoy sin bloquear hacia dónde tenga que ir mañana.
Las cinco opciones habituales de hosting de broker MQTT
- Autoalojado en un VPS o en un servidor on-premises, normalmente con Mosquitto.
- Autoalojado en Kubernetes, con un broker de código abierto en contenedores.
- Serverless gestionado, un broker multi-tenant compartido que consumes como servicio.
- Dedicado gestionado, un clúster de broker aislado operado por un proveedor.
- BYOC (bring your own cloud), un broker operado por el proveedor que se ejecuta en tu propia cuenta en la nube.
Una sexta variante, software del proveedor que instalas y operas tú mismo bajo una licencia empresarial, se sitúa entre las opciones 1 y 5.
Comparativa lado a lado
| VPS con Mosquitto | Kubernetes | Serverless gestionado | Dedicado gestionado | BYOC | |
|---|---|---|---|---|---|
| Tiempo hasta la primera conexión | Rápido para un único servidor | Más largo; requiere montar el clúster | Minutos, autoservicio | Requiere definir el alcance con el proveedor | Requiere definir el alcance y preparar la cuenta en la nube |
| Quién parchea y actualiza | Tú | Tú | Proveedor | Proveedor | Proveedor |
| Quién gestiona los certificados TLS | Tú | Tú | Proveedor | Proveedor | Proveedor |
| Aislamiento respecto a otros clientes | Total | Total | Lógico, infraestructura compartida | Total | Total |
| Propiedad de la infraestructura | Tú | Tú | Proveedor | Proveedor | Tú |
| Esfuerzo de escalado | Redimensionado manual | Manual, teniendo en cuenta el clúster | Elegir un plan | Dimensionado con el proveedor | Dimensionado con el proveedor |
| Habilidades internas necesarias | Linux, redes, TLS | Kubernetes, redes, TLS | Clientes MQTT | Clientes MQTT | Administración de la cuenta en la nube |
| Mejor encaje | Laboratorios, sistemas pequeños de una sola sede | Equipos que ya usan Kubernetes | De prototipos a flotas medianas | Flotas en producción que necesitan aislamiento | Control estricto de los datos o infraestructura cloud existente |
Opción 1: VPS u on-premises con Mosquitto
Eclipse Mosquitto es ligero, está bien documentado y es fácil para empezar. Una configuración mínima pensada para producción, con TLS y autenticación por contraseña, tiene este aspecto:
# /etc/mosquitto/conf.d/production.conf
per_listener_settings true
listener 8883
certfile /etc/letsencrypt/live/mqtt.example.com/fullchain.pem
keyfile /etc/letsencrypt/live/mqtt.example.com/privkey.pem
allow_anonymous false
password_file /etc/mosquitto/passwd
listener 8084
protocol websockets
certfile /etc/letsencrypt/live/mqtt.example.com/fullchain.pem
keyfile /etc/letsencrypt/live/mqtt.example.com/privkey.pem
allow_anonymous false
password_file /etc/mosquitto/passwd
sudo apt install -y mosquitto mosquitto-clients
sudo mosquitto_passwd -c /etc/mosquitto/passwd device01
sudo systemctl restart mosquitto
Con eso arrancas. Lo que la gente subestima es el trabajo continuo: renovar certificados y recargar el broker, aplicar las actualizaciones de seguridad del sistema operativo y del broker, monitorizar disco y memoria, subir los límites de descriptores de archivo, hacer copias de seguridad del archivo de contraseñas, gestionar los intentos de inicio de sesión por fuerza bruta y planificar qué pasa cuando el único servidor falla.
Ventajas: control total, bajo coste directo, funciona sin conexión en una red local. Inconvenientes: tú eres el equipo de guardia; un único servidor es un punto único de fallo; la seguridad es enteramente responsabilidad tuya.
Opción 2: Kubernetes
Si tu organización ya usa Kubernetes, desplegar ahí un broker parece lo natural. Obtienes configuración declarativa, actualizaciones progresivas e integración con la monitorización existente.
El problema es que MQTT es un protocolo con estado y conexiones de larga duración, mientras que Kubernetes brilla con servicios petición-respuesta sin estado. Necesitas balanceo de carga TCP en lugar de un ingress HTTP, pod disruption budgets bien pensados para que las actualizaciones progresivas no desconecten a todos los clientes a la vez, volúmenes persistentes si quieres persistencia de sesión y entender cómo se comporta el broker elegido cuando los pods se reprograman. Nuestra guía de broker MQTT en Kubernetes cubre estos detalles.
Ventajas: encaja con las herramientas de plataforma existentes, infraestructura como código, control total. Inconvenientes: exige una experiencia operativa considerable; es fácil provocar tormentas de reconexión disruptivas durante las operaciones rutinarias.
Opción 3: Serverless gestionado
Un broker serverless es el camino más rápido hacia un endpoint seguro. Te registras, creas un broker y recibes un nombre de host, puertos y credenciales. El proveedor opera un clúster multi-tenant compartido y aplica cuotas por plan para mantener aislados a los clientes.
Los planes Serverless de ConnectMQ son un ejemplo:
- Serverless (Free): hasta 25 conexiones, QoS hasta 1, mensajes de 256 KB.
- Serverless (Paid): hasta 1.000 conexiones, QoS 2, mensajes de 1 MB, suscripciones compartidas.
Ambos admiten MQTT 3.1.1 y 5.0 sobre TCP 1883, TLS 8883, WebSocket 8083 y Secure WebSocket 8084 con la ruta /mqtt, con un certificado de Let's Encrypt ya instalado. La conexión es igual que con cualquier broker:
mosquitto_sub -h broker.connectmq.com -p 8883 --capath /etc/ssl/certs \
-u YOUR_USERNAME -P YOUR_PASSWORD -i YOUR_CLIENT_ID \
-t "acme/#" -v -V mqttv5
Ventajas: empiezas en minutos, sin servidores, seguridad por defecto resuelta, herramientas del portal incluidas. Inconvenientes: infraestructura compartida, límites de plan fijos, menos control sobre la ubicación y el ajuste.
Más información en broker MQTT serverless.
Opción 4: Dedicado gestionado
Un despliegue dedicado te da un clúster de broker aislado que no usa ningún otro cliente, operado igualmente por el proveedor. Encaja en sistemas de producción en los que quieres un rendimiento predecible no afectado por otros clientes y en los que la carga ha superado los límites de los planes compartidos. Describes las conexiones esperadas, las tasas de mensajes y los tamaños de payload, y el despliegue se dimensiona en consecuencia.
Ventajas: aislamiento, operación a cargo del proveedor, dimensionado para tu carga. Inconvenientes: coste mayor que los planes compartidos; la puesta en marcha tarda más que un registro de autoservicio.
Consulta broker MQTT dedicado para ver los detalles.
Opción 5: BYOC
Con bring your own cloud, el broker se ejecuta en tu propia cuenta en la nube, bajo tu facturación, tus controles de red y tus políticas de seguridad, mientras el proveedor lo despliega y lo opera. Encaja en organizaciones con requisitos estrictos de control de datos o con una gran infraestructura cloud existente donde ya viven los consumidores.
Ventajas: tu infraestructura y tu ruta de datos, operación a cargo del proveedor, ubicación junto a tus otros sistemas. Inconvenientes: pagas la factura de la nube y debes conceder y gobernar el acceso del proveedor; más coordinación en la puesta en marcha.
Nuestro artículo sobre broker MQTT BYOC explica el modelo y la preparación de la cuenta que requiere.
Lo que ninguna opción cambia
Sea cual sea el modelo de hosting que elijas, algunas cosas siguen siendo tuyas:
- El firmware de los dispositivos, la lógica de reconexión y el buffering local.
- El diseño del espacio de nombres de topics.
- Los formatos y la validación de payloads.
- El almacenamiento del histórico y la integración con otros sistemas, normalmente con un servicio suscriptor, Node-RED o Telegraf conectados como clientes MQTT.
- La elección de niveles de QoS por tipo de mensaje.
Como MQTT es un estándar, pasar de un modelo de hosting a otro consiste sobre todo en cambiar el nombre de host y las credenciales en los clientes, siempre que evites extensiones propietarias.
Cómo elegir: checklist de hosting
Responde estas preguntas en orden. La primera que se aplique claramente suele decidir el modelo de hosting.
- ¿Es un ejercicio de aprendizaje o una demo? Usa el servidor MQTT público gratuito, solo con datos de prueba, y olvídate del hosting.
- ¿El broker debe funcionar en una red local sin internet? Autoalójalo on-premises o considera una opción empresarial autogestionada.
- ¿Los datos deben permanecer dentro de cuentas en la nube que te pertenecen? Elige BYOC.
- ¿Necesitas aislamiento respecto a otros clientes o un dimensionado por encima de los planes compartidos? Elige un despliegue dedicado.
- ¿Ya operas Kubernetes y quieres el broker en la misma plataforma? Autoalójalo en Kubernetes, asumiendo la carga operativa.
- En cualquier otro caso: empieza con serverless gestionado y sube de nivel a medida que crezcan las conexiones y los requisitos.
Valora también el coste total, no solo el precio mensual. El tiempo de ingeniería dedicado a parches, renovación de certificados, respuesta a incidentes y actualizaciones es un coste real en las opciones autoalojadas. Coste total de propiedad de un broker MQTT y broker MQTT autoalojado vs. gestionado profundizan en esa comparación, y la guía de broker MQTT en la nube ofrece la visión completa.
Dónde encaja ConnectMQ
ConnectMQ cubre la parte gestionada de esta tabla: Serverless (Free y Paid) para arrancar rápido y para flotas en crecimiento, Dedicated para clústeres aislados, BYOC para brokers en tu propia cuenta en la nube y Self Managed Enterprise para organizaciones que necesitan operarlo ellas mismas. Todos hablan el mismo MQTT estándar, así que puedes empezar en pequeño y avanzar por el espectro sin rediseñar tus dispositivos.
Empieza a alojar tu broker MQTT en ConnectMQ
Crea un broker Serverless gratuito en app.connectmq.com, sin tarjeta de crédito, y conecta tu primer dispositivo en minutos. Cuando necesites aislamiento o control sobre dónde se ejecuta el broker, habla con el equipo sobre Dedicated o BYOC. Si prefieres antes una introducción más amplia, lee sobre cómo elegir un broker MQTT gestionado.
Preguntas frecuentes
¿Cuál es la forma más barata de alojar un broker MQTT?
Un plan gestionado gratuito o un pequeño servidor Mosquitto autoalojado son lo que menos gasto directo supone. El autoalojamiento añade tu propio tiempo para parches, certificados y monitorización, que a menudo supera el coste del servidor.
¿Puedo alojar Mosquitto en un VPS para producción?
Sí, con TLS, autenticación, monitorización y un plan para actualizaciones y fallos. Muchos equipos empiezan así y pasan a un broker MQTT gestionado cuando crece la carga operativa.
¿Es Kubernetes un buen lugar para ejecutar un broker MQTT?
Puede serlo si tu equipo ya opera bien Kubernetes. Las conexiones de larga duración de MQTT necesitan balanceo de carga TCP y actualizaciones progresivas cuidadosas para evitar reconexiones masivas.
¿Qué diferencia hay entre el hosting dedicado y BYOC?
Ambos te dan un broker aislado operado por el proveedor. Dedicated se ejecuta en la infraestructura del proveedor, mientras que BYOC se ejecuta en tu propia cuenta en la nube.
