Por qué tener tu propio VPS: el caso de estudio de HosT.ia (agentes IA 24/7 por pocos euros)

La trampa del todo-en-la-nube SaaS

El día que decidimos montar HosT.ia nos dimos cuenta de que la industria nos tenía secuestrados por la nube SaaS. Cada tarea que queríamos automatizar con IA se traducía en una suscripción: un dashboard cuesta 20 euros, un webhook en otro panel otros 15, un scraper en el plan del proveedor otros 40, y la monitorización ya ni te digo. Al cabo de tres meses sumábamos cientos de euros al mes y, aun así, las piezas no se hablaban entre sí.

El problema no es el precio de cada SaaS en abstracto: es el modelo. Pagas la caja negra de otro y el día que necesitas un flujo tuyo, algo tan acertado como un agente que a las tres de la madrugada vigile si tu competidor bajó el precio o un watchdog que avise por email cuando un proceso se cuelga, las plataformas cerradas no te dejan. O te encorsetan en su plan, o te cambian la API sin avisarte. El coste real no está en la factura, está en la imposibilidad de hacer lo que tu negocio necesita.

La vuelta de tuerca fue cambiar de mentalidad: en lugar de alquilar mil productos de nube, alquila una máquina barata y pon en ella tu infraestructura. Por lo que costaba un dashboard fácil teníamos un VPS ARM64 de Hetzner con Node.js, un gateway de agentes, Ollama con modelos locales, Tailscale para el túnel y cron para las rutinas. Propio, abierto a nuestras necesidades y encendido 24/7. Este post es ese caso de estudio con números reales.

• un SaaS: precio por pieza, caja negra y coste que se duplica al sumar más suscripciones.
• Un solo VPS propio reemplaza varias suscripciones por la factura de una máquina al mes.
• La clave es la propiedad: control total, mantenible y con todo el stack integrado.

Cuánto cuesta tu propio VPS frente al SaaS: la tabla real

Antes de defender el VPS con palabras, mejor con la calculadora. Comparamos una infra de agentes típica de una pyme: monitorización 24/7 con aviso por email, un scraper de precios diario, un agente que genera un informe cada noche y un webhook que exponemos a un cliente. La columna SaaS asume las herramientas de mercado para cada pieza; la columna VPS asume un Hetzner CX ARM64 de unos cuatro euros al mes con todo el software del stack instalado una sola vez.

La tabla es honesta: no incluye tu tiempo. El VPS cuesta muy poco de hardware pero exige unas horas para montarlo y mantenerlo. El SaaS te lo precuece en diez minutos pero te sangra todos los meses y no es tuyo. Esa es la frontera real entre un producto pre-cocinado y una máquina con tu nombre. Y un agente que trabaje 24/7 no necesita un panel bonito: necesita que la infra nunca duerma, y eso lo da el VPS por el precio de una suscripción mínima de SaaS.

• El VPS se paga solo: el ahorro frente al SaaS supera al coste de la máquina tras el primer mes.
• No lo cuentas solo en euros, también ganas libertad para hacer lo que quieras con el stack.
• Lo que nunca pagas con un VPS propio es el lock-in de las APIs del SaaS.

Por qué ARM64 y por qué un plan small es suficiente

Cuando elegimos máquina, la tentación era pedir el servidor más grande. Error. Un agente que trabajar 24/7 casi nunca necesita potencia de mainframe: necesita RAM para tener el modelo en memoria y ser predecible. Los VPS de Hetzner de la serie Cx soportan ARM64, y esa arquitectura ofrece una rentabilidad por euro brutal frente a las x86 equivalentes: consumen menos, cuestan menos y para carga de agente van sobrados.

