Desplegar un Agente IA en VPS Hetzner: Guía 2026

Por qué Hetzner sigue apareciendo para agentes autohospedados

Si has pasado algo de tiempo en el rincón autohospedado de dev.to, Medium o los grupos indie de IA en Telegram, habrás notado el mismo patrón: cuando alguien pregunta dónde ejecutar un agente IA siempre encendido por menos del precio de dos cafés, la respuesta más votada es Hetzner Cloud. La comunidad sigue aterrizando ahí por dos razones estables desde hace años: rendimiento real de CPU por euro y un Cloud Firewall limpio que puedes configurar antes de que el servidor arranque.

Este tutorial es para quien ya decidió autohospedar un agente IA (Hermes Agent, OpenClaw, una configuración de n8n con un nodo LLM, o cualquier cosa que llame a una API de modelo desde un servidor de larga duración) y quiere hacerlo en Hetzner sin saltarse las partes que importan a las 3 AM. Dimensionado, endurecimiento, Docker Compose, una prueba con Telegram y la lista honesta de cosas que se romperán tarde o temprano.

Si todavía estás decidiendo qué VPS barato usar, nuestra comparativa de VPS baratos cubre el panorama. Este post asume que ya elegiste Hetzner.

Paso 1: Elige el plan correcto

Hetzner Cloud, a mediados de 2026, divide sus planes de vCPU compartidos en tres líneas:

CX (Intel) - vCPUs Intel más antiguas, en proceso de retirada en algunas regiones
CPX (AMD EPYC) - el x86 actual por defecto, mejor rendimiento mono-hilo
CAX (ARM Ampere) - la línea más barata, excelente rendimiento por euro

Para un agente IA basado en API (uno que llama a OpenAI, Anthropic, OpenRouter o tu propio Ollama y orquesta las herramientas localmente) el plan que buscas es el más pequeño de cualquiera de estas líneas:

| Plan | vCPU | RAM | NVMe | Precio EU | Notas | |---|---|---|---|---|---| | CAX11 (ARM) | 2 | 4 GB | 40 GB | ~3,79 €/mes | Opción viable más barata | | CX22 (Intel) | 2 | 4 GB | 40 GB | ~3,79 €/mes | Siendo retirado en algunas regiones | | CPX11 (AMD) | 2 | 2 GB | 40 GB | ~4,59 €/mes | Mejor mono-hilo x86 | | CPX21 (AMD) | 3 | 4 GB | 80 GB | ~7,55 €/mes | Margen para un segundo agente o herramientas con navegador |

Los precios de la región US son algo más altos (aproximadamente 4,59 a 4,99 USD para el equivalente al CX22). Hetzner ajustó precios el 15 de junio de 2026: los nuevos pedidos usan la nueva tarifa, los servidores existentes mantienen la antigua hasta que los redimensiones.

Recomendación: empieza con CAX11 o CX22. Dos vCPU y 4 GB de RAM bastan para un único agente, una pasarela de Telegram, un pequeño reverse proxy y el daemon de Docker, con margen para la ocasional tarea con navegador headless. Si planeas ejecutar varios agentes, scrapear páginas con Playwright o lanzar skills en batch por la noche, salta al CPX21.

Si tu runtime aún no publica imagen ARM, quédate con CX22 o CPX11. La mayoría de runtimes populares (Hermes Agent, OpenClaw, n8n) ya publican imágenes linux/arm64, así que la línea CAX suele ser una opción válida.

Paso 2: Aprovisiona y blinda el servidor antes de conectarte por SSH

Este es el paso que más se salta y el que más muerde después. Hetzner te da dos firewalls (el Cloud Firewall en el borde y el UFW en el host). Usa los dos. El Cloud Firewall conviene configurarlo antes de que el servidor arranque, para que no acepte un solo paquete en un puerto que no quieres abrir.

En la Consola de Hetzner, crea un Cloud Firewall con estas reglas de entrada:

TCP 22 solo desde tu IP (o desde un CIDR pequeño si tienes un rango fijo de oficina)
TCP 80 desde 0.0.0.0/0, ::/0 (solo si vas a correr un reverse proxy en esta caja)
TCP 443 desde 0.0.0.0/0, ::/0 (solo si necesitas HTTPS para webhooks o una UI web)
ICMP desde 0.0.0.0/0, ::/0 (para que ping funcione en monitorización)

