Cómo autoalojar a un agente de Hermes en un VPS

Hola, soy Lena. Llevo unos meses ejecutando Hermes Agent selfhosting en tres VPS diferentes, y mi observación sincera es esta: instalarlo en un servidor tarda quizá veinte minutos. Conseguir que funcione de forma estable durante semanas sin necesidad de cuidado lleva varias iteraciones. En realidad, todavía no estoy seguro de haber acertado con la tercera caja. De eso trata esta guía — no de la instalación, sino de la capa lenta entre "funciona una vez" y "confío en que siga funcionando mientras duermo".

Si solo necesitas la ruta oficial de instalación, la documentación de instalación del Hermes Agent la cubre. Esta pieza es lo que viene después.

Cuando auto-hospedar Hermes tiene sentido

Privacidad, continuidad, control de costes, flujos de trabajo siempre activos

Antes de todo lo relacionado con el servidor — el autoalojamiento es un compromiso, no un atajo. Tiene sentido cuando necesitas uno o más de estos:

Privacidad. Tus conversaciones, recuerdos y habilidades permanecen en la infraestructura que controlas. Las llamadas a la API siguen enviándose al proveedor de modelo que configuraste, pero todo lo que las rodea — historial de sesión, perfil de usuario, archivos de espacio de trabajo — permanece local.

Continuidad. Un portátil que entra en suspensión o cierra mata a un agente local. Un VPS no. Si quieres que el agente responda a un mensaje de Telegram a las 3 de la mañana o ejecute un trabajo cron programado para el que no tuviste que abrir un terminal, lo necesitas en otro sitio.

Control de costes. El autoalojamiento no reduce los costes de los modelos: esos son los que cobra el proveedor. Lo que sí cambia es el coste general: no hay licencia de asientos, no hay precios por usuario en un plan gestionado, solo el coste de la caja más los tokens de tu proveedor.

Flujos de trabajo siempre activos. Las integraciones de pasarela (Telegram, Discord, Slack, bots de mensajería) solo tienen sentido si el agente siempre está escuchando. Lo mismo ocurre con los trabajos cron.

Si ninguna de esas opciones se aplica y usas el agente durante treinta minutos por la tarde desde el portátil, sinceramente — no te alojes tú mismo. La complejidad no merece la pena.

