Alojamiento de Uptime Kuma en 2026: precios y restricciones de plataforma

En noviembre de 2026, los equipos que buscan autoalojar la herramienta de monitoreo de código abierto Uptime Kuma tienen cinco opciones principales de infraestructura, cada una con estructuras de costos y compensaciones técnicas distintas. El análisis destaca que, si bien plataformas como Heroku y Replit ya no son viables debido a las limitaciones del sistema de archivos, servicios como Ownkube, Fly.io, Railway y Render ofrecen entornos compatibles junto con servidores privados virtuales tradicionales.

Qué ocurrió

Uptime Kuma es un único proceso Node.js que depende de un archivo de base de datos SQLite para almacenar configuraciones de monitores, historial de comprobaciones y ajustes. Debido a esta arquitectura, el entorno de alojamiento debe proporcionar un disco que persista entre reinicios y redespliegues. La aplicación no puede funcionar correctamente en sistemas de archivos efímeros, lo que ha llevado a que su README oficial enumere Heroku y Replit como plataformas no compatibles. Cualquier host elegido debe garantizar que el directorio de datos se encuentre en un volumen local o de bloque, y no en un sistema de archivos de red como NFS, que también es incompatible.

Las opciones prácticas para 2026 incluyen Ownkube, Fly.io, Railway, Render e instancias VPS autogestionadas. Cada opción varía en complejidad de configuración, costo mensual y responsabilidad de mantenimiento. Ownkube ofrece un despliegue con un clic, HTTPS automático y un modelo de facturación prepagada. Fly.io proporciona el precio de entrada más bajo, pero requiere configuración manual mediante un archivo fly.toml. Railway y Render ofrecen despliegues basados en plantillas o Docker con discos persistentes, aunque Render impone restricciones específicas sobre los despliegues sin tiempo de inactividad cuando se adjuntan discos. Un VPS autogestionado sigue siendo la opción para quienes ya mantienen infraestructura de servidores y desean control total sobre las actualizaciones del SO y las reglas de firewall.

Detalles clave

• Ownkube: Costea aproximadamente $5 al mes con facturación medida por minuto. Incluye un volumen persistente de 2 GiB sin cargo adicional por almacenamiento y gestiona HTTPS automáticamente. La plataforma administra los parches del servidor.
• Fly.io: La opción más económica, alrededor de $2.34 al mes por una Máquina de 256 MB y un volumen de 1 GB. Los usuarios deben escribir un archivo de configuración fly.toml para montar el volumen correctamente. Los volúmenes se facturan según el tamaño aprovisionado, incluso si la máquina está detenida.
• Railway: Requiere una tarifa Hobby de $5 que incluye $5 de uso. Las plantillas adjuntan volúmenes automáticamente, pero el uso intensivo puede exceder el crédito incluido. La memoria y la CPU se facturan por separado si se superan los límites.
• Render: Comienza en $7.25 al mes por una instancia Starter más los costos de disco. Los servicios con discos adjuntos pierden la capacidad de despliegue sin tiempo de inactividad, causando breves interrupciones del monitor durante las actualizaciones. No puede escalar más allá de una instancia, lo cual se alinea con la restricción de escritura única de SQLite.
• VPS autogestionado: Ofrece el menor costo unitario para quienes ya pagan por infraestructura de servidores. El usuario es responsable de los parches del SO, la configuración del proxy inverso, la gestión de certificados y las copias de seguridad. Docker Compose es el método estándar de instalación.

Antecedentes

La dependencia de Uptime Kuma en SQLite dicta varios requisitos críticos de infraestructura. SQLite permite solo un escritor a la vez, lo que significa que la aplicación debe ejecutarse como una sola instancia. No es posible escalar horizontalmente con múltiples copias sin cambiar el backend de la base de datos, algo que Uptime Kuma no admite nativamente en este contexto. Además, el proceso nunca debe entrar en suspensión. Muchos proveedores de nube ofrecen niveles gratuitos que detienen los contenedores después de períodos de inactividad para ahorrar recursos. Para una herramienta de monitoreo, este comportamiento es fatal porque un monitor dormido no puede detectar fallas, creando un punto ciego precisamente cuando más se necesita.

Otro requisito esencial es un nombre de host público con HTTPS. Esto es necesario tanto para acceder al panel administrativo de forma segura como para servir páginas de estado a los usuarios finales. Mientras que algunas plataformas proporcionan esto automáticamente, otras requieren configuración manual de proxies inversos y certificados TLS. La elección del host a menudo depende de si el equipo prefiere la conveniencia gestionada o un control granular sobre estas capas de red.

Por qué importa

Para los equipos que ejecutan su propio software, la ubicación de la herramienta de monitoreo es tan crítica como la herramienta misma. Si Uptime Kuma se ejecuta en la misma plataforma, región o servidor que las aplicaciones que monitorea, una falla generalizada derribará el monitor junto con las apps. Esto resulta en un fallo silencioso donde no se envían alertas y la página de estado se vuelve inaccesible para los usuarios que buscan información. Para evitar esto, el monitor debe alojarse en un proveedor diferente o en una región distinta de las aplicaciones principales. Por ejemplo, si las apps se ejecutan en una plataforma en Alemania, el monitor podría ubicarse en Mumbai o en un servicio completamente diferente.

La previsibilidad de costos y la sobrecarga operativa también son factores significativos. El autoalojamiento elimina las tarifas por monitor asociadas con soluciones SaaS comerciales como UptimeRobot, que cobra $9 al mes por su plan Solo para lograr intervalos de verificación de 60 segundos. Sin embargo, el autoalojamiento introduce la carga de mantener la infraestructura subyacente. Los equipos deben sopesar los ahorros contra el tiempo dedicado a gestionar actualizaciones de servidores, copias de seguridad y parches de seguridad. La decisión a menudo depende de si la organización ya tiene capacidad DevOps para gestionar un VPS o prefiere la simplicidad de una plataforma de contenedores gestionada.

Qué puedes hacer

• Verifica que el directorio de datos de Uptime Kuma esté montado en un volumen persistente que sobreviva a redespliegues y reinicios.
• Deshabilita cualquier función de suspensión por inactividad o apagado en tu plataforma de alojamiento para asegurar comprobaciones de monitoreo continuas.
• Ejecuta solo una instancia de Uptime Kuma para prevenir la corrupción de la base de datos SQLite por escrituras concurrentes.
• Aloja el monitor en un proveedor de nube o región geográfica diferente a tus aplicaciones de producción para garantizar disponibilidad durante fallas.
• Establece una rutina regular de copia de seguridad para el archivo de datos SQLite para preservar el historial y la configuración del monitor.
• Envía alertas de prueba a todos los canales configurados, como correo electrónico, Slack o Telegram, para confirmar que las rutas de notificación funcionan antes de depender de ellas.