Salida: deja el "permitir todo" por defecto - el agente necesita alcanzar la API del modelo.

Ahora crea el servidor, asocia el firewall y elige Ubuntu 24.04 LTS. En el panel de claves SSH, añade la clave pública de tu portátil. No permitas login por contraseña.

Panel de control oscuro fotorrealista con un icono de escudo de red verde brillante, representando protección de firewall en la nube

Una vez arriba el servidor, conéctate por SSH como root e inmediatamente haz cuatro cosas:

# 1. Parchea
apt update && apt upgrade -y && apt install -y ufw fail2ban unattended-upgrades

# 2. Crea un usuario no root
adduser --disabled-password --gecos "" agent
usermod -aG sudo agent
mkdir -p /home/agent/.ssh && cp ~/.ssh/authorized_keys /home/agent/.ssh/
chown -R agent:agent /home/agent/.ssh && chmod 600 /home/agent/.ssh/authorized_keys

# 3. Cierra SSH
sed -i 's/^#*PermitRootLogin.*/PermitRootLogin no/' /etc/ssh/sshd_config
sed -i 's/^#*PasswordAuthentication.*/PasswordAuthentication no/' /etc/ssh/sshd_config
systemctl restart ssh

# 4. Firewall del host (UFW), redundante con el Cloud Firewall pero buena red de seguridad
ufw default deny incoming && ufw default allow outgoing
ufw allow OpenSSH && ufw allow 80/tcp && ufw allow 443/tcp
ufw --force enable

Luego activa actualizaciones de seguridad desatendidas y fail2ban con valores por defecto razonables:

dpkg-reconfigure -plow unattended-upgrades   # responde Yes
systemctl enable --now fail2ban

Por defecto, fail2ban banea IPs tras 5 intentos fallidos de SSH en 10 minutos. El Cloud Firewall ya descarta la mayoría en el borde, pero fail2ban atrapa lo que se cuele (un compañero, un runner de CI mal configurado, tú).

Cierra sesión como root, vuelve a entrar como agent y continúa desde ahí.

Paso 3: Instala Docker

Docker es la forma más limpia de ejecutar un agente IA en un VPS en 2026. El agente queda aislado, las dependencias no contaminan el host y las actualizaciones son un pull && up.

# Como el usuario agent, con sudo
curl -fsSL https://get.docker.com | sudo sh
sudo usermod -aG docker agent
newgrp docker
docker run --rm hello-world

Si hello-world imprime, Docker está listo.

Paso 4: Despliega el agente con Docker Compose

Crea ~/agent/docker-compose.yml en el servidor. El ejemplo de abajo es para Hermes Agent, pero la estructura es idéntica para OpenClaw, Open WebUI + un proveedor LLM o cualquier otro runtime de agente en contenedor.

services:
  agent:
    image: ghcr.io/your-runtime/agent:latest
    container_name: agent
    restart: unless-stopped
    env_file: .env
    volumes:
      - ./data:/data
      - ./skills:/skills
      - ./memory:/memory
    ports:
      - "127.0.0.1:8080:8080"   # UI web atada solo a localhost

Luego crea ~/agent/.env:

# Proveedor de modelo (BYOK - bring your own key)
OPENAI_API_KEY=sk-...
# O cualquiera de:
# ANTHROPIC_API_KEY=...
# OPENROUTER_API_KEY=...

# Pasarela de mensajería
TELEGRAM_BOT_TOKEN=...
TELEGRAM_ALLOWED_USERS=12345678   # tu ID de usuario de Telegram

# Persistencia
DATA_DIR=/data
MEMORY_DIR=/memory

chmod 600 .env para que otros usuarios de la caja no puedan leer tus claves, y arráncalo:

docker compose up -d
docker compose logs -f agent

La política restart: unless-stopped es lo que mantiene al agente vivo entre reinicios. Si prefieres una instalación nativa en lugar de Docker, el equivalente es una unidad systemd con Restart=always y WantedBy=multi-user.target.

Paso 5: Conecta Telegram y prueba

