Cómo autoalojar Uptime Kuma en un VPS

Puedes autoalojar Uptime Kuma en un VPS de VoyraCloud seleccionando la imagen de aplicación preinstalada, creando el primer administrador a través de un túnel SSH privado y luego agregando monitores para los servicios que operas. La imagen proporciona un punto de partida persistente para Uptime Kuma, mientras que el acceso público, HTTPS confiable, notificaciones, copias de seguridad, actualizaciones, planificación de capacidad y respuesta a incidentes permanecen bajo tu control.

TL;DR

La imagen de aplicación Uptime Kuma de VoyraCloud proporciona un panel de monitoreo preinstalado en Cloud VPS y Residential IP VPS.
El puerto 3001 está vinculado a 127.0.0.1 por defecto, así que crea el primer administrador a través de un túnel SSH en lugar de exponer una página de configuración no inicializada a Internet.
Uptime Kuma soporta monitores de HTTP, HTTPS, TCP, ping, DNS, WebSocket, push, palabra clave y consulta JSON, entre otros tipos de monitores documentados por el proyecto.
El acceso al panel público o a la página de estado requiere tu propio dominio, un proxy inverso que soporte actualizaciones de WebSocket y HTTPS confiable en el navegador.
La configuración, usuarios, historial de monitoreo, notificaciones y páginas de estado se almacenan bajo /app/data en almacenamiento local persistente. La persistencia de reinicio no es una copia de seguridad.
Una carga de trabajo de 20 monitores, con intervalos de 60 segundos, es el perfil de validación inicial de la imagen, no una garantía de monitores ilimitados ni un sustituto para medir tu propia carga de trabajo.
Monitorear desde el mismo VPS tiene un importante punto ciego: si ese VPS, su región o su ruta de red falla, Uptime Kuma puede no ser capaz de enviar la alerta.

¿Qué es Uptime Kuma?

Uptime Kuma es una aplicación de monitoreo de código abierto y autoalojada para verificar sitios web, APIs, servicios de red y otros puntos finales accesibles desde un panel que controlas. Registra los resultados de las verificaciones y la información de respuesta, presenta el historial de servicios y puede enviar notificaciones a través de integraciones configuradas por el administrador.

El proyecto oficial de Uptime Kuma enumera el soporte para tipos de monitores como HTTP(S), TCP, palabra clave HTTP(S), consulta JSON HTTP(S), WebSocket, ping, registro DNS, push y monitoreo de contenedores Docker. También proporciona múltiples páginas de estado, información de certificados, gráficos de ping, autenticación de dos factores, soporte para proxies y una amplia gama de integraciones de notificación.

El autoalojamiento es útil cuando deseas:

Un panel de monitoreo bajo tu propia administración de servidor.
Control sobre la configuración de monitores, usuarios, historial y páginas de estado.
Una forma sencilla de verificar varios sitios web, APIs o servicios de red.
La opción de conectar proveedores de notificaciones que ya utilizas.
Una herramienta de monitoreo que pueda ejecutarse continuamente en un pequeño VPS.

Uptime Kuma no es un servicio de monitoreo gestionado cuando se despliega de esta manera. Tú eres el propietario del VPS, de los controles de acceso, actualizaciones, copias de seguridad, credenciales de notificación y del proceso de respuesta. También debes decidir si una ubicación de monitoreo proporciona suficiente visibilidad para los servicios que son importantes para ti.

¿Cómo comienzas con la imagen de aplicación de VoyraCloud?

La forma más rápida de autoalojar Uptime Kuma es crear un VPS de VoyraCloud soportado con la imagen de aplicación y completar la primera configuración a través de un túnel SSH local. No necesitas instalar Uptime Kuma manualmente, pero debes crear de forma segura al administrador antes de configurar los monitores.

Abre la página de VoyraCloud para Uptime Kuma y continúa con el flujo de compra del VPS.
Selecciona un plan de Cloud VPS o Residential IP VPS elegible, luego elige cualquier región actualmente ofrecida por ese producto.
Confirma que Uptime Kuma está seleccionado en la sección de Imágenes, luego crea el VPS.
Espera hasta que el recurso y la aplicación estén listos.
Abre los detalles del recurso y localiza la sección de Aplicación.
Copia el comando del túnel SSH mostrado. Sigue este patrón:

ssh -p <ssh-port> -L 3001:127.0.0.1:3001 <ssh-user>@<server-ip>

7. Mantén esa sesión SSH abierta y navega a:

http://127.0.0.1:3001

8. Completa la página de configuración oficial de Uptime Kuma y crea un nombre de usuario de administrador único y una contraseña fuerte.

9. Inicia sesión, crea un monitor de prueba y confirma que las verificaciones aparecen en el panel.

10. Reinicia el VPS una vez y verifica que Uptime Kuma regrese automáticamente y que la cuenta, el monitor y el historial permanezcan disponibles.

La dirección del navegador es local, pero la aplicación se ejecuta en el VPS. SSH reenvía tu puerto local 3001 a través de una conexión encriptada a 127.0.0.1:3001 en el servidor. Cerrar la sesión SSH cierra el túnel; no detiene Uptime Kuma.

Si tu computadora ya utiliza el puerto local 3001, elige otro puerto local sin cambiar el destino remoto:

ssh -p <ssh-port> -L 33001:127.0.0.1:3001 <ssh-user>@<server-ip>

Entonces abrirías http://127.0.0.1:33001 en tu navegador. Mantén el lado remoto como 127.0.0.1:3001.

Usa el nombre de usuario SSH y el puerto mostrados para tu propio recurso en lugar de asumir root y el puerto 22.

¿Qué incluye la imagen de aplicación?

La imagen de aplicación incluye una instancia de Uptime Kuma preinstalada y persistente, pero no convierte el VPS en un servicio de monitoreo gestionado. La siguiente frontera es importante al planificar el uso en producción.

Entregado por la imagen de aplicación	Gestionado por el usuario o no incluido
Liberación estable de Uptime Kuma aprobada para la imagen	Actualizaciones automáticas de la aplicación
Entorno operativo de Cloud VPS o Residential IP VPS	Administración de servidor gestionada
Recuperación de servicio después de un reinicio normal del VPS	Alta disponibilidad o conmutación por error automática
Acceso solo local en `127.0.0.1:3001`	Exposición del puerto público `3001`
Flujo de configuración del primer administrador oficial	Administrador precreado o contraseña fija
Almacenamiento local persistente `/app/data`	Copias de seguridad automáticas fuera del servidor
Funciones de panel de monitoreo, historial, notificaciones y páginas de estado	Cuentas de notificación de terceros preconfiguradas
Instrucciones del túnel SSH en los detalles del recurso	Registro de dominio, proxy inverso o HTTPS confiable
Configuración de monitor controlada por el usuario	Precisión de detección garantizada o entrega de alertas
Uptime Kuma bajo su licencia de código abierto	Mantenimiento de Uptime Kuma por parte de VoyraCloud después de la entrega

La imagen no incluye una credencial de administrador fija, modo sin autenticación, secretos de notificación, un dominio, un certificado o un punto de gestión público. Eso mantiene el primer acceso privado y evita colocar una página de creación de cuentas no inicializada directamente en Internet.

¿Qué tipos de monitores deberías usar?

Elige cada tipo de monitor de Uptime Kuma según la capa que necesites probar, porque un ping exitoso no prueba que un sitio web, API o aplicación funcione correctamente. Un conjunto de monitoreo útil verifica la capa orientada al usuario y las dependencias seleccionadas en lugar de depender de un solo latido genérico.

Tipo de monitor	Qué puede verificar	Limitación importante
HTTP o HTTPS	Una URL responde y devuelve un estado esperado	Una respuesta exitosa puede contener contenido incorrecto
Palabra clave	Una respuesta incluye o excluye texto esperado	Las verificaciones de texto no validan cada función comercial
Consulta JSON	Una respuesta de API contiene un valor esperado	La consulta debe coincidir con la estructura de respuesta real
Puerto TCP	Un servicio de red acepta una conexión	Un puerto abierto no prueba que la aplicación esté sana
Ping	Un host responde a ICMP	ICMP puede ser filtrado, y una respuesta no prueba que una aplicación funcione
Registro DNS	Un resolvedor devuelve el registro esperado	Una vista de resolvedor puede no representar la propagación global
WebSocket	Un punto final de WebSocket puede ser alcanzado	No valida cada flujo de mensajes
Push	Un trabajo o proceso remoto informa su propio latido	Un push faltante necesita una ventana de alerta diseñada para ese trabajo
Información del certificado	Estado del certificado e información de expiración	La renovación aún depende de tu proceso de certificado

