Node.js
Configuración y operación de Node.js en producción: variables de entorno, builds, contenedores, señales, health checks, límites, despliegues y compatibilidad.
Preparar Node.js para producción significa controlar versión, configuración, startup, tráfico, recursos, shutdown y actualización. El deploy no termina cuando el proceso escucha un puerto.
artefacto reproducible
↓
configuración validada
↓
startup y readiness
↓
tráfico con límites
↓
observabilidad
↓
shutdown y rollbackLee configuración una vez al iniciar y expón un objeto validado e inmutable.
function loadConfig(env) {
const port = Number(env.PORT ?? 3000);
if (!Number.isInteger(port) || port < 1 || port > 65535) {
throw new Error("Invalid PORT");
}
return Object.freeze({ port, nodeEnv: env.NODE_ENV ?? "development" });
}Usa defaults solo cuando sean seguros. Un secreto ausente debe fallar startup, no activar un valor débil.
Separa valores incorporados al artefacto de valores entregados al iniciar. En Node puro, gran parte de la configuración puede resolverse en runtime; bundlers pueden congelar variables durante build.
Documenta qué capa controla cada valor.
Durante inicio:
Un startup parcial debe cerrar recursos antes de terminar.
Un proxy puede terminar TLS, balancear y añadir headers. Define trust boundaries: no confíes automáticamente en X-Forwarded-For, protocolo o host enviados por internet.
Configura la aplicación y el proxy para sobrescribir y aceptar esos headers solo desde saltos conocidos.
Alinea timeouts entre cliente, proxy, servidor y dependencias.
cliente > proxy > aplicación > dependenciaUna capa exterior que vence antes puede abandonar trabajo que el backend sigue ejecutando. Propaga cancelación cuando sea posible.
En muchos containers y plataformas, el disco local desaparece al reiniciar y no se comparte entre réplicas. Úsalo para temporales o cache descartable; guarda datos persistentes en servicios diseñados para ello.
Estado de sesión, jobs y archivos persistentes no deben depender de una única memoria si existen varias réplicas. Stateless no significa “sin estado”, sino estado administrado fuera del proceso o reconstruible.
El orquestador debe conceder un periodo coherente con el timeout interno.
Para producción utiliza una línea LTS soportada y define:
No esperes hasta el final de soporte para migrar.
Un deploy seguro necesita health checks, capacidad durante transición y compatibilidad de datos. Un rollback de código puede no revertir una migración incompatible.
Diseña cambios expand-contract cuando varias versiones conviven.
El supervisor reinicia procesos y aplica límites; la aplicación maneja señales y cleanup. No dupliques estrategias de clustering sin medir la CPU asignada al container.
¿Por qué una app puede responder health 200 y aun no estar ready?
Porque el proceso está vivo, pero todavía no abrió una dependencia necesaria, está drenando tráfico o no puede atender requests correctamente.
APIs avanzadas y adopción progresiva ubica capacidades recientes sin convertirlas en requisitos universales.