PatchMon 2.1: saber qué servidor lleva 200 días sin actualizar, sin abrir un solo puerto

Un vistazo en 30 segundos

• PatchMon centraliza el estado de parches de una flota de servidores Linux, FreeBSD y Windows, con inventario de paquetes, aprobación de actualizaciones y auditoría de cada ejecución.
• El agente solo habla hacia fuera: no hay que abrir puertos entrantes en los hosts vigilados, ni exponer SSH o WinRM, ni montar una VPN para gestionarlos.
• Licencia AGPL v3, un binario de Go con la interfaz React embebida, PostgreSQL 17 y Redis. Hay servicio gestionado de pago para quien no quiera alojarlo.
• La 2.1.0 salió el 13 de agosto de 2026 y es la actualización más gorda del año: envíos del agente de unos 2 MB a 1 KB, tiempo de espera automático para trabajos colgados, cuatro indicadores de estado por host y paginación en todas las listas.
• Cuatro correcciones que se notan: los contenedores LXC informan de su propio tiempo de actividad y no del host, y los hosts sin datos dejan de contarse como «al día».
• Si actualizas hoy, ve directo a la 2.1.3: la 2.1.1 arregla un bucle de arranque al subir desde la 2.1.0 que dejó a más de uno con el servicio caído.

---

Hay una pregunta que casi ninguna empresa sabe responder rápido: cuántos de sus servidores tienen actualizaciones de seguridad pendientes ahora mismo. No cuántos deberían tenerlas al día, no cuántos están en la política de mantenimiento. Cuántos, ahora, con nombre y apellidos.

Lo normal es una mezcla de unattended-upgrades en unos cuantos, un for con SSH que alguien escribió hace tres años, un playbook de Ansible que se lanza cuando hay tiempo y dos máquinas heredadas que nadie toca por miedo. Funciona hasta que sale un CVE con nombre propio y toca contestar a un cliente, a un auditor o al Esquema Nacional de Seguridad en menos de veinticuatro horas.

PatchMon ataca justo ese hueco: ver el estado real de toda la flota en un sitio, y desde ahí decidir qué se parchea, cuándo y con qué registro de quién lo aprobó. Es software libre, se puede alojar uno mismo, y la versión 2.1 lo ha puesto en un punto en el que ya es razonable mirarlo para producción y no solo para el laboratorio de casa.

Qué es y cómo está montado

Dos decisiones de diseño explican por qué esto es fácil de meter en una casa ajena.

La primera es el sentido de la conexión. El agente inicia todo el tráfico: manda sus informes por HTTPS y mantiene un WebSocket para lo que ocurre en tiempo real, como el volcado en vivo de una ejecución de parches. En el host vigilado no hay que abrir nada. Compáralo con el modelo clásico de empujar desde un servidor de gestión, que exige SSH accesible desde la máquina de control, con sus llaves, sus saltos y su lista de excepciones en el cortafuegos. Para una plataforma con clientes en varias sedes y detrás de varios NAT, la diferencia es enorme.

La segunda es el empaquetado: un binario con la interfaz dentro y una base de datos, sin runtime de Node al desplegar. Eso lo convierte en un contenedor y poco más. Sobre Proxmox hay dos caminos: Docker sobre una VM o un LXC, que es la vía oficial, o el script de la comunidad de Proxmox VE Helper-Scripts para levantarlo como contenedor directamente. Y sí, esa segunda opción es otro curl a un script que corre como root en tu nodo, con la misma advertencia de siempre: léelo antes, es tu hipervisor.

Lo que trae la 2.1

Las notas de la 2.1.0 son largas y no todas las líneas pesan igual. Estas son las que cambian el día a día.

El agente pasó de hablar mucho a hablar poco

El envío periódico de cada agente ha bajado de unos 2 MB a en torno a 1 KB, porque ahora solo sube lo que ha cambiado de verdad en lugar del inventario completo cada vez. Con veinte hosts da igual. Con quinientos hosts informando cada quince minutos, la diferencia entre subir dos megas y subir un kilobyte son gigabytes al día de tráfico y de escrituras en la base de datos.

Va acompañado de una pestaña nueva de actividad del agente, que sustituye a las de informes de paquetes y cola de agentes y guarda un historial configurable de treinta días. Es la vista a la que vas cuando alguien pregunta por qué un host lleva dos días sin dar señales.

Los trabajos colgados ya no se quedan colgados

Antes, si un apt se quedaba esperando en un host, la ejecución se quedaba en marcha para siempre en la interfaz y había que limpiarla a mano. Ahora hay un tiempo de espera configurable, de treinta minutos por defecto, tras el cual el trabajo se marca como caducado. Si el agente desaparece a mitad de la ejecución, el trabajo queda marcado como desconectado en vez de eterno, y el botón de parar funciona aunque el agente ya no esté al otro lado.

Suena a detalle menor y no lo es: un panel con trabajos fantasma es un panel en el que la gente deja de confiar, y un panel en el que nadie confía no se mira.

Los contadores decían cosas que no eran

Aquí está la corrección más incómoda de la versión, y la que más agradece cualquiera que use estos números para informar a un cliente.