Si elegiste Telegram como superficie de mensajería (la mayoría de quienes autohospedan lo hacen, porque la Bot API es gratis y al instante), el bucle de prueba es corto:

Habla con @BotFather en Telegram, ejecuta /newbot, guarda el token en .env.
Habla con @userinfobot para obtener tu ID numérico de Telegram y ponlo en TELEGRAM_ALLOWED_USERS.
docker compose restart agent.
Abre tu nuevo bot en Telegram y envía "hola".

Deberías ver respuesta en pocos segundos. Si no, docker compose logs -f agent suele apuntar directo al problema (token ausente, ID de usuario mal puesto, proveedor de modelo devolviendo 401).

Para un recorrido mucho más profundo del lado de Telegram (grupos, temas, modo voz, troubleshooting), mira cómo construir un agente IA en Telegram.

Primer plano fotorrealista de un smartphone mostrando una burbuja de chat en tema oscuro con un acento verde

Paso 6: Copias y monitorización (lo que todo el mundo se salta)

Dos cosas baratas que se amortizan la primera vez que algo se rompe:

Snapshots de Hetzner: en la Consola, activa un snapshot diario del servidor. Unos 0,012 €/GB/mes, alrededor de 0,50 €/mes para un disco de 40 GB. Etiqueta uno "before-update" antes de cualquier docker compose pull.
Un ping de uptime: gratis con BetterStack o UptimeRobot. Que pegue a https://tu-dominio/health (o un chequeo TCP) cada 5 minutos. La primera vez que la pasarela de Telegram caiga a las 3 AM, te enterarás antes de comer y no a la hora de comer.

Para el estado propio del agente (ficheros de memoria, skills, historial), pon un cron de una línea que empaquete el volumen montado en /var/backups/agent-$(date +%F).tar.gz y rote copias antiguas. Rsync semanal fuera de la caja a un segundo VPS barato, un bucket compatible S3 o tu portátil.

Paso 7: Actualizaciones

Una vez por semana, con el snapshot ya hecho:

cd ~/agent
docker compose pull
docker compose up -d
docker image prune -f

Suele tardar menos de un minuto. Si la nueva imagen se rompe, restaura el snapshot desde la Consola de Hetzner - lo único que pierdes son las conversaciones entre el snapshot y ahora, que viven en el volumen de memoria del agente.

Lo que se rompe tarde o temprano

Una lista corta y honesta:

Caídas de long-polling de Telegram en cortes de red largos. La mayoría de runtimes reconectan solos, pero si el tuyo no, el ping de uptime es el que avisa.
docker compose pull introduce un cambio incompatible de config. Fija el tag de la imagen a una versión concreta en producción en lugar de :latest.
El proveedor del modelo te limita y el agente deja de responder sin error obvio. Registra siempre el HTTP status del proveedor y prefiere proveedores con panel de uso.
Se llena el disco porque una skill escribe en /tmp sin rotación. du -sh /* y docker system df deben formar parte de tu memoria muscular de debugging.
Olvidas la regla del firewall al añadir un segundo servicio. Los dos firewalls (Cloud + UFW) necesitan el nuevo puerto, o pierdes 20 minutos depurando "connection refused" desde la dirección correcta.

Ninguna es específica de Hetzner. Son el impuesto de ejecutar cualquier cosa tú mismo.

Cuando las cuentas del VPS dejan de cuadrar

Si estás leyendo esto y los pasos de arriba te parecen interesantes - genial, este es exactamente el flujo de trabajo para el que Hetzner es bueno. Barato, rápido, transparente.

Si te parecen un impuesto sobre un fin de semana, la comparativa cambia. El hosting gestionado cambia 4 €/mes y una tarde de domingo por una configuración que ya incluye la pasarela de Telegram, BYOK con tu proveedor, volúmenes de memoria persistente, snapshots y "simplemente sigue arriba". Nuestra guía hosting vs self-hosting repasa las cuentas completas, incluido cuánto vale tu tiempo.

Empieza con Hermify si quieres el camino gestionado - un agente sobre infraestructura de producción en menos de 30 minutos, sin Cloud Firewall que configurar ni fail2ban que afinar. Si prefieres hacerlo tú mismo en Hetzner, esta guía debería llevarte hasta ahí.