¿Por qué tu servidor EC2 de repente deja de responder — Y cómo hacer a prueba de balas las aplicaciones Laravel y Node

Gestionar varias aplicaciones Laravel y Node.js en una sola instancia EC2 es habitual en equipos pequeños y medianos, pero cuando varias aplicaciones comparten recursos una operación pesada puede dejar congelado todo el servidor y tumbar todos los dominios a la vez. Recientemente en uno de nuestros proyectos de desarrollo detectamos que todos los dominios de test y desarrollo dejaron de responder al mismo tiempo aunque en muchos de ellos no se había desplegado código. Tras investigar a fondo, la causa fue el agotamiento de recursos provocado por un proceso de build de Node ejecutado directamente en la instancia.

Qué ocurrió realmente: alguien ejecutó npm run build o yarn build dentro de la EC2. En instancias con poca memoria RAM, típicamente 1 a 2 GB, herramientas de build de Node como Vite, Webpack o Next.js consumen mucha memoria para compilar y optimizar assets. A medida que la memoria se llena, el servidor comienza a usar swap agresivamente, el sistema mata procesos críticos, PHP-FPM se cuelga, los workers de Nginx se atascan y SSH se vuelve lento o inalcanzable. Como todas las aplicaciones Laravel, servicios Node, workers y sockets corren bajo el mismo sistema operativo, el resultado fue que todo el sistema quedó inoperativo.

Síntomas típicos a vigilar: uso de CPU al 100 por ciento, memoria RAM cercana al 100 por ciento, swap en uso total, procesos OOM killer eliminando primero PHP-FPM o MySQL en lugar del propio compilador Node, códigos 502 o 504 en Nginx y pérdida de acceso SSH.

Por qué un build de Node puede colapsar una instancia pequeña: minificar grandes bundles JS, optimizar imágenes, compilar TypeScript, aplicar tree-shaking y generar múltiples targets son tareas muy costosas en memoria y CPU. En servidores pequeños eso conlleva a 1) CPU al máximo, 2) agotamiento de RAM porque un build puede requerir 512 MB a 2 GB o más, 3) kills por OOM donde el kernel prioriza procesos distintos a Node, 4) Nginx devuelve errores o deja de responder, y 5) el sistema entra en swapping intenso y deja de schedulear tareas.

Medidas inmediatas y prácticas para evitar futuros incidentes:

1. Nunca compilar frontend en servidores de producción o test. En su lugar compilar localmente o en CI/CD y subir solo la carpeta dist o build ya compilada para desplegar los assets finales. Esto previene la mayoría de incidentes relacionados con builds en servidor.

2. Añadir un archivo de swap de 2 GB en instancias pequeñas para mitigar picos de memoria: por ejemplo sudo fallocate -l 2G /swapfile; sudo chmod 600 /swapfile; sudo mkswap /swapfile; sudo swapon /swapfile; y añadir /swapfile swap swap defaults 0 0 a /etc/fstab. El swap ayuda al sistema operativo a no colapsar cuando la RAM se agota.

3. Limitar el uso de memoria de procesos Node, sobre todo si se usan PM2: pm2 restart nombre_app --max-memory-restart 300M o aplicar a todas las apps pm2 restart all --max-memory-restart 300M. Esto evita que una sola instancia de Node consuma toda la memoria disponible.

4. Reiniciar PHP-FPM y Nginx en casos de carga extrema para restaurar servicio rápidamente: sudo systemctl restart php8.1-fpm; sudo systemctl restart nginx. Suele ser un remedio inmediato mientras se resuelve la causa raíz.

5. Monitorizar el uso de recursos en tiempo real con htop para identificar procesos que consumen CPU o RAM, procesos zombis y servicios bloqueados. Instalar con sudo apt install htop y ejecutar htop.

6. Usar pm2 startup y pm2 save para garantizar que las aplicaciones Node se reinicien automáticamente tras un reboot.

7. Implementar una pipeline de despliegue para construir los assets fuera del servidor: GitHub Actions, GitLab CI, Bitbucket Pipelines, Jenkins o servicios de build en la nube. Construir antes de desplegar y no en el servidor es la solución más fiable a largo plazo.

Medidas adicionales recomendadas: separar entornos y servicios críticos en instancias o contenedores distintos, usar builds en runners dedicados o servicios como AWS CodeBuild o Azure DevOps, configurar límites con cgroups o systemd, y diseñar escalabilidad horizontal si la carga lo requiere. Para equipos que necesitan máxima estabilidad conviene usar balanceadores, autoescalado y almacenamiento de assets en CDNs.

Sobre Q2BSTUDIO: somos una empresa de desarrollo de software a medida especializada en aplicaciones a medida, inteligencia artificial, ciberseguridad y servicios cloud. Ofrecemos soluciones completas que incluyen despliegue seguro en AWS y Azure, automatización de pipelines, integraciones con Power BI y proyectos de inteligencia de negocio para convertir datos en decisiones. Si necesitas ayuda para diseñar una arquitectura robusta que evite caídas por builds en servidor o para migrar a una estrategia CI/CD profesional, en Q2BSTUDIO podemos ayudarte a crear software a medida y a desplegarlo de forma segura y escalable. Consulta nuestros servicios de desarrollo de aplicaciones en software a medida y aplicaciones a medida y descubre nuestras opciones de infraestructura en la nube en servicios cloud aws y azure.

Palabras clave y servicios que cubrimos: aplicaciones a medida, software a medida, inteligencia artificial, ciberseguridad, servicios cloud aws y azure, servicios inteligencia de negocio, ia para empresas, agentes IA y power bi. Implementar las prácticas anteriores garantiza rendimiento estable y reduce drásticamente el riesgo de downtime en entornos de desarrollo, test y producción.

Conclusión: cuando varias aplicaciones comparten una sola instancia EC2, una tarea intensa como un build de Node puede sobrecargar recursos y paralizar todo el servidor. Evita construir en servidores de runtime, añade swap en instancias pequeñas, limita memoria de procesos, monitoriza constantemente y usa pipelines CI/CD. Si necesitas apoyo para aplicar estas medidas o diseñar una arquitectura segura y escalable, Q2BSTUDIO está listo para ofrecer soluciones a medida en desarrollo, inteligencia artificial, ciberseguridad y cloud.