Autoalojar aplicaciones en un VPS: arquitectura, uso de RAM y por dónde empezar

Tienes un VPS. Quizá lo acabas de conseguir, o quizá ya tienes algunos servicios corriendo y quieres hacer más. En cualquier caso, la pregunta es la misma: ¿qué puedo ejecutar en él y va a caber?

Esta guía responde a eso. Cubre la arquitectura de un stack de aplicaciones autoalojadas, proporciona datos reales de consumo de memoria medidos en un VPS de 4 vCPU/8 GB y ofrece una matriz de decisión para elegir tu primera (o siguiente) aplicación. Requisitos previos: Esta guía asume que ya tienes Docker y un reverse proxy funcionando. Si no, empieza con Docker en producción en un VPS: qué falla y cómo solucionarlo para instalar Docker, Docker Compose y Caddy o Traefik en Debian 12 o Ubuntu 24.04. Para los fundamentos de Docker Compose, consulta [-> docker-compose-multi-service-vps].

¿Por qué autoalojar en un VPS en lugar de un homelab?

Un VPS te da hosting siempre disponible con una dirección IPv4 pública, sin CGNAT, sin factura de luz y sin hardware que mantener. Las snapshots gestionadas por el proveedor se encargan de la recuperación ante desastres. Un VPS de 4 vCPU/8 GB ejecuta de 5 a 8 aplicaciones Docker cómodamente por unos pocos euros al mes. Tu internet doméstico se cae; tu VPS no.

Así se compara un VPS con un homelab para autoalojamiento:

Factor	VPS	Homelab
IP pública	Incluida, estática	A menudo detrás de CGNAT. Requiere soluciones con túneles.
Disponibilidad	SLA 99,9 %+, alimentación redundante	Depende de tu ISP y de la red eléctrica
Ancho de banda	Simétrico, típicamente 1 Gbps+	Asimétrico. La subida es el cuello de botella.
Mantenimiento de hardware	Problema del proveedor	Tu problema. Fallos de disco, ruido de ventiladores, calor.
Electricidad	Incluida en el precio	20-60 EUR/año para un servidor pequeño funcionando 24/7
Snapshots/backups	Un clic, gestionados por el proveedor	Tú construyes y pruebas el pipeline de backup
Coste inicial	Desde ~4 EUR/mes	200-500+ EUR para un Mini PC o NAS
Acceso físico	Ninguno. Solo SSH.	Acceso completo. Útil para dispositivos USB, arrays ZFS.

Un homelab tiene sentido si necesitas almacenamiento local (arrays ZFS, NAS), hardware USB (sticks Zigbee, dongles SDR) o quieres aprender administración bare-metal. Para todo lo demás, un VPS es más sencillo y más barato para empezar.

La mayoría de los ISP residenciales ahora usan Carrier-Grade NAT, lo que significa que compartes una IP pública con docenas de otros clientes. No puedes hacer port-forwarding. No puedes recibir conexiones entrantes. Tus aplicaciones autoalojadas son invisibles en internet. Existen soluciones alternativas (Cloudflare Tunnels, relays WireGuard a través de un VPS), pero añaden complejidad y una dependencia de un servicio externo. Un VPS elimina el problema por completo: tienes una IPv4 pública dedicada, controlas el DNS y el tráfico entrante simplemente funciona.

Si quieres ambas cosas, usa un VPS como tu punto de entrada público y un túnel WireGuard hacia tu homelab para servicios privados. Pero para la mayoría de las aplicaciones autoalojadas, un VPS solo es suficiente.

¿Cómo es un stack de aplicaciones autoalojadas?

Un stack autoalojado en un VPS sigue una arquitectura en capas: un reverse proxy se sitúa delante, enrutando el tráfico HTTPS hacia los contenedores de aplicación. Cada app se conecta a su propia base de datos (o usa SQLite integrado). Una capa de backup crea snapshots según un calendario.

Internet
  │
  ▼
┌─────────────────────────────┐
│  Reverse Proxy (Caddy)      │  Port 443 ← only public port
│  TLS termination + routing  │
└──────┬──────┬──────┬────────┘
       │      │      │
       ▼      ▼      ▼
    ┌─────┐ ┌─────┐ ┌─────┐
    │App 1│ │App 2│ │App 3│    Docker containers
    └──┬──┘ └──┬──┘ └──┬──┘
       │      │      │
       ▼      ▼      ▼
    ┌─────┐ ┌─────┐ ┌─────┐
    │ DB  │ │ DB  │ │SQLite│   PostgreSQL, Redis, or embedded
    └─────┘ └─────┘ └─────┘
              │
              ▼
    ┌─────────────────┐
    │  Backup Layer   │        Restic, borgmatic, or provider snapshots
    │  (scheduled)    │
    └─────────────────┘

