Servidor y presupuesto de recursos
Toda la plataforma corre en un único VPS con 4 GB de RAM. Con ese límite estricto, delegar el control de memoria a Docker es obligatorio: si un contenedor se excede, el sistema operativo lo apaga forzosamente (Out of Memory). La distribución de recursos queda fija por diseño, no librada al azar del uso de cada momento:
| Componente | Límite de memoria | Propósito |
|---|---|---|
| Sistema operativo (Linux) | ~600 MB (sin límite Docker) | Estabilidad de red y kernel. |
| SQL Server 2022 | ~1.25 GB | Plano de control — Stored Procedures, Vistas, auditoría. |
| MySQL 8.0 | 800 MB (innodb-buffer-pool-size=256M) | Motor de bases de datos de estudiantes. |
| Nginx Proxy Manager | 300 MB | Proxy inverso: subdominios, SSL, rate limiting. |
| Backend .NET Web API | 500 MB (GC en modo bajo consumo) | Middleware despachador. |
| Margen de seguridad | 4 GB de swap | Absorbe picos de tráfico sin tumbar contenedores. |
Por qué el backend nunca se expone directo
El puerto del backend .NET se publica únicamente en 127.0.0.1 (loopback) — solo Nginx puede
alcanzarlo. Nada de internet llega directo al proceso .NET; toda petición pasa primero por el
proxy inverso, que además aplica rate limiting antes de que la petición llegue al backend.
Runtime en modo bajo consumo
El backend corre con variables de entorno del SDK de .NET pensadas específicamente para un entorno de RAM ajustada, no el default de un servidor con recursos holgados:
DOTNET_GCServer=false # Garbage Collector en modo workstation, no server
DOTNET_GCHighMemPercent=60 # Más agresivo liberando memoria bajo presión
DOTNET_COUNTER_MetricsEnabled=false
Monitoreo diario
docker stats # consumo de RAM/CPU en tiempo real por contenedor
free -h # uso real de RAM y porcentaje de swap
df -h # espacio en disco (relevante para las cuotas de las bases de estudiantes)
Seguí con Subdominios para cómo se organiza el tráfico entre servicios.