Self-hosting de herramientas de IA en un VPS: guía realista 2026
Cuánta memoria consume de verdad cada servicio, qué VPS necesitas, y los tres errores de seguridad que se cometen el primer día. Con datos medidos.
- Autor
- Dani
- Publicado
- Lectura
- 8 min · 1635 palabras
Casi toda la documentación sobre autoalojar herramientas dice lo mismo: “requisitos mínimos, 2 GB de RAM”. Luego montas cuatro servicios, la base de datos empieza a tener datos de verdad, y el servidor se queda sin memoria un martes a las tres de la mañana.
Esta guía va de los números reales. Cuánto consume cada cosa medido sobre una máquina en funcionamiento, qué VPS necesitas de verdad, y los tres errores que se cometen el primer día y se pagan meses después.
Qué consume cada servicio de verdad
El dato que no publica casi nadie. Esto está medido con docker stats sobre servicios
en reposo —arrancados y sin tráfico—, no copiado de la documentación de cada proyecto:
Memoria real en reposo, medida con docker stats
Fig. 01
Ver los datos como tabla
| Servicio | MB |
|---|---|
| Gestor de contraseñas (Vaultwarden) | 11 |
| Base de datos Postgres (en reposo) | 20 |
| Monitor de caídas (Uptime Kuma) | 102 |
| Panel de métricas (Netdata) | 272 |
| Orquestador de flujos (n8n) | 283 |
| Total en reposo | 688 |
Datos propios
Tres cosas se ven aquí que cambian cómo eliges el servidor.
Los servicios ligeros son increíblemente ligeros. Un gestor de contraseñas completo ocupa 11 MB. Una base de datos Postgres en reposo, 20. Si tu idea de autoalojar es “necesito un servidor potente”, el coste no viene de estos.
Los paneles cuestan más que lo que vigilan. El monitor de métricas consume 272 MB: más que el orquestador de flujos al que vigila. Es el patrón general de la observabilidad, y la decisión práctica es si esa información te vale lo que ocupa. En una máquina de 4 GB, sí; en una de 1 GB, es lo primero que quitas.
El reposo no es el problema. Los cinco juntos se quedan en 1,6 GB sin tráfico. Lo que tira un servidor abajo es la base de datos cuando crece, o un proceso que se come la memoria al procesar algo grande. El presupuesto hay que hacerlo sobre el pico, no sobre el reposo.
Qué VPS necesitas
Con esos números, la regla práctica:
| Memoria | Para qué sirve de verdad |
|---|---|
| 1 GB | Un servicio ligero y nada más. Sin panel de métricas |
| 2 GB | Dos o tres servicios ligeros. Se queda corto en cuanto añades una base de datos con uso real |
| 4 GB | El punto de partida sensato. Cuatro o cinco servicios con holgura para picos |
| 8 GB | Si vas a tener bases de datos con datos de verdad, o modelos pequeños en local |
Dos avisos sobre la letra pequeña que casi nadie mira al comparar precios.
El disco importa más de lo que parece. Las imágenes de contenedor pesan. Cinco servicios con sus imágenes, volúmenes y copias de seguridad se comen 20 o 30 GB sin esfuerzo. Un VPS con 20 GB de disco se llena antes de que te quedes sin memoria.
El precio de renovación casi nunca es el de contratación. Las ofertas de alojamiento se anuncian a tres o cuatro años pagados por adelantado, y la renovación puede ser el triple. No es una trampa oculta —está en las condiciones— pero conviene mirar el coste a cuatro años y no el del primer mes. Puedes comparar los planes de Hostinger o de cualquier otro proveedor con ese criterio en la mano.
Los tres errores del primer día
1. Publicar el servicio entero para exponer una sola ruta
Este es el caro. Necesitas que un formulario de tu web llegue a tu orquestador de flujos, montas un túnel rápido apuntando al servicio y funciona en treinta segundos.
Lo que acabas de publicar en internet no es tu webhook: es el editor completo, su API interna y todos tus flujos con las credenciales dentro. Cualquiera con la URL entra. Y si el túnel genera una dirección nueva en cada reinicio, además tienes una integración que se rompe sola.
Lo correcto cuesta una tarde: un túnel con nombre, DNS fijo, y una regla que publique solo la ruta que necesitas, dejando el panel de administración accesible únicamente desde la red local o una VPN. El razonamiento completo sobre separar lo que se publica de lo que se administra está en la guía para automatizar tareas con n8n y un LLM.
2. Dejar los puertos escuchando en todas las interfaces
Al levantar un contenedor con -p 5678:5678, ese puerto queda escuchando en todas
las interfaces de red, incluida la pública. El servicio que creías accesible solo desde
tu máquina está en internet.
La forma correcta es anclar la publicación a la interfaz local —-p 127.0.0.1:5678:5678—
y poner delante un proxy inverso o un túnel que decida qué sale fuera. Es un cambio de
un carácter en la configuración y es la diferencia entre un servicio privado y uno
público.
3. Confundir volumen con copia de seguridad
Un volumen de Docker sobrevive a que reinicies o recrees el contenedor. No sobrevive a que borres el volumen, a que el disco falle, ni a que un comando mal escrito se lo lleve. No es una copia de seguridad: es almacenamiento.
Una copia de seguridad de verdad cumple tres condiciones: está fuera de esa máquina, se hace sin que tengas que acordarte, y la has restaurado al menos una vez. La tercera es la que casi nadie cumple, y es la única que demuestra que las otras dos funcionan. Una copia que nunca has restaurado es una suposición.
El coste que nadie cuenta: las actualizaciones
El precio del VPS es la parte fácil de calcular. La parte difícil es que cada servicio que autoalojas es software que hay que actualizar, y nadie lo va a hacer por ti.
Esto no es una molestia teórica. Un orquestador de flujos con una vulnerabilidad sin parchear y el panel publicado en internet es una puerta abierta con tus credenciales dentro. Y las actualizaciones de servicios con base de datos a veces incluyen migraciones de esquema que no se pueden deshacer.
El procedimiento que funciona tiene tres pasos y conviene no saltarse ninguno:
- Copia antes de actualizar, siempre. No la copia programada de anoche: una copia de ahora mismo, antes de tocar nada. Si la migración sale mal, esa es la única vía de vuelta.
- Lee las notas de la versión, no solo el número. Un salto de versión mayor suele traer cambios que rompen. El número de versión te dice que hay algo nuevo; las notas te dicen si vas a pasar la tarde arreglándolo.
- Actualiza un servicio a la vez. Si actualizas cuatro y algo se rompe, tienes cuatro sospechosos y ninguna pista.
Lo que sí se puede automatizar es el aviso, no el cambio. Un comprobador que te diga “hay versión nueva de estos tres servicios” es útil y seguro. Un actualizador automático que aplique los cambios solo, en servicios con estado, acaba el día que una migración falle a las cuatro de la mañana sin nadie mirando. Es el mismo criterio que aplico a cualquier automatización: la máquina propone, la persona decide lo irreversible.
Calcula entre media hora y una hora al mes por cada servicio que mantengas. Con cinco servicios son unas cuatro horas mensuales. Si tu tiempo vale algo, mete esa cifra en la comparación antes de decidir que autoalojar sale más barato que pagar una suscripción.
Qué no autoalojar
Hay una parte de la conversación que se evita, así que la digo: autoalojar no siempre gana.
Los modelos de lenguaje grandes, en general no. Un modelo pequeño corre en una máquina modesta, pero la diferencia de calidad con los modelos por API es enorme y el coste por token de la API es bajo. La comparación la desarrollé en la comparativa de Claude y ChatGPT para empresas: para la mayoría de usos, pagar por llamada sale más barato que mantener hardware ocioso.
El correo, casi nunca. Un servidor de correo propio es la cosa más difícil de mantener con buena reputación de entrega. Se puede, pero el día que tus correos empiecen a llegar a spam tendrás un problema que no sabrás diagnosticar.
Nada cuyo tiempo de caída te duela y no puedas atender. Si el servicio se cae un domingo y eso te cuesta clientes, lo que necesitas no es autoalojarlo: es que alguien tenga guardia. Autoalojar traslada el ahorro a tu tiempo, y tu tiempo no es gratis.
Por dónde empezar
Monta un servicio. El que más uses, no el que más ilusión te haga. Déjalo una semana y mira tres cosas: si la memoria sube con el uso, si las copias de seguridad se hacen de verdad, y si puedes restaurarlo en una máquina nueva.
Si esas tres funcionan, añade el siguiente. Si no, arréglalas antes de añadir nada: cada servicio que apilas sobre una base que no sabes restaurar multiplica lo que pierdes el día que algo falle.
Autoalojar no es más barato. Es más tuyo. Eso vale mucho, pero hay que saber qué se está comprando.