Decisiones clave:

• Reverse proxy: Caddy provisiona certificados TLS automáticamente sin configuración. Traefik se integra con labels de Docker para auto-descubrimiento. Ambos funcionan. Caddy es más simple para principiantes.
• Base de datos: Muchas apps ligeras (Vaultwarden, Uptime Kuma, Beszel) usan SQLite integrado. No necesitan un contenedor de base de datos separado. Las apps más pesadas (Immich, Plausible, Gitea) necesitan PostgreSQL.
• Backup: Las snapshots del proveedor cubren el disco completo. Para backups a nivel de aplicación, usa Restic o borgmatic hacia un destino offsite (almacenamiento compatible con S3 o un segundo VPS).
• Red: Todos los contenedores de aplicación están en una red Docker interna. Solo el reverse proxy expone los puertos 80 y 443. Las apps nunca se vinculan directamente a interfaces públicas.

Esta arquitectura se detalla en Docker en producción en un VPS: qué falla y cómo solucionarlo.

¿Cuánta RAM usan realmente las aplicaciones autoalojadas?

Menos de lo que piensas. La mayoría de las apps autoalojadas populares consumen menos de 200 MB en reposo. Las excepciones son apps con funcionalidades de machine learning (Immich) o motores de analítica integrados (Plausible con ClickHouse).

Los números a continuación son memoria RSS en reposo/uso ligero obtenidos de docker stats, medidos en un VPS Virtua Cloud de 4 vCPU/8 GB con Debian 12. Los valores pico representan los picos típicos durante el uso activo (subida de fotos, OCR de documentos, ejecución de workflows).

App	Qué reemplaza	RAM en reposo	RAM pico	Almacenamiento/mes	Base de datos
Vaultwarden	Bitwarden, 1Password	~25 MB	~50 MB	Mínimo	SQLite
Uptime Kuma	UptimeRobot, Pingdom	~100 MB	~170 MB	Mínimo	SQLite
Beszel	Datadog (básico)	~50 MB	~80 MB	Mínimo	Integrada
Gitea	GitHub (repos privados)	~150 MB	~300 MB	~50 MB/repo	PostgreSQL o SQLite
n8n	Zapier, Make	~100 MB	~500 MB+	Variable según workflows	PostgreSQL
Paperless-ngx	Archivador de documentos	~300 MB	~1 GB	~5 MB/documento	PostgreSQL + Redis
Nextcloud	Google Drive, Dropbox	~250 MB	~512 MB	Variable según archivos	PostgreSQL + Redis
Coolify	Vercel, Railway	~500 MB	~1,2 GB	Variable según despliegues	PostgreSQL (incluido)
Plausible	Google Analytics	~400 MB	~1,5 GB	~100 MB/1M páginas vistas	PostgreSQL + ClickHouse
Immich	Google Photos	~800 MB	~2,5 GB	~3 GB/1000 fotos	PostgreSQL + Redis

Algunas notas sobre estos números:

• Immich con machine learning (detección de caras/objetos) activado necesita 4-6 GB en total. Los números anteriores son con ML activado pero en reposo. Durante una importación masiva de fotos, espera 3-4 GB. Puedes desactivar ML para bajar a ~400 MB, pero pierdes la búsqueda inteligente y el reconocimiento facial.
• Plausible: la RAM depende del volumen de tráfico. ClickHouse adora la memoria. Para un sitio con menos de 100.000 páginas vistas/mes, los números anteriores se mantienen. Sitios con mucho tráfico necesitan más.
• n8n en reposo es ligero, pero workflows complejos con payloads JSON grandes o integraciones de IA provocan picos importantes. Los workflows de agentes IA pueden consumir 200 MB+ por ejecución.
• Paperless-ngx tiene picos durante el OCR. Establece PAPERLESS_WEBSERVER_WORKERS=1 en Docker para ahorrar ~150 MB si eres el único usuario.

¿Qué aplicación debería autoalojar primero en mi VPS?

Empieza con Vaultwarden. Usa 25 MB de RAM, se despliega en menos de 10 minutos, reemplaza un gestor de contraseñas de pago que usas todos los días y te obliga a configurar TLS correctamente. Esa configuración de TLS (reverse proxy + DNS + certificados) es la base que toda aplicación autoalojada necesita. Una app, tres beneficios: privacidad, ahorro de costes e infraestructura reutilizable.