Y sobre el modelo local: no necesitas una GPU de mil euros. En HosT.ia no intentamos correr un modelo de 70.000 millones de parámetros; usamos Ollama con un qwen3 cuantizado (8B, o incluso 4B si la instancia es más justa). Ese modelo cabe en 4-8 GB de RAM y da toda la curva de un flujo de agente sin depender de un servidor remoto. Para resumir un correo, extraer campos de un log o decidir si hay que alertar, un 8B cuantizado es más que suficiente.

La ventaja de ARM se nota todo en el bolsillo. Las instancias ARM de Hetzner salen más baratas por la misma RAM que sus hermanas x86. Para un node y un gateway de agentes el cómputo es ligero en CPU y pesado en memoria, justo el perfil donde ARM gana en equilibrio de coste.

• Un 8B cuantizado con Ollama corre en 4-8 GB de RAM: no hace falta GPU ni servidor grande.
• Las instancias ARM de Hetzner son más baratas por RAM que las equivalentes x86.
• Carga de agente: CPU ligera y RAM priorizada; el equilibrio te sale barato.

El stack completo que corre en el VPS y cómo se conecta

Este es el corazón del post: la pila real que montamos y mantenemos. No es un montaje de demostración, es lo que está detrás de varios agentes automatizando tareas en HosT.ia las 24 horas. Lo importante no es juntar herramientas, es saber para qué sirve cada una y cómo encaja con la siguiente.

Node.js y Express son el servidor HTTP y el bus. Casi toda la lógica interna pasa por Express, que expone las rutas de los endpoint, recibe los webhooks y sirve la salida de los scraper y los informes. Encima corre el gateway de agentes (nuestra capa OpenClaw/Hermes) que orquesta las tareas: recibe la petición, decide el modelo, llama a las tools y devuelve el resultado. Debajo, Ollama sirve qwen3 de forma local para que la respuesta no salga de la máquina cuando queremos privacidad y cero latencia.

De fuera hacia dentro, la entrada es un cristal: nginx hace reverse proxy sobre Express para no exponer Node directo al público. El acceso administrativo va por Tailscale encriptado, que no exporta puertos públicos y te deja conectar tú y tu equipo desde cualquier lugar como si fueras en la misma LAN. Los procesos viven con systemd (aunque PM2 también vale) para que si uno se cuelga el sistema lo reinicie solo. Abajo te dejo el código real del despliegue.

• Express es el servidor y el bus; el gateway (OpenClaw/Hermes) orquesta los agentes.
• Ollama/qwen3 local para tareas offline sin que los datos salgan de la máquina.
• nginx expone solo lo necesario y Tailscale esconde el resto: única puerta de entrada.
• PM2 o systemd: orquestan los procesos y se encargan del auto-reinicio.

El código real: pnpm, systemctl y cron en un VPS

Como es build in public, compartimos lo que realmente ejecutamos. Usamos pnpm porque gestiona mejor el grafo de dependencias de nuestro monorepo de agentes; systemd levanta los servicios al arrancar y cron dispara las tareas de calendario. Esto está adaptado de nuestro despliegue real, con los comandos que no nos fallan.

• pnpm en vez de npm: más rápido y limpio con un monorepo de varios agentes.
• systemd arranca y reinicia los servicios; si el agente se cuelga, vuelve a subir solo.
• cron dispara las rutinas diarias con logs separados para saber qué pasó cada noche.
• Todo como servicio, nada de nohup sueltos o procesos que se pierden.

sudo apt update && sudo apt upgrade -y

sudo apt install -y nodejs git
curl -fsSL https://get.pnpm.io/install.sh | sh -

git clone [email protected]:usuario/mi-repo-agentes.git && cd mi-repo-agentes
pnpm install

curl -fsSL https://ollama.com/install.sh | sh
ollama pull qwen3:8b

sudo systemctl enable --now mi-agente.service

crontab -e
*/5 * * * * cd /srv/agentes && node watchdog.js >> /var/log/watch.log 2>&1
0 2 * * *  cd /srv/agentes && node informe-diario.js >> /var/log/diario.log 2>&1
0 4 * * *  cd /srv/agentes && node scraper-precios.js >> /var/log/scrape.log 2>&1