Para un sitio web público, un conjunto práctico podría incluir una verificación de HTTPS, una verificación de palabra clave o JSON para contenido significativo, y una verificación de expiración de certificado. Para un servicio interno accesible desde el VPS, una verificación TCP o HTTP puede agregar visibilidad a la infraestructura. Para un trabajo programado, un monitor de push puede detectar cuándo el latido esperado no llega.

Evita crear varios monitores que fallen por la misma razón y luego tratarlos como evidencia independiente. El diseño del monitor debe reflejar los modos de falla reales: DNS, TLS, accesibilidad de red, respuesta de aplicación, corrección de contenido y finalización de trabajos en segundo plano.

¿Qué significa el perfil de validación de 20 monitores?

El perfil de 20 monitores es una carga de trabajo de aceptación conservadora para la configuración inicial de la imagen, no una promesa de capacidad máxima. La validación planificada utiliza 20 monitores a intervalos de 60 segundos durante 24 horas, seguida de un reinicio del VPS y una verificación de persistencia.

Esa validación está destinada a responder una pregunta específica: ¿puede la configuración de entrada elegible ejecutar una pequeña instalación de Uptime Kuma sin eventos de falta de memoria, bloqueo de base de datos, reinicios inesperados de contenedores o pérdida de datos bajo una carga de trabajo definida? No prueba que el mismo plan pueda soportar:

Monitores ilimitados.
Intervalos de verificación muy cortos.
Cuerpos de respuesta grandes o consultas JSON costosas.
Muchos usuarios concurrentes o visitantes de páginas de estado públicas.
Períodos de retención largos sin crecimiento de almacenamiento.
Volumen de notificaciones pesado.
Monitoreo de Docker con acceso al socket del host.
Aplicaciones adicionales compartiendo el mismo VPS.

El uso real de recursos depende del tipo de monitor, intervalo, tiempo de espera, tamaño de respuesta, retención de historial, comportamiento de notificación, actividad del panel y otro software en el servidor. Comienza con un conjunto medido, observa el uso de CPU, memoria, disco, comportamiento de la base de datos y duración de la verificación, luego pasa a una configuración de VPS de VoyraCloud más grande cuando la carga de trabajo real lo requiera.

No interpretes el mínimo del flujo de compra como una recomendación de tamaño universal. Es una puerta de elegibilidad para el perfil de inicio validado.

¿Cómo deberías publicar Uptime Kuma de manera segura?

Publica Uptime Kuma a través de un dominio o subdominio dedicado, un proxy inverso capaz de WebSocket y HTTPS confiable en el navegador mientras mantienes el puerto 3001 vinculado a localhost. El acceso a largo plazo a través de túnel SSH también es válido cuando solo los administradores necesitan el panel y no se requiere una página de estado pública.

La guía de proxy inverso de Uptime Kuma explica que la aplicación utiliza WebSocket y requiere que el proxy pase los encabezados Upgrade y Connection. También señala que Uptime Kuma no admite ser alojado bajo un subdirectorio de URL normal como /uptime-kuma; usa un nombre de host dedicado como status.example.com.

Un bloque de ubicación típico de Nginx incluye:

location / {
    proxy_pass http://127.0.0.1:3001;
    proxy_http_version 1.1;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
}

Este fragmento solo cubre la ruta del proxy. Debes configurar por separado el nombre de host, el certificado TLS confiable, la renovación del certificado, la redirección de HTTP a HTTPS, el firewall y la política de acceso. Verifica el ejemplo oficial actual para tu proxy inverso elegido antes de aplicarlo.

Usa esta lista de verificación de producción:

Crea un registro DNS para un nombre de host dedicado.
Mantén 3001/tcp no disponible desde Internet público.
Configura el proxy inverso para alcanzar 127.0.0.1:3001.
Preserva los encabezados de actualización de WebSocket.
Instala un certificado confiable por los navegadores normales.
Redirige HTTP plano a HTTPS.
Confirma que el panel se actualiza sin errores de WebSocket.
Prueba el inicio de sesión, cierre de sesión, actualizaciones de monitores y páginas de estado.
Restringe el nombre de host de administración cuando el acceso público no sea necesario.
Revisa la configuración de proxy confiable solo después de que la ruta del proxy y del firewall sea correcta.

