Aloje su primera aplicación Node.js sin tratarla como un sitio PHP

Un desarrollador envía su aplicación Express por FTP a un hosting PHP compartido. No se inicia nada: no hay node server.js permanente, no hay puerto 3000 expuesto, no hay proxy inverso configurado. No es Node.js lo que es "complicado": es Node.js alojado como PHP, donde cada solicitud iniciaría un intérprete que muere inmediatamente.

Alojar su primera aplicación Node.js significa aceptar un modelo de ejecución diferente. PHP-FPM maneja solicitudes cortas; Node.js mantiene un proceso vivo que mantiene el estado en la memoria, escucha un puerto HTTP y espera conexiones. Sin un administrador de procesos, un proxy y un reinicio automático, la primera ola de tráfico (o la primera falla del proceso) finaliza su “puesta en marcha”.

PHP y Node.js: dos modelos de ejecución

Tratar Node.js como PHP es como pedirle a un restaurante que recaliente el horno para cada pedido.

En un PHP compartido, el servidor web sabe cómo ejecutar archivos .php. No sabe cómo mantener activo un proceso de Node.js entre dos solicitudes. Incluso si carga server.js, nadie lo inicia y nadie lo reinicia si falla a las 3 a. m.

Pila mínima para una primera producción

1. Compilación de integración continua. npm ci, pruebas automatizadas, npm run build si se compila una interfaz. La producción recibe un artefacto probado, no un "git pull" improvisado.

2. Administrador de procesos. Archivo del ecosistema PM2 o ​​unidad systemd con Restart=always. El proceso debe sobrevivir a los errores no detectados y reiniciarse al iniciar el servidor.

3. Proxy inverso. nginx con proxy_pass a 127.0.0.1:PORT. Node.js no expone directamente el puerto 3000 a Internet: el proxy maneja TLS, encabezados y compresión.

4. Cifrado TLS. Cifraremos en nginx, no en Node.js a menos que esté específicamente restringido. Renovación automatizada y recarga de nginx documentada.

5. Variables de entorno. NODE_ENV=producción, secretos a través de variables de entorno: nunca confirmados en el repositorio. Un archivo .env en el servidor, permisos restringidos.

6. Registros. stdout y stderr agregados; rotación si se escribe en el disco. Sin registros centralizados, un fallo nocturno permanece invisible hasta el lunes por la mañana.

7. Comprobación de estado. Ruta /health para monitoreo y equilibrio de carga. Sin él, un proceso zombie puede permanecer "en línea" sin atender solicitudes.

Elija el anfitrión adecuado

Evite las ofertas de “PHP ilimitado compartido” sin mencionar explícitamente Node.js: este es el producto equivocado. Compare las ofertas PaaS y VPS en nuestro directorio y la comparación. Para conocer la cultura de implementación a largo plazo, consulte también Django en producción y PM2 e implementación: otras pilas, los mismos principios.

Errores clásicos cuando se pone en producción por primera vez

• node_modules cargado de Windows a Linux sin reconstruir los módulos nativos: bcrypt, Sharp y sqlite3 fallan silenciosamente.
• Aplicación que escucha en 0.0.0.0 sin firewall: el puerto Node.js se expone directamente, sin pasar por nginx.
• Sin límite de memoria: una fuga de JavaScript mata todo el servidor después de unas horas.
• WebSockets olvidados en la configuración de nginx: faltan los encabezados "Actualización" y "Conexión", el tiempo real no funciona.
• Implementación = git pull sin reinicio de PM2: el código antiguo todavía se está ejecutando en la memoria.

Cada error es predecible. Ninguno es inevitable si prueba el ciclo completo antes de anunciar el lanzamiento.

La parte superior: Node.js solicita un host que permita vivir un proceso

Esto es lo que los tutoriales de “implementación en cinco minutos” olvidan decir.

Decide y avanza sin puntos ciegos

En un día, puedes sentar las bases para una producción real de Node.js:

1. Validar una oferta de Node.js, PaaS o VPS con acceso root.
2. Configure PM2 o ​​systemd, luego nginx como proxy inverso.
3. Automatizar la implementación reiniciando el proceso en cada versión.
4. Pruebe la recuperación tras fallo: finalice el proceso manualmente y verifique el reinicio.
5. Monitorear la memoria y el número de reinicios de PM2.

Comience validando que su host permita un proceso persistente; este es el requisito previo no negociable. A continuación, documente quién modifica la configuración, cómo reiniciar nginx después de la renovación de TLS y dónde leer los registros en caso de falla. Para obtener más información sobre las pérdidas de memoria, consulte Pérdida de memoria de Node.js.

Preguntas frecuentes

¿Podemos alojar Node.js en una plataforma PHP compartida?

Casi nunca. Un PHP compartido no mantiene un proceso Node.js persistente, no expone un puerto personalizado ni configura un proxy inverso para su aplicación. Busque una oferta dedicada de Node.js, PaaS o VPS.

¿PM2 o ​​systemd en producción?

Ambos funcionan. PM2 simplifica el modo de clúster y la recarga perfecta; systemd se integra de forma nativa con el registro del sistema Linux. En ambos casos, es obligatorio el reinicio automático después de una falla y al iniciar el servidor.

¿Debería usarse nginx delante de Node?

Sí, en la práctica: nginx gestiona el cifrado TLS, HTTP/2, archivos estáticos y limitación de velocidad. Node.js escucha localmente en un puerto interno, nginx enruta el tráfico público hacia él.

¿Cómo implementar sin interrupción del servicio?

Utilice la recarga de PM2, una implementación azul-verde o dos instancias detrás de un equilibrador de carga. Construya siempre con npm ci en integración continua, nunca manualmente en el servidor de producción.

Node.js en producción no es un archivo cargado, es un proceso que alguien debe mantener vivo.