Casos de uso replicables: watchdog, cron, scraper y webhooks

Lo que de verdad convierte a un VPS en infraestructura es cuando le das trabajo real. Estos son los casos que tenemos por ahí en HosT.ia y cada uno es una necesidad viva que un SaaS caro no resolvía bien.

Watchdog por email: un script que revisa cada pocos minutos que los servicios y el cron hayan corrido; si un proceso se queda dormido o un lock se atasca, te suena una alerta por correo en menos de un primo. La base para dormir tranquilo.

Agentes diarios por la sección: por la noche un agente revisa la actividad, genera un informe, limpia los logs o actualiza los precios, y por la mañana tienes todo servido y nada que lanzar a mano.

Webhooks para cliente: Express expone endpoint (no un servicio webhook con lo de una tarifa) que recibe una señal cuando un proceso termina y dispara al agente. El resultado es un cierre de bucle real entre tu infra y tu negocio.

Monitorización 24/7: juntando scraper, cheque de uptime y el watchdog revisamos en un informe semanal el estado de todos nuestrosservicios, sin depender de un panel de terceros.

El cielo de software de José: orquestación ligera sobre cron

Un momento de build in public honesto: al principio cada agente vivía en una carpeta con su propio reinicio de procesos. Con seis de ellos a la vez, se volvió un lío de estados. La solución de Jos, el responsable de infraestructura, fue montar una capa de orquestación ligera: un mapa central que declara cada tarea, quién la dispara, con qué periodo y dónde deja su log. No hace falta un Airflow gigante para esto.

Jos lo llama el cielo de software de la infra: un solo origen de verdad que recorre por una carpeta de tareas declaradas y lanza según la hora y el estado. Es software sencillísimo, mantenido en un repositorio y que le costó una tarde larga. El valor no está en el framework, está en declarar el trabajo que se repite y dejar que la cronología lo ejecute.

• Un scheduler declarativo evita tener veinte crontab sueltos sin rastro de quién corre qué.
• Cada tarea registra periodo, dependencia y log, formando un mapa del estado de toda tu infra.
• El valor está en la declaración, no complicarse con un orquestador gigante cuando no toca.

La visión HosT.ia: cada negocio con su infra de agentes por pocos euros

Aquí entra la visión que nos mueve: no queremos que exista solo para técnicos. Cualquier negocio, desde el autónomo hasta la pyme, debería poder montar su propia infraestructura de agentes por unos pocos euros al mes, sin depender de un SaaS caro ni de una boutique de consultora. La tabla de costes lo demues: el hardware no es el cuello en botella, es el tiempo y el conocimiento para montarlo.

HosT.ia existe para bajar ese suelo. Montamos nosotros el stack completo (VPS, gateway, modelo, cron y seguridad) y tú solo decides qué quieres automatizar. Tú conservas la propiedad, los datos y, lo más importante, una infraestructura que nadie te puede quitar ni cerrarte.

El resultado práctico: no vendemos una suscripción a una caja negra, entregamos un VPS tuyo con su llave SSH donde ya viven tus agentes y tus automatizaciones, y el coste recurrente no es una tarifa por módulo, sino la máquina. Es decir, la infra ayuda de agentes se posee, y eso es el futuro que pedimos.

• Que cualquier pyme tenga infra de agentes propia por debajo de los 10 euros al mes.
• HosT.ia monta el stack, tú decides qué automatizar y conservas propiedad y llave.
• Cobramos por montar y mantener, no por alquilar un módulo encerrado.

Seguridad básica: SSH por llave, UFW, Tailscale y actualización

Tener un VPS propio no significa exponerse: significa que controlar la puerta de entrada. Aplicamos una base mínima de seguridad en todas las instalaciones, y son cuatro balas tan simples que cualquiera las puede aplicar, no hace falta ser un experto.

