Dimensionado de un servidor multidominio con reverse proxy

Introducción

Escenario habitual: un único servidor Ubuntu con Nginx como frontal, sirviendo varios dominios independientes sobre la misma IP pública (un server{} por dominio, HTTPS con certificado propio vía Let's Encrypt/Certbot y renovación automática), con estructura separada por dominio (/var/www/<dominio>/...) y, en algunos de esos dominios o subdominios, un reverse proxy hacia microservicios internos (típicamente FastAPI/Python). Solo 80/443 expuestos al público; el resto de puertos cerrados salvo necesidad concreta.

Es una configuración estándar y muy repetible, pero el dimensionado de la máquina no siempre es intuitivo: la tentación es mirar solo el número de dominios, cuando en la práctica el consumo real depende sobre todo de cuántos procesos de microservicio conviven a la vez.

Resumen rápido

Lo que más pesa no es la CPU, es la RAM — cada proceso de microservicio Python vive en memoria de forma permanente.
Mínimo razonable para varios dominios + un puñado de microservicios con margen real: 2 vCPU / 8 GB RAM / 80 GB SSD.
Recomendado si se prevé crecer (más dominios, más servicios) sin redimensionar a corto plazo: 4 vCPU / 16 GB RAM / 160 GB SSD.
Con un único microservicio muy ligero y sin stack de seguridad completo, se puede ir bastante más bajo — ver la referencia real de producción más abajo.

1. Configuraciones de partida

Mínimo razonable

Para arrancar ya, con margen real

vCPU2

RAM8 GB

Disco SSD80 GB

Cómodo para 1–4 dominios estáticos + 1–3 microservicios ligeros, con el stack de seguridad estándar (§4) corriendo de fondo.

Recomendada

Para crecer sin redimensionar a corto plazo

vCPU4

RAM16 GB

Disco SSD160 GB

Margen hasta ~10 dominios + 6–8 microservicios ligeros sin tocar la máquina. La opción por defecto si la idea es ir añadiendo dominios/servicios con el tiempo.

2. Por qué manda la RAM y no la CPU

Nginx sirviendo estático y haciendo de proxy es barato en CPU y en RAM, incluso con TLS de por medio. El coste real está en los procesos Python: un worker (uvicorn/gunicorn) de una API ligera suele ocupar entre 100 y 250 MB en reposo según dependencias (Pydantic, SQLAlchemy, clientes HTTP…), y ese consumo es permanente mientras el proceso vive — a diferencia de Nginx, que solo tira de recursos bajo demanda. Con 5–8 microservicios activos a la vez, eso ya son 1–2 GB solo en procesos Python, antes de contar sistema operativo, Nginx y el stack de seguridad.

Vigilar aparte Si alguno de los servicios hace trabajo pesado de CPU en vez de ser puramente I/O — por ejemplo firma electrónica avanzada (XAdES o similar), generación o compresión de PDF, procesado de imágenes, u otro cálculo intensivo — ese servicio concreto puede justificar subir vCPU de forma independiente, sin importar en qué tramo de la tabla se esté por lo demás.

Referencia real de producción — el otro extremo Un servidor con 2 vCPU / 2 GB RAM / 60 GB SSD lleva funcionando de forma estable desde hace meses con dos microservicios Python muy ligeros (generación de códigos y un acortador/redirector de URLs), cada uno con varios workers en paralelo. Uso real observado: en torno a 800 MB de RAM ocupados sobre 1,9 GB disponibles — margen cómodo. La diferencia con el escenario de este documento: esa máquina no sirve varios dominios ni lleva el stack de seguridad completo (sin Fail2Ban ni ClamAV). Es la prueba de que, con muy poca carga y sin ese stack, se puede ir mucho más ajustado que los 8 GB recomendados como suelo en §1 — pero no es una comparación directa.

3. Tabla de escalado orientativa

Horquilla aproximada, no una regla exacta. Pensada para microservicios «ligeros» (APIs CRUD, integraciones, formularios) sin base de datos pesada propia ni procesamiento intensivo.

Escenario	Dominios estáticos	Microservicios	vCPU	RAM	Disco SSD
Solo microservicioreferencia real, sin stack de seguridad completo	0–1	1–2 muy ligeros	`2`	`2 GB`	`60 GB`
Arranque	1–3	0–1 ligero	`2`	`8 GB`	`60 GB`
Mínimo recomendadopunto de partida real con seguridad completa	1–4	1–3 ligeros	`2`	`8 GB`	`80 GB`
Estándar con margenrecomendada para crecer	4–10	4–8 ligeros	`4`	`16 GB`	`160 GB`
Crecimiento sostenido	10–20	8–15 ligeros	`6`	`24–32 GB`	`240 GB`
Carga alta / servicios con estadoBD local, colas, más tráfico	>20	>15, o alguno con CPU/BD propia	`8+`	`32 GB+`	`300 GB+`

Disco Presupuestar ~1–2 GB por microservicio (código + entorno virtual + logs) y bastante menos por dominio estático salvo que sirva media pesada. El margen extra en disco es barato comparado con RAM/CPU — mejor pasarse aquí que quedarse corto.

4. Seguridad, firewall y backups desde el arranque

Con la máquina en marcha, este es el mínimo que aplicamos por defecto en cualquier servidor Ubuntu con exposición pública, no solo en el escenario multidominio:

Firewall

Doble capa: firewall a nivel de proveedor/hosting (por delante de la máquina) + ufw en el propio servidor. Solo 22/80/443 abiertos al público; el resto cerrado salvo necesidad concreta.
SSH solo con clave (sin password), PermitRootLogin no explícito en sshd_config, y Fail2Ban con jail para SSH desde el primer día.

Nginx / TLS

Un server{} por dominio, certificado Let's Encrypt independiente por dominio vía Certbot, renovación automática por el timer de systemd que instala el propio paquete (sin cron manual).
Alerta si un certificado no renueva — mejor detectarlo antes de que caduque que por aviso del cliente final.

Reverse proxy a microservicios

Cada microservicio como su propio servicio systemd (no nohup/screen), arranque automático y reinicio ante fallo. Usuario Unix dedicado (no root) por servicio o al menos un usuario de despliegue sin privilegios.
limit_req por ubicación en las rutas de API expuestas, para no quedar abierto a abuso desde el minuto uno.

Stack base y monitorización

Postfix (envío de alertas), Fail2Ban, ClamAV y rkhunter como paquete estándar en cualquier servidor con exposición pública.
Informe periódico consolidado (disco, baneos, amenazas reales) en vez de aviso por evento — evita saturar el correo y facilita ver tendencias.

Backups

Copia diaria fuera de la máquina de: configuración de Nginx (bloques por dominio), certificados/config de Certbot, contenido de /var/www/<dominio>, y código + requirements.txt de cada microservicio.
Si algún servicio guarda datos locales (SQLite, ficheros subidos), incluirlo explícitamente — no asumir que «es solo código».