</> HTML5Advent
ENFRESDEITPT

// hosting · Web Platform Advent #14

Cómo alojar una app Node.js: VPS, PaaS y serverless

Las formas prácticas de desplegar una aplicación Node.js — VPS, PaaS gestionado o serverless — con PM2, un proxy inverso, variables de entorno y un flujo de despliegue ordenado.

Una mano inserta un servidor blade en un rack de servidores iluminado en azul

Alojar una app Node.js no se parece a alojar un sitio estático o una página PHP. Node ejecuta un proceso de larga duración que posee su propio servidor HTTP, así que el alojamiento debe mantener vivo ese proceso, reiniciarlo si se cae y enrutar el tráfico público hacia él. Esta guía repasa las tres opciones realistas y las piezas que necesitas elijas la que elijas.

Tres formas de alojar Node.js

Casi todos los despliegues encajan en uno de estos modelos. La elección correcta depende de cuánto del servidor quieras gestionar y de cómo se comporte tu tráfico.

  • VPS (autogestionado) — obtienes una máquina Linux con acceso root completo. Control máximo y coste previsible, pero instalas y mantienes tú mismo Node, el gestor de procesos, el proxy inverso y TLS.
  • PaaS (platform-as-a-service) — subes el código (a menudo vía Git) y la plataforma construye, ejecuta y escala el proceso por ti. Menos control, despliegue más rápido, normalmente cobrado por uso.
  • Serverless / funciones — despliegas handlers individuales en lugar de un servidor permanente. La plataforma los arranca bajo demanda. Ideal para tráfico irregular o bajo, pero sin estado y sujeto a arranques en frío.

Mantener el proceso vivo con PM2

En un VPS, ejecutar node server.js en tu shell se detiene en cuanto cierras sesión, y nada lo reinicia tras un fallo. Un gestor de procesos resuelve ambas cosas. PM2 es la opción habitual:

npm install -g pm2

# arrancar la app y darle nombre
pm2 start server.js --name web

# reinicio automático tras un reinicio del servidor
pm2 startup
pm2 save

# comandos útiles del día a día
pm2 list
pm2 logs web
pm2 restart web

PM2 también ejecuta tu app en modo cluster para usar todos los núcleos de CPU, la forma más sencilla de escalar una sola máquina:

pm2 start server.js --name web -i max
Una fila de servidores montados en rack en un centro de datos
En un VPS, tu proceso Node corre en una máquina física o virtual como estas; un gestor de procesos lo mantiene en marcha y un proxy inverso lo expone a la web.

Un proxy inverso delante de Node

No expongas Node directamente en el puerto 80/443. Coloca un proxy inverso como Nginx delante: termina TLS, sirve archivos estáticos de forma eficiente y puede enrutar varias apps en una sola máquina. Un bloque de servidor Nginx mínimo que reenvía el tráfico a una app Node que escucha en el puerto 3000:

server {
  listen 80;
  server_name example.com;

  location / {
    proxy_pass http://127.0.0.1:3000;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection 'upgrade';
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
  }
}

Las cabeceras Upgrade y Connection importan si tu app usa WebSockets. Para HTTPS, la vía habitual es un certificado gratuito de Let's Encrypt vía certbot, que edita esta configuración por ti.

Variables de entorno y configuración

Nunca pongas secretos en duro (URL de base de datos, claves de API) en tu código fuente. Léelos del entorno con process.env, y deja que la plataforma los inyecte:

const port = process.env.PORT || 3000;
const dbUrl = process.env.DATABASE_URL;

app.listen(port, () => {
  console.log(`escuchando en ${port}`);
});

En un VPS puedes guardarlos en un archivo .env (cargado por una librería, y excluido de Git) o pasarlos mediante el archivo ecosystem de PM2. En un PaaS, los defines en el panel. Lee siempre process.env.PORT — las plataformas gestionadas te asignan el puerto.

Un flujo de despliegue ordenado

Sea cual sea tu alojamiento, busca un despliegue reproducible en lugar de editar archivos en el servidor a mano:

  • Trae el código nuevo (git pull o un artefacto de CI).
  • Instala solo las dependencias de producción: npm ci --omit=dev.
  • Ejecuta el paso de build si lo tienes (npm run build).
  • Recarga el proceso sin cortes: pm2 reload web.

En un PaaS toda esta secuencia se dispara con un git push; en un VPS puedes scriptarla o conectarla a un runner de CI.

¿Qué opción encaja?

OpciónGestionasIdeal cuando
VPSSO, Node, PM2, Nginx, TLSQuieres control y coste previsible
PaaSSolo tu código + variables de entornoQuieres desplegar rápido y escalar con facilidad
ServerlessHandlers individualesTráfico irregular o bajo, trabajo sin estado

Si empiezas, un solo VPS bien configurado con PM2 y Nginx ejecutará cómodamente la mayoría de apps Node y te enseña lo que las plataformas gestionadas automatizan. Pasa a un PaaS o a serverless cuando el escalado o la carga operativa se convierta en el cuello de botella — no antes.