App	Impacto en privacidad	Complejidad de instalación	SaaS que reemplaza	RAM mín.
Vaultwarden	Muy alto (contraseñas)	Baja (10 min)	Bitwarden/1Password	128 MB
Immich	Alto (fotos personales)	Media (30 min)	Google Photos	2 GB (4 GB con ML)
Paperless-ngx	Alto (documentos, DNIs)	Media (20 min)	Archivador + apps de escaneo	512 MB
Plausible	Medio (analítica de visitantes)	Media-alta (25 min)	Google Analytics	1 GB
Uptime Kuma + Beszel	Bajo (monitoring de infra)	Baja (10 min)	UptimeRobot + Datadog	256 MB
Gitea	Medio (código fuente)	Baja (15 min)	Repos privados de GitHub	256 MB
n8n	Medio (datos de workflows)	Media (20 min)	Zapier, Make	512 MB
Coolify	Bajo (herramienta de despliegue)	Media (20 min)	Vercel, Railway	1 GB

El impacto en la privacidad es la razón más fuerte para autoalojar. Tus contraseñas, fotos y documentos escaneados son los datos más sensibles que manejas a diario. Alojarlos en el servidor de otro significa confiar en su seguridad, su jurisdicción y su continuidad de negocio. En tu propio VPS en Europa, esos datos quedan bajo tu control y bajo el RGPD.

Para tutoriales de cada app, sigue los enlaces al final de esta guía.

¿Qué puedo ejecutar en un VPS de 4 GB vs uno de 8 GB?

Un VPS de 4 GB ejecuta un stack personal sólido. Un VPS de 8 GB maneja todo lo que un desarrollador independiente o un equipo pequeño necesita. Los números a continuación tienen en cuenta el reverse proxy (~30 MB), la sobrecarga de Docker y el propio sistema operativo (~300-400 MB usados).

VPS de 4 GB (~3,2 GB disponibles para apps)

Combinación	RAM total en reposo	Margen
Vaultwarden + Uptime Kuma + Beszel + Gitea	~325 MB	~2,9 GB
Vaultwarden + Paperless-ngx + Uptime Kuma	~425 MB	~2,8 GB
Vaultwarden + n8n + Beszel + Gitea	~325 MB	~2,9 GB
Vaultwarden + Nextcloud + Uptime Kuma	~375 MB	~2,8 GB

Estas combinaciones dejan margen de sobra para picos de uso. Incluso cuando Paperless-ngx sube a 1 GB durante el OCR, queda espacio. Evita Immich con ML o Plausible en 4 GB a menos que sea la única app.

VPS de 8 GB (~7 GB disponibles para apps)

Combinación	RAM total en reposo	Margen
Vaultwarden + Immich + Uptime Kuma + Beszel	~975 MB	~6 GB
Vaultwarden + Plausible + Gitea + Paperless-ngx + Beszel	~925 MB	~6 GB
Vaultwarden + Coolify + Uptime Kuma + n8n	~725 MB	~6,3 GB
Todas las ligeras (Vaultwarden + Gitea + Uptime Kuma + Beszel + n8n + Paperless-ngx)	~725 MB	~6,3 GB

Con 8 GB, puedes ejecutar cómodamente Immich con ML junto a tres o cuatro apps ligeras. También puedes correr Plausible con ClickHouse sin preocuparte por la presión de memoria. Este es el punto óptimo para una configuración de autoalojamiento personal.

La RAM en reposo es sobre lo que planificas, pero los picos son lo que tumba tu servidor. Paperless-ngx tiene picos durante el OCR. Immich tiene picos durante la importación de fotos con clasificación ML. n8n tiene picos al ejecutar workflows con payloads grandes. La columna de margen anterior es tu red de seguridad. Si el margen baja de 1 GB, te arriesgas a que el OOM killer de Linux termine un contenedor en el peor momento posible. Mantén al menos 1,5 GB de margen para cualquier stack que incluya Immich o Plausible.

Para un VPS de Virtua Cloud con 4 vCPU y 8 GB de RAM en almacenamiento NVMe, consulta los planes actuales. La ubicación en Frankfurt sitúa tus datos en la UE bajo la ley alemana de protección de datos.

¿Qué aplicaciones autoalojadas necesitan hosting europeo?

Cualquier app que almacene datos personales se beneficia del hosting europeo bajo el RGPD. Pero algunas apps manejan datos que hacen urgente la cuestión jurisdiccional.

Prioridad alta para hosting en la UE:

• Vaultwarden almacena cada contraseña que tienes. Una brecha aquí es catastrófica. El hosting europeo significa que se aplican los requisitos de notificación de brechas del RGPD.
• Immich contiene fotos personales, a menudo con rostros de miembros de la familia. Los datos de reconocimiento facial son datos biométricos según el Artículo 9 del RGPD. Categoría especial. Protecciones adicionales.
• Paperless-ngx almacena DNIs escaneados, documentos fiscales, contratos. Algunos de los datos personales más sensibles que posees.

Prioridad media:

• Plausible recopila analítica de visitantes. Está diseñado con privacidad por defecto (sin cookies, sin datos personales), pero los datos siguen perteneciendo a tus visitantes.
• Gitea puede contener código fuente propietario. No son datos personales como tales, pero es propiedad intelectual que quieres controlar.
• n8n: los workflows a menudo procesan datos de múltiples servicios. La capa de automatización lo ve todo.

Prioridad menor:

• Uptime Kuma / Beszel almacenan datos de monitorización. Sin datos personales a menos que estés monitorizando endpoints que los contengan.
• Coolify es una herramienta de despliegue. Maneja tu código pero no almacena datos de usuario final.

Si eres una empresa europea o manejas datos de ciudadanos de la UE, alojar estas apps en un VPS en Alemania (u otro país de la UE) simplifica tu cumplimiento del RGPD. Tú controlas los datos. Sabes dónde están. Tú eliges quién tiene acceso.

¿Cómo mantengo mis aplicaciones autoalojadas seguras y actualizadas?

Autoalojar significa que tú eres el administrador de sistemas. Ese es el precio del control. Estas son las prácticas innegociables:

Firewall primero. Antes de desplegar cualquier app, configura ufw para permitir solo SSH (puerto 22) y HTTPS (puerto 443). Bloquea todo lo demás. Esto se cubre en Docker en producción en un VPS: qué falla y cómo solucionarlo.

TLS en todas partes. Tu reverse proxy (Caddy o Traefik) se encarga de la terminación TLS. Cada app obtiene HTTPS. Sin excepciones. Nada de «añadiré TLS después». Caddy provisiona certificados de Let's Encrypt automáticamente.

Actualizaciones. Comprueba las actualizaciones de imágenes de contenedor semanalmente. Descarga las nuevas imágenes, recrea los contenedores:

docker compose pull
docker compose up -d

Para actualizaciones de seguridad críticas (Vaultwarden, cualquier app expuesta a internet), suscríbete a las releases de GitHub del proyecto o al feed RSS. Releases de Vaultwarden e Releases de Immich son buenos ejemplos.

Backups. Pruébalos. Un backup que nunca has restaurado no es un backup. Usa snapshots del proveedor para la recuperación completa del disco y Restic o borgmatic para backups offsite a nivel de aplicación. Prográmalos con cron o un timer de systemd. Veríficalos mensualmente.

Gestión de secretos. Nunca escribas contraseñas directamente en docker-compose.yml. Usa un archivo .env con chmod 600:

openssl rand -base64 32 > /dev/null  # example: generate a strong password

# docker-compose.yml
services:
  app:
    env_file: .env

# .env (chmod 600, owned by root)
DB_PASSWORD=<generated-password>
SECRET_KEY=<generated-key>

Monitorización. Ejecuta Uptime Kuma para comprobaciones de endpoints externos y Beszel para métricas a nivel de contenedor (CPU, RAM, disco por contenedor). Ambos son ligeros y te dan visibilidad antes de que los problemas se conviertan en caídas. Ver Auto-alojar Uptime Kuma y Beszel en un VPS con Docker Compose.

Conocimiento de los logs. Sabe dónde están tus logs. Los contenedores Docker envían logs a stdout por defecto. Consúltalos con:

docker compose logs -f --tail=50 <service-name>

Para servicios a nivel de sistema (el reverse proxy si corre de forma nativa, SSH, firewall), usa journalctl:

journalctl -u caddy -f

Cuando algo se rompe, los logs son tu primera parada. No Stack Overflow. No Reddit. Los logs.

¿Qué viene después?

Cada app de la matriz de decisión anterior tiene un tutorial dedicado con configuraciones completas de Docker Compose, configuración de reverse proxy, backups y hardening:

App	Tutorial
Vaultwarden (contraseñas)	Autoalojar Vaultwarden en un VPS con Docker Compose
Immich (fotos)	Autoalojar Immich en un VPS con Docker Compose
Plausible (analítica)	Autoalojar Plausible Analytics en un VPS con Docker Compose
Uptime Kuma + Beszel (monitorización)	Auto-alojar Uptime Kuma y Beszel en un VPS con Docker Compose
Coolify vs Dokploy (PaaS)	Coolify vs Dokploy: ¿cuál PaaS autoalojado para tu VPS?
Paperless-ngx (documentos)	Autoalojar Paperless-ngx en un VPS con Docker Compose
Gitea (hosting Git)	Auto-alojar Gitea en un VPS con Docker Compose

Si aún no has configurado Docker y un reverse proxy, empieza aquí: Docker en producción en un VPS: qué falla y cómo solucionarlo. Esa guía cubre Debian 12 y Ubuntu 24.04, instala Docker con Compose, configura Caddy como reverse proxy con TLS automático, establece un firewall y crea un usuario de despliegue sin privilegios de root. Todo en esta guía se construye sobre esa base.