Un host del que PatchMon no tenía ningún dato de paquetes se contaba como «al día». Es decir, la máquina que acababas de dar de alta y todavía no había reportado nada sumaba al verde del panel. Ahora existe una categoría separada de Awaiting data, y un host añadido pero sin inscribir muestra «esperando informe» y «sin datos de paquetes» en lugar de dos etiquetas verdes que no significaban nada.

En la misma línea, el estado de cada host se ha partido en cuatro indicadores independientes: conexión, informes, reinicio pendiente y actualizaciones. Un host puede estar conectado y reportando y aun así necesitar un reinicio, y eso antes se perdía en un único semáforo.

Los LXC dejaron de contar el tiempo del vecino

Los contenedores LXC informaban del tiempo de actividad del host, no del suyo. Cualquiera que gestione contenedores sobre Proxmox sabe por qué pasa: el contenedor comparte el núcleo del anfitrión, así que lo que se lee sin cuidado es el arranque del nodo. El resultado eran contenedores que llevaban recién reiniciados marcando ochenta días de servicio, o al revés, y decisiones de reinicio tomadas sobre un dato falso. En la 2.1 cada contenedor informa del suyo, y además el tiempo de actividad se muestra en vivo en lugar de quedarse congelado en el último informe.

Es el tipo de fallo que solo aparece cuando el producto se usa de verdad sobre contenedores en vez de máquinas completas, y que se agradece ver corregido.

Rendimiento y correcciones por distribución

La versión se ha probado contra flotas de más de mil hosts. Han entrado paginación en hosts, paquetes, repositorios y alertas, y ha desaparecido el tope de diez mil paquetes en los totales, que a partir de cierto tamaño convertía las cifras del panel en decorativas.

Y hay una tanda larga de arreglos específicos por sistema que dice bastante sobre dónde se está usando esto:

Seguridad

Se ha cerrado la suplantación de IP de cliente detrás de un proxy inverso mediante una configuración explícita de proxies de confianza, algo que importa si publicas el panel detrás de Nginx o Traefik y usas listas de IP permitidas para inscribir hosts. Los tokens quedan ligados a la sesión, cerrar sesión o cambiar la contraseña tiene efecto inmediato, las credenciales de repositorio se ocultan de los registros y el proyecto publica ya SBOM y procedencia de compilación de sus artefactos.

La actualización, en la práctica

Es sencilla, con una trampa que conviene conocer antes de empezar.

Hay tres líneas que hay que cambiar a mano en el docker-compose.yml: el mapeo de puertos del servidor pasa a usar la variable PORT, se añade un hostname al servicio del servidor, y la imagen de guacd —la que da el terminal SSH del navegador— se fija a la versión 1.6.0 en lugar de seguir latest. Después, lo de siempre:

docker compose pull
docker compose up -d

Las migraciones de base de datos se aplican solas. En el primer arranque se reconstruyen índices, así que el servicio tarda más de lo normal en responder: no es un cuelgue, es la base de datos trabajando. Y el registro detallado pasa a estar activado por defecto, que es algo a tener en cuenta si el disco del servidor va justo.

La trampa está en el número de versión. La 2.1.0 se publicó el 13 de agosto y dos días después salieron tres correcciones seguidas, la primera de ellas para un bucle de reinicios al actualizar desde la 2.1.0, causado por una migración concreta sobre la configuración de alertas de host caído. La 2.1.2 arregló el acceso con Entra ID y la 2.1.3, el acceso con ADFS, los webhooks de Mattermost y Rocket.Chat, la distribución de contenido de cumplimiento y los hosts que aparecían obsoletos tras despertar de una suspensión.

Traducido: actualiza a la 2.1.3 directamente. Y si tu autenticación va contra un proveedor de identidad corporativo, prueba el acceso en un entorno de laboratorio antes de tocar el de producción, porque esa es justo la parte que se rompió en la 2.1.0 y necesitó tres intentos.

Captura oficial del proyecto PatchMon. La flota del ejemplo tiene 73 hosts, de los que 13 están al día, 60 esperan actualizaciones y 27 un reinicio, con 90 actualizaciones de seguridad pendientes. El panel es reordenable por usuario, así que cada perfil coloca delante lo que le importa.

Lo que hay que entender antes de meterlo en producción

Esto no parchea tu hipervisor por ti, y no debería. Un agente dentro de un contenedor LXC ve los paquetes del contenedor. El nodo Proxmox que hay debajo es otra máquina con sus repositorios, su núcleo y su necesidad de reinicio, y actualizarlo tiene un procedimiento propio, con evacuación de máquinas y orden entre nodos, que ya contamos en actualizar un clúster sin cortar servicio. Que el panel te enseñe el estado del nodo está muy bien. Que decida por ti cuándo reiniciarlo, no.

Un parche sin marcha atrás es una apuesta. La aprobación previa con simulación de la transacción y el historial de auditoría son exactamente lo que pide una empresa, y PatchMon los trae. Lo que no trae, ni puede, es el punto al que volver si la actualización se lleva por delante un servicio. Eso es un snapshot antes de la ventana y una copia verificada detrás, con la regla 3-2-1 intacta. La secuencia sana es: copia, simulación, ventana, ejecución, comprobación.

