RunCloud ha puesto al día su plataforma con una batería de cambios que, sin grandes estridencias, atacan tres dolores muy comunes en producción: estabilidad de HTTP/3, recuperación automática de servicios y autenticación centralizada para aplicaciones detrás de NGINX. A ello se suma un nuevo control de sincronización del agente para evitar desajustes tras restauraciones a nivel proveedor, además de soporte de PHP 8.4.11 (en servidores NGINX). El resultado: menos caídas misteriosas, más visibilidad de lo que corre realmente en cada máquina y más opciones “enterprise” sin abandonar la filosofía de panel único que ha hecho popular a RunCloud.
A continuación, un repaso en profundidad —con foco en qué cambia para el día a día— de las versiones RunCloud Agent v2.14.0+2, v2.13.1+7 y nginx-rc 1.27.1+7 incluidas en este ciclo.
HTTP/3 más estable: adiós a los timeouts esporádicos
Varios usuarios habían reportado casos límite con HTTP/3 —el protocolo basado en QUIC sobre UDP— que se manifestaban en cortes y timeouts ocasionales. La nueva RunCloud Agent v2.14.0+2 introduce la corrección que elimina ese comportamiento intermitente.
Qué significa en la práctica: si ya sirve su aplicación por HTTP/3, debería notar conexiones más estables y menos caídas que no dejan rastro claro en registros. Y si aún no lo ha activado, conviene recordar por qué interesa hacerlo: HTTP/3 mejora la latencia de establecimiento (0-RTT/1-RTT), evita el bloqueo de cabecera de línea (HOL) propio de TCP en multiplexación y se comporta mejor en redes con pérdida o variación de latencia (móvil, Wi-Fi, last mile). RunCloud, además, mantiene una guía específica para habilitar HTTP/3 en servidores core contenerizados.
Recomendación: revisar dashboards y logs en horas pico tras actualizar; si tenía reglas de fallback a HTTP/2, verifique que no activan de forma innecesaria por falsos positivos.
Nuevo “Sync Agent”: el panel y la máquina, por fin alineados
Bajo Server Settings → Agent Settings, aparece una opción que muchos admins echaron de menos tras restauraciones a bajo nivel: Sync Agent. En escenarios de restauración desde copias del proveedor (p. ej., snapshots de la nube), puede ocurrir que el agente que corre en el servidor y el que se muestra en el dashboard no coincidan. Hasta ahora, esa desalineación generaba confusión (¿tengo la versión parcheada o la anterior?) y, a veces, falsas alarmas.
Con Sync Agent, el usuario puede forzar la lectura de la versión real del agente en el servidor, actualizar la que aparece en la consola y, si es necesario, elevar el agente a la última versión. La opción está en la pestaña Settings del servidor, justo sobre la conocida Danger Zone.
Por qué importa: las decisiones de mantenimiento —activar una función, aplicar un hotfix— dependen de la versión efectiva del agente. Este botón ahorra tickets, ida-y-vuelta y diagnósticos erróneos tras un restore a nivel proveedor.
Auto Healing 2.0: reinicios más fiables y menos ruido en los registros
El mes pasado, RunCloud lanzó Auto Healing, su mecanismo para reiniciar automáticamente servicios caídos. Con v2.13.1+7, afina la puntería: corrige incidencias relacionadas con registros y subsana casos en los que algunos servicios no se reiniciaban como debían. En términos simples, el “sistema de auto-reparación” es ahora más predecible.
Qué cubre: NGINX, MariaDB, PHP-FPM y Redis. Si cualquiera de estos servicios falla (o queda colgado), Auto Healing intentará recuperarlo sin intervención humana.
Impacto: menos tiempo fuera (downtime) por caídas puntuales, menos madrugadas de guardia. Eso sí, recuerde que la función requiere RunCloud Agent v2.13.0+7 o superior y debe activarse en Server → Settings → Auto Healing Services.
Consejo de operación: Auto Healing es un salvavidas, no un sustituto de la causa raíz. Si detecta reinicios recurrentes de, por ejemplo, PHP-FPM, conviene mirar carga, límite de procesos, memoria, bloqueos o filtros del WAF antes de dar el asunto por resuelto.
NGINX aprende SSO: llega ngx_http_auth_request_module
La actualización nginx-rc 1.27.1+7 añade el módulo ngx_http_auth_request_module. Aunque el nombre no sea de lo más amigable, su alcance sí lo es: permite delegar la autenticación en un servidor externo —un microservicio de auth, un IdP corporativo, un endpoint de verificación— antes de entregar una petición a la aplicación.
Qué habilita:
- SSO (Single Sign-On) y autenticación centralizada para múltiples aplicaciones detrás de NGINX, sin duplicar lógica en cada app.
- Protección de APIs con reglas en el reverse proxy: la ruta solo pasa si el servicio externo devuelve 200 OK; se deniega con 401/403 según el caso.
- Escenarios enterprise: validación de JWT, OAuth2/OIDC y cabeceras de identidad, integración con puertas de enlace de API.
Quién se beneficia: startups y SaaS con varios fronts bajo un mismo dominio; agencias que gestionan sitios de clientes con inicio de sesión corporativo; equipos con necesidades de control de acceso más sofisticadas (segmentación por roles y claims).
Buenas prácticas: defina un servicio rápido para la comprobación (latencia baja), maneje caché de decisiones cuando sea seguro y registre tanto decisiones como motivos (para auditorías).
PHP 8.4.11 disponible en NGINX (y una nota sobre OpenLiteSpeed)
RunCloud incorpora PHP 8.4.11 para servidores NGINX. La plataforma OpenLiteSpeed, por limitaciones del propio stack, no gestiona actualizaciones de PHP desde RunCloud; cuando el proveedor ofrezca la nueva versión, aparecerá automáticamente en los servidores del usuario. Si su runtime es NGINX, puede programar el salto desde el panel con el proceso habitual.
Recomendación: pruebe primero en staging (compatibilidad de extensiones, cambios de comportamiento), revise CLI y FPM (RunCloud publica guía específica para actualizar PHP CLI) y planifique ventanas de bajo tráfico.
Guías nuevas y contenido destacado del mes
RunCloud ha publicado varias guías que complementan los cambios:
- Añadir cabeceras HTTP personalizadas (útil para seguridad, caching, control de CSP).
- Brotli: compresión y lectura de speed tests (para no confundir compresión con latencia).
- Actualizar versión de PHP CLI (coordinación entre CLI y FPM).
- Bloquear bots “malos” en apps y servidores (listados actualizados y estrategias por capa).
Y, entre los artículos de referencia en el blog: cómo eliminar directorios masivos en Linux, arreglar ERR_NETWORK_CHANGED en Chrome, limpiar DNS cache en distintos sistemas, diagnosticar “Error establishing a database connection” en WordPress, matar procesos en Linux, solventar ERR_SSL_PROTOCOL_ERROR, verificar versión de SO en Linux, cambiar la URL de un WordPress con seguridad, medir espacio en disco, arreglar Cloudflare HTTP 526, comparar SMTP para correo de marketing y alternativas a reCAPTCHA, entre otros. Lectura útil para un recetario DevOps de guardia.
Qué debería hacer hoy un sysadmin con estos cambios
- Actualizar agente y NGINX a v2.14.0+2 y nginx-rc 1.27.1+7; sincronizar versión con Sync Agent tras restauraciones.
- Activar/Verificar Auto Healing y revisar logs: ¿qué reinició y por qué? Ajuste límites si ve patrones.
- Habilitar HTTP/3 (si no lo ha hecho) en servidores contenerizados siguiendo la guía; monitorizar errores 4xx/5xx y latencias tras el cambio.
- Explorar
auth_request: si tiene un IdP (OIDC, OAuth2), valore centralizar authZ con este módulo y descargar a NGINX parte del trabajo. - Planificar salto a PHP 8.4.11 en staging y, después, en producción con roll-back preparado.
Impacto para desarrolladores y equipos de producto
- Backends y APIs con SSO: usar
auth_requestreduce deuda técnica e impone un punto único para políticas (p. ej., rate limits por claims). - HTTP/3 y Brotli: combinado, ofrece mejoras de TTFB y experiencia en fronts SPA/MPA con recursos pesados.
- Auto Healing: alarga el “colchón” operativo, pero no sustituye la telemetría de causa raíz; incorpórela a dashboards de producto.
Un apunte de cultura operativa: automatizar con criterio
El refuerzo de Auto Healing y la llegada de HTTP/3 estable invitan a automatizar más. Hágalo con guardarraíles: defina alarma si un servicio reinicia n veces en m minutos; registre dumps y métricas pre-reinicio; trace versiones en Sync Agent; evite que un reinicio silencie problemas de diseño (fuga de memoria, timeouts por N+1, deadlocks).
Lo bueno, lo mejor y lo todavía mejorable
Lo bueno
- Corrección tangible en HTTP/3.
- Sync Agent para alinear panel y realidad.
- Auto Healing más fiable y menos ruidoso.
auth_request: ficha clave para SSO/authZ modernizada.- PHP 8.4.11 listo en NGINX.
Lo mejor
- El enfoque de guías y recetario que acompaña —evita que los cambios caigan en saco roto.
Lo mejorable
- Más telemetría expuesta de Auto Healing (contadores, razones, heatmaps) ayudaría a priorizar técnicos.
- Un asistente de SSO guiado para
auth_requestbajaría aún más la barrera de entrada.
Conclusión
Esta actualización mensual de RunCloud no presume de grandes “features bandera”, pero sí entrega lo que más falta hace en producción: estabilidad, observabilidad y controles que permiten construir capacidades “enterprise” sin montar un castillo de naipes. La estabilidad de HTTP/3 quita un clavo del zapato a los que ya habían dado el salto; Auto Healing vuelve a ganar puntos como failsafe operativo; auth_request abre una vía nativa para SSO y autorización centralizada; y Sync Agent cierra una brecha de visibilidad que provocaba diagnósticos erróneos tras restauraciones.
Para sysadmins y desarrolladores, la consigna es clara: actualizar, encender Auto Healing si no está activo, habilitar HTTP/3 en los contenerizados, empezar a prototipar SSO con auth_request y planificar el salto a PHP 8.4.11. Son tareas de poco brillo mediático, pero de alto retorno en SLA, MTTR y, sobre todo, en horas de descanso que el equipo no echará de menos.
Preguntas frecuentes
¿Cómo habilitar HTTP/3 en RunCloud para servidores contenerizados sin romper nada?
Siga la guía de RunCloud para activar HTTP/3 en servidores core contenerizados. Tras habilitarlo, monitorice latencias, errores 4xx/5xx y registros en las primeras horas. Si usa CDN/WAF delante, verifique que soporta QUIC y que no fuerza downgrade a HTTP/2.
¿Qué es Auto Healing en RunCloud y qué servicios reinicia automáticamente?
Auto Healing es la función que rearranca servicios cuando detecta fallos. Cubre NGINX, MariaDB, PHP-FPM y Redis. Requiere RunCloud Agent v2.13.0+7 o superior y se activa en Server → Settings → Auto Healing Services. Úselo como failsafe y revise causa raíz si ve reinicios recurrentes.
¿Para qué sirve ngx_http_auth_request_module y cómo usarlo en RunCloud?
Este módulo permite que NGINX consulte a un servidor externo si una petición está autenticada/autorizada antes de pasarla a la aplicación. Es ideal para SSO y control centralizado en APIs. Tras la actualización nginx-rc 1.27.1+7, puede configurarlo para validar JWT/OIDC/OAuth2 mediante un endpoint de verificación rápido, devolviendo 200 OK si el acceso es válido y 401/403 en caso contrario.
¿Cómo actualizar a PHP 8.4.11 en RunCloud y qué pasa con OpenLiteSpeed?
La versión 8.4.11 está disponible para NGINX y puede programarse desde el panel. Pruebe primero en staging, verifique extensiones y coordine CLI/FPM (RunCloud ofrece guía para actualizar PHP CLI). En OpenLiteSpeed, RunCloud no gestiona versiones de PHP; cuando el proveedor libere la actualización, aparecerá automáticamente en sus servidores.