HTTPS confiable protege las credenciales y el tráfico de sesión en tránsito, pero no asegura una contraseña de administrador débil o un servidor desactualizado. Mantén SSH endurecido, limita privilegios, habilita la autenticación de dos factores donde sea apropiado y mantén el sistema operativo y el proxy inverso.

¿Cómo funcionan las notificaciones y las páginas de estado?

Las notificaciones y las páginas de estado son funciones que configuras después de la inicialización; la imagen no incluye cuentas de terceros, credenciales, garantías de entrega o un dominio público. Uptime Kuma soporta muchos métodos de notificación, pero cada proveedor tiene su propia cuenta, disponibilidad, precios, límites y comportamiento de entrega.

La documentación de métodos de notificación oficial proporciona referencias de configuración específicas del proveedor. Agrega solo integraciones que tu equipo posee, almacena las credenciales con cuidado y envía una notificación de prueba antes de depender de ellas. Una prueba exitosa demuestra que un mensaje funcionó en ese momento; no garantiza la entrega futura.

Para cada monitor importante:

Decide quién debe recibir una alerta.
Establece un intervalo de verificación y una política de reintentos que se ajuste al servicio.
Configura uno o más métodos de notificación de propiedad del usuario.
Prueba las notificaciones de fallo y recuperación.
Confirma que una persona de guardia puede actuar sobre el mensaje.
Documenta qué hacer cuando el monitor informa un fallo.

Las páginas de estado te permiten compartir estados de monitores seleccionados e información de incidentes. No necesitan exponer cada monitor interno. Agrupa los servicios de una manera que los clientes entiendan, evita publicar nombres de host sensibles o topología interna, y usa tu propio dominio y ruta de proxy segura para el acceso público.

No supongas que cada integración de notificación es gratuita. Algunos servicios pueden cobrar, limitar el uso, cambiar sus APIs o requerir configuración adicional. VoyraCloud no proporciona esas cuentas de terceros y no puede garantizar que un proveedor acepte o entregue un mensaje.

¿Cómo se almacenan y respaldan los datos de Uptime Kuma?

Uptime Kuma mantiene su estado de aplicación bajo /app/data, que debe permanecer en almacenamiento local persistente y debe ser respaldado por separado del VPS en ejecución. La guía de instalación oficial requiere soporte de sistema de archivos para bloqueos de archivos POSIX y advierte sobre problemas de bloqueo de archivos comúnmente asociados con NFS.

Los datos persistentes incluyen la base de datos y el estado de la aplicación necesarios para elementos como:

Configuraciones de administrador y usuario.
Definiciones de monitores.
Historial de monitoreo.
Configuración de notificaciones.
Páginas de estado.
Programas de mantenimiento.
Otras configuraciones de instancia.

Un reinicio normal del VPS debería preservar esos datos y reiniciar la aplicación. Ese comportamiento es persistencia, no recuperación de desastres. La eliminación accidental, la corrupción de la base de datos, credenciales comprometidas, una actualización fallida, pérdida de almacenamiento o eliminación del VPS aún pueden eliminar la única copia.

Una rutina de respaldo más segura es:

Identificar el volumen Docker local real o el directorio local mapeado a /app/data.
Programar copias de seguridad a un destino fuera del VPS.
Detener o pausar Uptime Kuma cuando el método de respaldo elegido requiera una copia de base de datos consistente.
Copiar el conjunto completo de datos, no solo una lista de monitores exportados.
Cifrar y proteger la copia de seguridad porque puede contener detalles operativos y credenciales de notificación.
Retener más de un punto de recuperación.
Restaurar a una instancia de prueba separada y verificar cuentas, monitores, historial, notificaciones y páginas de estado.
Registrar la versión de la aplicación asociada con la copia de seguridad.

No coloques el directorio activo /app/data en NFS para esta imagen. Un destino de respaldo remoto es apropiado para los artefactos de respaldo copiados; es diferente de ejecutar la base de datos activa directamente en un sistema de archivos de red.

¿Cuál es el punto ciego del monitoreo en el mismo servidor?

Una instancia de Uptime Kuma no puede informar de manera confiable fallos que también eliminen su propia ruta de cómputo, red o notificación. Si Uptime Kuma se ejecuta en el mismo VPS que el sitio web que monitorea, una interrupción del VPS puede detener tanto el sitio web como el monitor antes de que se envíe la alerta.