El asistente de IA de la terminal merece una decisión consciente. La consola SSH del navegador incluye un panel de chat que sugiere órdenes y diagnostica errores, y funciona contra OpenRouter, Anthropic, OpenAI o Gemini. Es cómodo. También significa que fragmentos de sesión de un servidor de producción salen hacia un tercero. Si trabajas bajo ENS, RGPD o un contrato con cláusulas de confidencialidad, esa función se activa cuando esté escrito quién procesa qué y con qué base legal, no porque venga en el menú. Es el mismo razonamiento que aplicamos a cualquier servicio externo que toque datos de cliente, y del que hablamos en soberanía del dato.

El panel es acceso privilegiado. Con SSH por navegador, ejecución remota de órdenes y credenciales de repositorio dentro, esta pieza vale exactamente lo que valen sus permisos. Roles ajustados, autenticación única contra tu proveedor de identidad si lo tienes, y nada de publicarlo en internet sin más. Mismo criterio que aplicamos a cualquier panel que toque el hipervisor.

Cómo lo miramos nosotros

En una plataforma gestionada, el valor de una herramienta así no es tanto parchear —eso ya se hace— como poder demostrar qué está parcheado, cuándo se hizo y quién lo aprobó. La conversación con un cliente cambia cuando en lugar de decir «lo tenemos al día» enseñas la lista de hosts, la fecha del último informe de cada uno y el registro de la última ventana con los paquetes que tocó.

Para eso, la 2.1 es la versión que hacía falta: sin datos inventados en los contadores, sin trabajos fantasma, con estado desglosado y con un agente que no satura la red de nadie. Nuestro orden de trabajo sería el de siempre: montarlo en el laboratorio, inscribir un puñado de hosts representativos —una VM, un LXC, algo con RHEL— comprobar cómo clasifica las actualizaciones de seguridad de cada uno, y solo entonces decidir si entra en el procedimiento oficial.

Y ojo con confundir cobertura con seguridad. Tener el panel en verde significa que los paquetes están actualizados, no que la máquina esté bien configurada, ni segmentada, ni con copias que restauren. Es una capa. Buena, medible y barata, pero una.

Si estás poniendo orden en la operación de tu infraestructura y quieres saber cómo lo planteamos nosotros, mira los servicios gestionados o cuéntanos qué tienes montado.

Preguntas frecuentes

¿Hay que abrir puertos en los servidores que quiero vigilar?

No. El agente inicia todas las conexiones hacia el servidor de PatchMon por HTTPS y WebSocket seguro. En los hosts vigilados no hace falta abrir nada ni exponer SSH. Quien necesita ser accesible es el servidor de PatchMon, y solo desde donde estén los agentes.

¿Sirve para contenedores LXC de Proxmox?

Sí, y desde la 2.1 informan de su propio tiempo de actividad en lugar del anfitrión, que era un fallo molesto. Hay además inscripción automática para LXC de Proxmox. Recuerda que parchear el contenedor no parchea el nodo que hay debajo.

¿Puedo actualizar directamente desde la 2.0.2?

Sí, cambiando antes tres líneas del docker-compose.yml y dejando que las migraciones se apliquen solas en el primer arranque, que tardará más de lo normal por la reconstrucción de índices. Ve a la 2.1.3, no a la 2.1.0: esta última tenía un fallo de migración que provocaba reinicios en bucle.

¿Es gratis del todo?

El proyecto es AGPL v3 y se puede alojar uno mismo sin coste ni funciones capadas. Hay servicio gestionado de pago y soporte comercial para quien prefiera no mantener la pieza. Ojo con la AGPL si piensas ofrecer una versión modificada como servicio a terceros: obliga a publicar tus cambios.

¿Sustituye a Ansible?

No hacen lo mismo. Ansible aplica configuración deseada empujando desde fuera por SSH; PatchMon vigila el estado de parches con agentes que llaman hacia dentro y orquesta las actualizaciones con aprobación y auditoría. Conviven bien, y de hecho PatchMon se integra con Ansible.

¿Sirve para justificar cumplimiento?

Ayuda, que no es lo mismo. Trae historial auditable de cada ejecución, control de acceso por roles y escaneo con CIS de OpenSCAP y Docker Bench. Un auditor te pedirá además política escrita, ventanas definidas y evidencias de que el procedimiento se sigue. La herramienta produce las evidencias; el procedimiento lo pones tú.

Fuentes

• PatchMon/PatchMon en GitHub — código, licencia AGPL v3, arquitectura, requisitos y opciones de despliegue.
• Notas de la versión 2.1.0 — publicada el 13 de agosto de 2026: eficiencia del agente, estados de host, tiempos de espera de las ejecuciones, correcciones por distribución y cambios necesarios en docker-compose.yml.
• Publicaciones 2.1.1, 2.1.2 y 2.1.3 — 15 de agosto de 2026: bucle de reinicios al actualizar, acceso con Entra ID y ADFS, webhooks y hosts obsoletos tras suspensión.
• patchmon.net — sitio del proyecto, documentación y servicio gestionado.