Primero, acceso SSH solo por llave pública y se desactiva la entrada por contraseña del usuario que no necesitemos. Segundo, un firewall (UFW) que solo abre lo mínimo: el puerto 22 limitado por IP de tu casa, y 80/443 para nginx. Tercero, el acceso administrativo va por Tailscale (SSH) sobre el túnel para no exponer herramientas de admin a toda internet. Y cuarto, activamos las actualizaciones automáticas de seguridad.

La parte más sorprendente es esta: con Tailscale, el VPS ni se ve excepto para el que esté en tu red. No hay puertos de base de datos abiertos, no hay MySQL a la calle, no hay panel de administración pública. Casi toda la superficie de ataque desaparece por el propio diseño, sin ir persiguiendo exploits.

• SSH por llave y sin contraseña de root: no hay puerta sin cerradura.
• UFW solo abre lo necesario: el 80/443 y la IP de tu casa para SSH.
• Tailscale esconde la administración: solo se ve quien está en tu red.
• Actualizaciones de seguridad automáticas para que la máquina no se quede vieja.

Cuándo NO tener un VPS: las limitaciones honestas

Si dejamos el post en euforia no seríamos honestos. Un VPS no es para todo el mundo, y saber tu territorio te ahorra el dolor de cabeza. Primera limitación: si tu proyecto no se adapta para mantener una máquina, por pequeño que sea el esfuerzo, mejor no. Un VPS olvidado sin parches es un riesgo, y hay negocios mejor pagar por el mantenimiento.

Segunda: no da una alta disponibilidad por diseño, hay un punto único de fallo. Si tu servicio necesita SLA de nunca bajar, replicación real y un equipo de guardia para las 24 horas, un solo VPS no corresponde; ahí hace falta un clúster o una nube gestionada.

Tercera: si lo usas un mes y luego lo abandonas, no no paga la curva de aprendizaje. Y cuarta: si necesitas modelos enormes y GPU continua (entrenamiento, visión pesada), un VPS de 4 GB no es la herramienta, es territorio de nube de GPU.

En breve: el VPS gana en automatización constante, tareas planificadas y volumen de datos contenido; la nube SaaS tiene sentido para el SLA bancario y lo de modelo exigente. En lugar de defensa: el territorio.

• Un VPS abandonado sin parches es un riesgo: no lo tengas si no lo vas a mantener.
• No hay alta disponibilidad por sí: para misión crítica, mejor clúster o SaaS.
• Modelos enormes o GPU continua no son territorio de un VPS de 4 GB.
• El uso de una sola vez al mes no paga el coste de aprender.

Cómo empezar: la hoja de ruta en diez pasos

Si te convence la idea, esta es la secuencia concreta que recomendamos y que nosotros seguimos. El orden importa: primero la seguridad, luego el que runtime, luego el modelo y por último las cargas. Así, si un agente falla, sabes si es del modelo o de la máquina sin tocarlo todo.

• Elige un Hetzner ARM64 con 4-8 GB y contrata el plan small/medium.
• Desactiva el usuario root de SSH y añade tu llave con ssh-copy-id.
• Instala Node 20, pnpm y activa las actualizaciones automáticas.
• Instala ollama y descarga qwen3:8b; comprueba que tienes RAM suficiente.
• Clona el repo y haz el setup, con Express escuchando y el nginx como proxy inverso.
• Activa UFW para no exponer puertos de más.
• Instala Tailscale y conéctate, tu acceso de admin privado ya está hecho.
• Define tus servicios en systemd (o PM2) y abre el primer agente.
• Escribe un cron de watchdog y una alp por email de prueba.
• Crea la primera tarea de tu agente real y déjalo corriendo desatendido.

Preguntas frecuentes sobre tener tu propio VPS

Terminamos con las dudas más escuchadas cuando clientes plantean pasar sus agentes a infra propia. Respuestas cortas, directas y sin humo.

Preguntas frecuentes