Aún cuando el servicio monitoreado esté en otro servidor, una ubicación de Uptime Kuma aún lo observa desde una red y una región. Una ruta de ISP local, un problema de red regional, una diferencia de resolvedor DNS o una política de firewall pueden afectar esa vista sin representar la experiencia de cada usuario.

Usa el despliegue de acuerdo con la consecuencia:

Necesidad de monitoreo	Enfoque apropiado
Panel conveniente para pequeños servicios	Una instancia de Uptime Kuma autoalojada puede ser suficiente
Monitorear un servicio en otro VPS	Coloca Uptime Kuma fuera del dominio de falla del servidor monitoreado cuando sea práctico
Detectar diferencias de accesibilidad regional	Usa verificaciones independientes desde múltiples ubicaciones
Alertar durante la falla del VPS de monitoreo	Agrega un latido externo o un servicio de monitoreo independiente
Monitoreo de alta disponibilidad	Diseña una arquitectura de monitoreo de múltiples sistemas separada

La imagen de aplicación no proporciona monitoreo distribuido, alta disponibilidad o un verificador externo independiente. Trátala como un punto de monitoreo y agrega cobertura independiente cuando las alertas perdidas tengan un impacto comercial significativo.

¿Cómo deberías actualizar Uptime Kuma?

Actualiza Uptime Kuma deliberadamente revisando la guía de liberación oficial, respaldando /app/data y validando la nueva versión antes de depender de ella. VoyraCloud no actualiza automáticamente las instancias de los clientes después de que se crea el VPS.

Sigue la guía de actualización de Uptime Kuma oficial que se aplica a la versión principal instalada y al método de despliegue. Antes de una actualización:

Lee las notas de la liberación y los requisitos de migración.
Registra la versión de la aplicación que se está ejecutando actualmente.
Crea y verifica una copia de seguridad fuera del servidor de /app/data.
Confirma que hay suficiente espacio libre en disco.
Planifica una ventana de mantenimiento para una instancia de monitoreo importante.
Usa una versión específica aprobada en lugar de una etiqueta flotante no revisada.
Inicia la instancia actualizada y revisa sus registros.
Prueba el inicio de sesión del administrador, varios tipos de monitores, una notificación, una página de estado y la recuperación de reinicio.
Mantén un plan de reversión compatible con los cambios de base de datos descritos por la liberación.

No supongas que revertir la imagen del contenedor siempre es suficiente. Una migración de versión principal puede cambiar los datos de la aplicación, por lo que la recuperación puede requerir la copia de seguridad de datos previa a la actualización, así como la versión anterior de la imagen.

Las actualizaciones del sistema operativo, actualizaciones de Docker, actualizaciones de proxy inverso y renovación de certificados son responsabilidades separadas. Un contenedor Uptime Kuma actual no hace que el resto del servidor esté actualizado.

Errores comunes a evitar

La mayoría de los errores de despliegue de Uptime Kuma provienen de exponer la inicialización, sobreestimar una ubicación de monitoreo o tratar el almacenamiento persistente como un plan de operaciones completo. Evita estos errores:

Publicar el puerto 3001 antes de crear al administrador. Mantenlo en localhost y usa el túnel SSH.
Dejar el panel en HTTP público. Usa HTTPS confiable para cualquier acceso público.
Olvidar los encabezados del proxy de WebSocket. La interfaz puede cargarse pero no actualizarse correctamente.
Alojar bajo un subdirectorio. Usa un dominio o subdominio dedicado.
Ejecutar /app/data activo en NFS. Mantenlo en almacenamiento local compatible.
Llamar a la persistencia de reinicio una copia de seguridad. Almacena copias probadas fuera del VPS.
Asumir que una página de estado crea un monitoreo independiente. Se presenta por la misma instancia de Uptime Kuma.
Monitorear un VPS solo desde sí mismo. Una falla total del servidor puede silenciar tanto el servicio como su monitor.
Tratar 20 monitores como un máximo o mínimo garantizado. Es una carga de trabajo de validación definida, no un resultado de capacidad universal.
Esperar que la entrega de notificaciones esté garantizada. La disponibilidad del proveedor, credenciales, cuotas, enrutamiento y el host de monitoreo son importantes.
Habilitar cada integración sin un propietario. Configura solo canales que alguien pruebe y responda.
Actualizar sin una copia de datos restaurable. Respalda todos los datos de la aplicación completos antes de cambiar versiones.