! [imagen] (https://uploads.evomap.ai/blog/ebab901cfe9b4a55.png)

Elige un VPS y un sistema operativo base para Hermes

Especificaciones mínimas vs recomendadas

Aquí es donde quiero criticar el encuadre de "funciona con un VPS de 5$". Técnicamente cierto. Prácticamente frágil. Esto es lo que he observado realmente:

1 vCPU / 1 GB RAM: Se iniciará. Se bloqueará con cualquier carga de trabajo real. Python + Node + los propios procesos del agente consumen RAM rápidamente, especialmente una vez que el gateway está en funcionamiento. Tuve uno de estos bloqueado durante una sola sesión de depuración.
2 vCPU / 2 GB RAM: Funciona para uso solo por CLI, un solo usuario, sin gateway. Aún es justo. El swap ayuda pero no lo soluciona.
2 vCPU / 4 GB RAM: Mi mínimo en el mundo real para gateway + cron + habilidades ligeras. Aquí es donde las cosas dejan de sentirse inestables.
2–4 vCPU / 8 GB RAM: Cómodo para uso con múltiples perfiles, varias plataformas conectadas y margen para alguna tarea pesada ocasional.

Sistema operativo base: Ubuntu 22.04 o 24.04 LTS. Uso ambos. Debian 12 también funciona bien. Cualquier otro, dependerás de ti mismo para los casos límite de dependencias.

Almacenamiento: 30–40 GB son suficientes para el propio agente. Las bases de datos de sesión crecen lentamente — quizás 50 MB por mes de uso activo. Los logs son lo que puede sorprenderte, a eso volveré.

Qué cambia cuando el gateway y cron se ejecutan continuamente

Esta es la parte que casi olvido aprender por las malas. Ejecutar Hermes interactivamente es diferente a ejecutarlo como un servicio persistente. Cuando el gateway está siempre escuchando y cron ejecutando trabajos programados, tienes:

Residencia constante en memoria (sin un estado inactivo recolectado por basura)
Volumen continuo de logs
Reintentos de red que pueden acumularse durante cortes del proveedor
Mecanismos de archivos que deben sobrevivir a reinicios
Secretos (claves API, tokens) que deben ser accesibles para el servicio, no solo tu shell

No estoy seguro de si estoy interpretando esto correctamente, pero mi impresión es que la mayoría de los informes de "mi VPS se queda sin memoria" realmente son "dimensioné para uso interactivo y luego activé gateway + 4 trabajos cron." Planifica para la carga persistente, no para la vacía.

Instalar y endurecer Hermes en un servidor

Usuario del servicio, estructura de directorios, actualizaciones, respaldos

No ejecutes Hermes como root. Esto es lo único no negociable. Crea un usuario dedicado:

Bash

sudo adduser hermes
sudo usermod -aG docker hermes   # only if you plan to use the Docker terminal backend

Luego instala como ese usuario. Todo se ubicará en ~/.hermes/ — configuración, sesiones, memoria, habilidades. Ese directorio es tu estado. Hazle copia de seguridad.

Mi copia de seguridad real es sencilla:

Bash

tar -czf hermes-backup-$(date +%F).tar.gz ~/.hermes/

Ejecuta semanalmente vía cron, envía el archivo tar fuera del servidor (almacenamiento de objetos, otro VPS, lo que sea). Lo que quieres proteger es config.yaml, la base de datos de sesiones, y MEMORY.md/USER.md. Las habilidades se pueden recuperar del hub. La memoria y la configuración no.

Para actualizaciones: el instalador incluye un camino de actualización. Pero he aprendido a hacer una instantánea o una copia de seguridad antes de cualquier actualización, porque ocasionalmente una actualización cambia el esquema de configuración y no quiero descubrirlo en medio de una conversación. La información de la versión está visible en el repositorio de GitHub de Hermes Agent si quieres revisar los registros de cambios antes de actualizar.

Cortafuegos: mantén la superficie pública del VPS al mínimo. UFW es el camino más simple — la documentación del cortafuegos de Ubuntu Server lo explica bien. Mis reglas para una máquina solo con Hermes se ven aproximadamente así:

Bash

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow ssh
sudo ufw enable

Eso es todo. Hermes no necesita ningún puerto de entrada abierto para la mayoría de las configuraciones — la puerta de enlace se conecta hacia afuera a las plataformas de mensajería. Si agregas una interfaz web o expones una API localmente, solo entonces abre un puerto específico.

Ejecutando la puerta de enlace bajo systemd

Esta es la pieza que convierte un proceso en ejecución en un servicio. Sin systemd (o algo equivalente), en el momento en que tu sesión SSH muere, también lo hace hermes gateway. Perdí un bot de Telegram al menos una vez por esto antes de escribir realmente el archivo de unidad.

Aquí está la forma que uso. Guarda como /etc/systemd/system/hermes-gateway.service:

TOML

[Unit]
Description=Hermes Agent Gateway
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
User=hermes
Group=hermes
WorkingDirectory=/home/hermes
ExecStart=/home/hermes/.local/bin/hermes gateway start
Restart=on-failure
RestartSec=10
StandardOutput=journal
StandardError=journal

[Install]
WantedBy=multi-user.target

Luego:

Bash

sudo systemctl daemon-reload
sudo systemctl enable --now hermes-gateway
sudo systemctl status hermes-gateway

Un par de detalles que desearía que alguien me hubiera dicho antes. Restart=on-failure + RestartSec=10 es lo mínimo. Sin esto, cualquier error transitorio mata el servicio permanentemente. La página del manual systemd.service tiene la lista completa de políticas de reinicio — on-abnormal es una alternativa si quieres permitir que el servicio decida salir limpiamente sin reinicio automático.

También — User=hermes está haciendo trabajo real aquí. No solo seguridad. Garantiza que el servicio lea desde el directorio ~/.hermes/ del usuario hermes y no desde el de root (que no existirá, y recibirás un error de configuración críptico). Esto lo hice mal la primera vez.

Para reforzar más el archivo de unidad — NoNewPrivileges=true, ProtectSystem=strict, PrivateTmp=true — no lo reproduciré todo aquí, pero la guía de DigitalOcean de unidades y archivos de unidad systemd muestra un ejemplo endurecido estilo producción que vale la pena copiar.

Comprobaciones de producción antes de confiar en la configuración

Comportamiento de reinicio, registros, fallo del proveedor, persistencia de archivos

Antes de llamar a una máquina "lista", paso por cuatro comprobaciones. Ninguna de ellas es opcional. Las he omitido en una máquina que creía conocer, y me arrepentí.

El reinicio sobrevive a un reinicio**.**

Bash

sudo reboot
# wait, then:
ssh back in
systemctl status hermes-gateway

Si el servicio no está activo después del reinicio, olvidaste enable. Arréglalo ahora.

Los registros son legibles y se rotan.

Bash

journalctl -u hermes-gateway -n 100
journalctl -u hermes-gateway --since "1 hour ago"

Importante — establece límites del journal antes de que el disco se llene. Edita /etc/systemd/journald.conf y configura SystemMaxUse=500M (o lo que se ajuste a tu equipo). La página del journal de systemd del Arch Wiki explica las opciones de rotación y limpieza con más detalle que la mayoría de la documentación específica de tu distro. Yo aprendí esto dejando que un equipo se quedara sin disco por completo. No es divertido.

El fallo del proveedor es recuperable.

Rompe temporalmente tu clave de API (cambia el nombre de la variable de entorno, revoca el token, lo que sea). Envía un mensaje a través del gateway. ¿Se bloquea el servicio? ¿Registra el error? ¿Se recupera una vez restauras la clave?

Mi expectativa básica: el agente debería registrar un error claro y seguir funcionando, no morir. Si muere, tienes un problema operativo que es mejor descubrir ahora que a las 3 a.m.

Persistencia de archivos a través de reinicios.

Ten una conversación. Envía un mensaje. Reinicia el servicio. Reanuda la sesión. ¿La memoria se mantiene? ¿Sobrevive la sesión? Si no, revisa los permisos de ~/.hermes/ — esto casi siempre es un problema de usuario/grupo.

Errores comunes en VPS

Memoria insuficiente, registro débil, acceso inseguro a la terminal, sin ruta de reversión

Los cuatro modos de fallo que veo con más frecuencia, en aproximadamente el orden en que yo mismo los cometí:

Memoria insuficiente. Ya cubierto. 2 GB es un mínimo, no un objetivo.

Registro débil o sin límites. Si no configuras los límites de tamaño del journal, tus registros llenarán el disco. Cuando el disco se llena, el agente falla de maneras extrañas — las escrituras de configuración fallan silenciosamente, las habilidades no se guardan, se corrompen las sesiones. Establece los límites desde el primer día.

Acceso inseguro a la terminal para el agente. Si dejas que el agente ejecute comandos arbitrarios con la terminal configurada en local y estás ejecutando como un usuario con derechos sudo, el radio de daño de un error puede ser toda tu máquina. O usa terminal.backend=docker para aislarlo, o ejecuta bajo un usuario dedicado sin sudo. Yo prefiero ambos.

Sin ruta de reversión. Una mala actualización, una mala edición de configuración, y necesitas una forma de revertir. Haz una snapshot del VPS antes de cualquier cambio importante. Mantén las últimas tres copias de seguridad en tarball. Yo las he usado. Me han salvado.

Preguntas frecuentes

¿Necesito Docker?

No es obligatorio, pero recomendado para la terminal si vas a dejar que el agente ejecute comandos arbitrarios. Sandbox más seguro.

**¿Puedo ejecutar múltiples perfiles en un solo VPS**?

Sí — hermes profiles create work, luego cambia entre ellos. Cada uno tiene configuración, memoria y habilidades aisladas.

¿Cómo actualizo sin tiempo de inactividad?

Realmente no puedes, pero el tiempo de inactividad es corto. Detén el servicio, aplica la actualización, reinicia. Un minuto o dos.

¿Puedo ejecutar el gateway y CLI al mismo tiempo?

Sí, siempre que estén en el mismo perfil. Las sesiones se comparten.

¿Qué pasa si mi proveedor se cae?

No puedes hacer nada respecto al proveedor, pero si Hermes está configurado para cambio de proveedor, intentará con el siguiente. Si no has configurado un cambio de respaldo, el gateway dará un error limpio y se recuperará una vez que el proveedor vuelva.

Podría estar pensando demasiado en esto, pero el patrón al que sigo regresando es: el VPS no es la parte difícil. La parte difícil es el descubrimiento lento y silencioso de todo lo que puede salir mal durante un mes de tiempo activo. Esa es realmente la naturaleza del autoalojamiento. Seguiré observando cómo se comporta mi propia configuración y probablemente actualizaré esto cuando rompa algo nuevo. Por ahora, lo dejaré así.