Cómo enseñarle a n8n a reparar servicios caídos en tu servidor por ti

Escena familiar: un contenedor con una base de datos o servidor multimedia se cae a mitad de la noche. Te despiertas con una alerta, abres la terminal, revisas los logs, reinicias el servicio caído y vuelves a dormir de mal humor. El monitoreo regular solo sabe enviar mensajes de pánico. Ve el síntoma pero ni siquiera intenta descubrir las causas.

El popular blogger tecnológico NetworkChuck publicó un repositorio interesante llamado n8n-terry-guide. Dentro hay una guía paso a paso para construir a Terry. Este es un sysadmin virtual dentro de n8n que verifica servicios, se conecta por SSH a servidores para examinar logs y te pregunta en Telegram si tiene permiso para reiniciar.

La idea suena divertida, pero detrás hay una arquitectura de agente práctica que es fácil de replicar en tu propio servidor.

Quién es Terry y por qué esto no es solo otro bot

Por lo general, la automatización de homelab se construye con scripts rígidos. El servicio se cae — se activa el comando docker restart. Si el puerto está ocupado por otro proceso, el script se rompe y comienza a enviar errores sin parar.

El enfoque de agente LLM funciona de manera diferente. El autor sugiere entrenar el modelo como un aprendiz de soporte, expandiendo gradualmente sus responsabilidades. En el repositorio, todo el proceso se divide en cinco etapas de evolución:

1. Verificador básico. El agente hace ping a un endpoint HTTP y verifica la presencia de una etiqueta HTML específica.
2. Diagnóstico. Si el servicio no está disponible, Terry se conecta mediante SSH, ejecuta docker ps, recupera el código de salida y las últimas líneas de logs.
3. Reparador automático. El modelo intenta levantar el contenedor caído y vuelve a verificar la disponibilidad del sitio.
4. Solucionador de problemas. El agente encuentra un conflicto de puerto, busca el proceso culpable usando utilidades del sistema y toma una decisión.
5. Humano en el ciclo. El modelo encuentra la causa del fallo, forma un plan de acción y espera la confirmación del propietario en el messenger.

La característica principal aquí es la quinta etapa. Ninguna persona sensata le daría a un modelo de lenguaje acceso root sin control. Terry puede realizar diagnósticos de forma independiente, pero cualquier comando de modificación debe ser aprobado.

Cómo funciona la conexión interna en n8n

Toda la lógica se construye usando nodos estándar de n8n sin escribir código personalizado en TypeScript o Python.

En el centro del esquema hay un nodo AI Agent con un modelo GPT-4o-mini conectado y un bloque Simple Memory. Para ejecutar comandos en el servidor, el autor ideó una solución elegante: un subworkflow separado con un nodo SSH.

Cuando el agente necesita verificar el estado del sistema, llama a este subproceso como Tool, pasando el comando requerido:

docker inspect website --format='{{.State.ExitCode}}'
docker logs website --tail 10

Para automatizar las verificaciones, se coloca un Schedule Trigger antes del agente, ejecutando el escenario cada 5 minutos. Para evitar que el diálogo se convierta en un desastre de texto arbitrario, se utiliza un Structured Output Parser en la salida del modelo. El agente debe devolver JSON en un formato estrictamente definido:

{
  "website_up": false,
  "message": "Контейнер остановлен из-за нехватки памяти",
  "applied_fix": false,
  "needs_approval": true,
  "commands_requested": "docker start website"
}

Gracias a la estructura estricta, el siguiente nodo IF o Switch entiende al instante si todo está bien. Si se detecta una avería, el escenario envía un mensaje a Telegram con botones de confirmación. Si presionas "Sí" — n8n devuelve el control al agente, y este realiza la reparación.

Conectando hardware real

El autor no se limitó a un sitio de prueba en Nginx. La guía incluye prompts del sistema y ejemplos de comandos para cuatro sistemas populares:

• Hypervisor Proxmox. El agente obtiene el estado del nodo, lista de VMs mediante pvesh get /nodes, y verifica los contenedores LXC.
• Equipo de red UniFi. Solicitudes a la UniFi Network API para monitorear puntos de acceso, cantidad de clientes y consumidores de tráfico.
• Network Attached Storage (NAS). Verificación de atributos SMART de discos mediante smartctl, lectura del estado del array RAID desde /proc/mdstat, y verificación de errores críticos en journalctl.
• Servidor multimedia Plex. Verificación de la interfaz web y reinicio adecuado cuando se cuelga.

Para discos y NAS, Terry está configurado para trabajar estrictamente en modo solo lectura. El prompt prohíbe explícitamente ejecutar comandos de formateo, remontaje o detención de pools.

Errores comunes con los que podrías encontrarte

Si decides desplegar un escenario así en tu propio servidor, presta atención a un par de matices que a menudo se olvidan al configurar agentes de IA.

Primero, el límite de iteraciones. Por defecto, el nodo AI Agent en n8n realiza hasta 10 llamadas a herramientas por ejecución. Si el agente se confunde con la salida de netstat o docker ps, agotará rápidamente el límite y fallará con un error. Los prompts deben ser lo más específicos posible, reduciendo el campo para experimentos.

Segundo, el paso de sesión. Al ejecutarse en un schedule, no tienes un chat en vivo, por lo que el ID de sesión chatId necesita generarse de forma fija en un nodo Edit Fields intermedio antes de enviarlo a la memoria del agente. De lo contrario, se perderá el contexto de verificaciones anteriores.

Tercero, el llamado God-Mode. En el repositorio hay un prompt con todos los derechos para la reparación automática de cualquier problema. Habilitar esto en un servidor de producción definitivamente no vale la pena: el modelo puede eliminar fácilmente un contenedor necesario para liberar un puerto ocupado.

¿Vale la pena probar?

El repositorio n8n-terry-guide no contiene archivos de exportación de workflows listos para usar — es una colección de configuraciones, instrucciones paso a paso y prompts refinados. Si ya ejecutas n8n para necesidades personales o laborales, la guía ofrece un excelente marco para crear un asistente de guardia.

El proyecto atraerá a quienes estén hartos de alertas tontas y quieran recibir en Telegram no solo un grito de "servicio caído", sino un diagnóstico listo con un botón de "reparar". Empieza pequeño: configura la verificación de un contenedor de prueba, prueba la integración con Telegram y evalúa qué tan conveniente es delegar tareas rutinarias a un modelo de lenguaje.