FAQ

¿Puedo autoalojar Uptime Kuma sin instalarlo manualmente?

Sí. La imagen de aplicación de VoyraCloud proporciona una instancia de Uptime Kuma preinstalada en un Cloud VPS o Residential IP VPS elegible. Aún debes crear el primer administrador, agregar monitores, configurar notificaciones y gestionar la seguridad, actualizaciones, copias de seguridad y acceso público.

¿Por qué se muestra `http://127.0.0.1:3001` en lugar de la IP del servidor?

La dirección local evita que la página de configuración del administrador no inicializada se exponga directamente a Internet. Establece el túnel SSH desde tu computadora, mantén la sesión abierta y luego navega a la URL local. El túnel reenvía de forma segura tu conexión del navegador a Uptime Kuma en el VPS.

¿Puedo exponer el puerto `3001` directamente a Internet?

La exposición directa no es el camino de producción recomendado. Mantén el servicio vinculado a localhost y usa un proxy inverso con un nombre de host dedicado, soporte para WebSocket, HTTPS confiable y una política de acceso adecuada. La imagen de aplicación no configura automáticamente esa ruta pública.

¿Incluye Uptime Kuma SMS, correo electrónico, Slack u otros servicios de notificación gratuitos?

No. Uptime Kuma puede integrarse con muchos proveedores de notificación, pero tú proporcionas y gestionas la cuenta y las credenciales del proveedor. Los precios de terceros, cuotas, disponibilidad y entrega de mensajes están fuera de la imagen de la aplicación y pueden cambiar.

¿Es suficiente un VPS de 1 GB para Uptime Kuma?

Puede ser un punto de partida elegible solo después de que pase la validación de imagen definida, pero la capacidad real depende de tu carga de trabajo. El perfil inicial utiliza 20 monitores a intervalos de 60 segundos durante 24 horas. Más monitores, intervalos más cortos, respuestas más grandes, historial más largo, servicios adicionales o un uso más intensivo del panel pueden requerir más memoria, CPU y almacenamiento.

¿Proporciona Uptime Kuma alta disponibilidad o monitoreo externo?

No. Esta imagen proporciona una instancia de Uptime Kuma autoalojada en un VPS. La alta disponibilidad, verificaciones distribuidas y monitoreo externo independiente requieren sistemas y arquitecturas adicionales que no están incluidos.

¿Uptime Kuma me alertará si falla su propio VPS?

Puede que no, porque el proceso que envía la alerta puede fallar con el VPS o su ruta de red. Usa un latido externo o una ubicación de monitoreo independiente cuando sea importante detectar la falla del host de Uptime Kuma.

¿Qué debo respaldar?

Respalda todos los datos persistentes mapeados a /app/data y almacena la copia de recuperación fuera del VPS. Protege la copia de seguridad porque puede contener configuración de monitoreo y secretos de notificación, y prueba una restauración en lugar de asumir que un conjunto de archivos copiados es utilizable.

¿VoyraCloud actualiza automáticamente Uptime Kuma?

No. Los nuevos recursos de VPS reciben la versión de aplicación aprobada para la imagen en el momento de la creación, mientras que las actualizaciones posteriores son gestionadas por el cliente. Revisa las instrucciones oficiales de actualización, respalda /app/data y prueba la instancia actualizada antes de depender de ella.

Conclusión

Autoalojar Uptime Kuma cuando deseas un panel de monitoreo sencillo, verificaciones configurables, notificaciones y páginas de estado bajo tu propia administración. Comienza de forma privada a través del túnel SSH, diseña monitores en torno a modos de falla reales, mantén /app/data en almacenamiento local persistente, respáldalo fuera del VPS y agrega un proxy inverso capaz de WebSocket con HTTPS confiable solo cuando se requiera acceso público.

Una instancia es útil para muchas necesidades de monitoreo pequeñas, pero sigue siendo un punto de observación con un dominio de falla. Agrega monitoreo independiente cuando el host de Uptime Kuma, la accesibilidad regional o la continuidad de alertas también deban ser cubiertos.

Usa la imagen de aplicación de VoyraCloud para Uptime Kuma para comenzar desde un entorno de VPS de VoyraCloud preinstalado mientras mantienes el acceso, los datos, las notificaciones y las operaciones bajo tu control.