Cómo ejecutar Node.js en un VPS

Heroku eliminó su plan gratuito y subió el precio mínimo. Vercel cobra por usuario y corta las tareas de larga duración. Render y Railway escalan el precio con el tráfico.

Abre la última factura de tu proveedor de hosting. La aplicación de Node, una base de datos Postgres y una caché Redis. Tres conceptos, tres avisos de excedente y un hilo frenético en Slack el día que marketing por fin lanza una campaña.

Esa factura es la razón por la que muchos equipos están volviendo a fijarse en el VPS. A Node.js no le importa dónde se ejecuta. Lo único de lo que te protegía el serverless era de descubrir qué pasa después de «npm start».

Veamos un patrón de configuración de producción para Node.js en una máquina Linux que controlas. Si sabes conectarte por SSH a un servidor y leer un archivo de configuración, al terminar tendrás un stack de producción que podrás mantener durante años con un par de horas de mantenimiento al mes.

¿Cuándo tiene sentido ejecutar Node.js en un VPS?

Un VPS es el sitio ideal para Node.js cuando tienes un proceso de larga duración, un stack que quieres agrupar en una sola factura o una factura de un entorno de ejecución administrado que ya no compensa por la comodidad.

A grandes rasgos, hay tres casos en los que encaja bien:

• Procesos de larga duración: servidores WebSocket, workers de colas, programadores cron, servidores MCP. Cualquier cosa que tenga que seguir en ejecución y a la escucha. La mayoría de plataformas serverless siguen optimizadas para ejecuciones cortas y ciclos de vida de peticiones. Un proceso de Node en un VPS simplemente se queda ahí.
• Consolidación de costes: la aplicación de Node, Postgres, Redis y un pequeño worker de compilación conviven en la misma máquina de 4 GB. Una línea en la factura, no cuatro.
• Aplicaciones a las que el PaaS se les ha quedado pequeño: tiempos de espera agotados en tu larga tarea de generación de PDF. Precios por usuario en un equipo que por fin ha contratado a su cuarto ingeniero. Una factura de Heroku que supera los 60 $ al mes por una carga de trabajo que funciona sin problemas en un VPS de 15 $.

Y hay tres casos en los que no encaja:

• Sitios estáticos y contenido SSG: una exportación de Next.js, una compilación de Astro, un blog de Gatsby. El plan gratuito de Vercel es la herramienta adecuada. Un VPS es excesivo.
• Cargas de trabajo esporádicas basadas en eventos: AWS Lambda o Cloudflare Workers cuestan céntimos para un webhook que se ejecuta diez veces al día. Un VPS cuesta lo mismo tanto si la aplicación está ocupada como si está inactiva.
• Aplicaciones en tiempo real con escalado horizontal: si tu servidor WebSocket necesita repartirse entre 100 000 conexiones simultáneas, un solo VPS no es la solución. Eso requiere un clúster de Kubernetes, una infraestructura edge distribuida o una plataforma en tiempo real administrada.

JavaScript es el lenguaje más usado según la Encuesta para desarrolladores de Stack Overflow de 2025, y Node.js sigue siendo una de las formas habituales de ejecutar JavaScript en el backend. Es mucha gente ejecutando Node en algún sitio. Este artículo es para quienes estarían más contentos ejecutándolo en un servidor que controlan.

He visto a equipos trasladar cuatro servicios de Node en producción de Heroku a un único VPS de 4 GB, con la misma disponibilidad, un tercio de la factura y WebSockets de larga duración que por fin funcionaban sin apaños.

La migración consiste básicamente en una tarde de «apt install», un «pm2 start» y un cambio de DNS.

¿Qué especificaciones de VPS necesita realmente Node.js?

Node.js en sí es ligero. Un servidor Express mínimo puede quedarse en reposo muy por debajo de 100 MB de memoria residente. El consejo de que Node solo necesita 1 GB, que aún encontrarás en blogs antiguos, es técnicamente cierto y en la práctica inútil. Para cuando has añadido Postgres, Redis, logs y un proceso de despliegue que no se sostiene a base de esperanza, ya superas esa cifra en un día tranquilo.

Tamaños realistas para cargas de trabajo habituales:

Algunos detalles que conviene concretar antes de aprovisionar:

• El almacenamiento NVMe importa más que el tamaño del disco: las aplicaciones de Node modernas acceden a miles de archivos pequeños durante las instalaciones, las compilaciones y el arranque. Los discos lentos empeoran notablemente la instalación de dependencias, los arranques en frío y las recompilaciones SSR.
• Virtualización KVM, no OpenVZ: los planes antiguos basados en OpenVZ comparten kernel con el host, lo que puede implicar versiones de kernel obsoletas y algún que otro problema de compatibilidad con entornos de ejecución más recientes. La mayoría de proveedores de VPS fiables ya solo usan KVM, pero merece la pena comprobarlo.
• Espacio de swap: activa 1-2 GB de swap en las máquinas más pequeñas. El heap de V8 de Node puede oscilar mucho durante la recolección de basura. Sin swap, un pico puntual mata el proceso. He visto una máquina de 4 GB quedarse sin memoria (OOM) durante un despliegue rutinario porque alguien había desactivado el swap pensando que era un anacronismo de la era Docker.
• Ancho de banda: la mayoría de los planes VPS actuales incluyen entre 1 y 4 TB de ancho de banda al mes, suficiente para casi todo salvo el alojamiento de vídeo. Los planes de VPS autogestionado incluyen ancho de banda sin límite: una línea menos en la hoja de cálculo de planificación de capacidad.

Un VPS de 4 GB cuesta unos 15 $ al mes a precio de mercado. Son 50 céntimos al día, más o menos un café de aeropuerto cada dos semanas. Comparado con pagar por separado entornos de ejecución, Postgres administrado y Redis en un PaaS, las cuentas cambian sorprendentemente rápido.

¿Qué versión de Node.js deberías instalar?

Instala Node.js 24 (nombre en clave Krypton). Es la versión Active LTS actual, promovida en octubre de 2025 y con soporte hasta abril de 2028, según el calendario oficial de versiones de Node.js.

Muchos tutoriales aún recomiendan Node 22. Esas guías no se han actualizado. Si empiezas un despliegue nuevo hoy, fija tu imagen de CI y tu VPS en Node 24.x.

Algunas reglas básicas:

• No ejecutes versiones Current (no LTS) en producción: Node 26 existe para probar la compatibilidad futura y nuevas funciones del entorno de ejecución, no para la aplicación de la que dependen tus ingresos.
• Node 22 es la opción de reserva si alguna dependencia crítica aún no es compatible con Node 24: la mayor parte del ecosistema se estabilizó a los pocos meses de la promoción a LTS.
• Fija tu versión de Node en todas partes: tu imagen de CI, el Dockerfile, .nvmrc y el VPS de producción deben coincidir. El clásico en mi máquina funciona sale caro en cuanto entran en juego los módulos nativos.

🤔¿Estás pensando en Bun? Es más rápido en algunas cargas de trabajo y realmente impresionante, pero su ecosistema aún es más pequeño y su historial en producción es más corto que el de Node. Para la mayoría de equipos, lo aburrido gana.

NodeSource, que mantiene los repositorios apt y yum desde los que muchos equipos instalan Node en producción, destaca las mejoras de la rama 24.x, empezando por un motor V8 más reciente. Node 24 también incluye herramientas ya maduras, como node –watch integrado y un ejecutor de pruebas nativo estable (node: test), ambos estabilizados en las ramas 20–22 y que se mantienen aquí. Nada de esto es espectacular. Simplemente elimina un poco de fricción operativa cada mes.

¿Cómo se instala Node.js en un VPS?

Tienes dos opciones de instalación realistas. Elige según si el servidor ejecuta una aplicación de Node o varias.

NodeSource para un servidor con una sola aplicación

Esta es la opción más sencilla para producción. Con un script de configuración y un apt install obtienes la rama actual Node 24 LTS como paquete del sistema, y las futuras actualizaciones de seguridad llegan con las actualizaciones normales de paquetes.

En Ubuntu o Debian:

curl -fsSL https://deb.nodesource.com/setup_24.x | bash -
apt install -y nodejs

Verifica la instalación:

node -v
npm -v

Deberías ver una versión Node 24.x.

Las instrucciones para distribuciones de la familia RHEL (yum/dnf) están en el repositorio oficial de distribuciones de NodeSource.

nvm para cambiar de versión según el proyecto

nvm (Node Version Manager) instala Node en tu directorio personal y permite que distintos proyectos usen distintas versiones de Node. Es útil si alojas varias aplicaciones en el mismo servidor o no tienes acceso sudo.

Ejecuta esto con el usuario de tu aplicación, no como root:

curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.40.5/install.sh | bash

Recarga tu shell y luego instala Node 24:

nvm install 24
nvm use 24
nvm alias default 24

👉Una regla importante: no uses sudo ‘npm install -g’ para las dependencias de la aplicación.

Las instalaciones globales suelen reservarse para herramientas CLI a nivel de máquina, como pm2, typescript o nodemon. Las dependencias de tu aplicación van en package.json y deben instalarse desde el directorio del proyecto con npm ci.

Si no lo tienes claro, empieza con NodeSource. La mayoría de servidores de producción con un único propósito no necesitan cambiar de versión de Node por proyecto.

👉Usuarios de VPS de DreamHost: la aplicación Node.js disponible al aprovisionar incluye Node.js 24 LTS, además de fnm, PM2, Nginx y SSL con Certbot, así que puedes saltarte los pasos de instalación anteriores.

¿PM2 o systemd para mantener tu aplicación en marcha?

Cualquiera de los dos funciona. La respuesta sincera es: el que tu equipo maneje con comodidad. PM2 es la opción pensada para desarrolladores. systemd es la opción nativa de Unix. Ambos resuelven los mismos tres problemas: reiniciar tras un fallo, arrancar al iniciar el sistema y apagar de forma ordenada al recibir «SIGTERM».

Si empiezas de cero, así puedes elegir:

El inicio rápido de PM2 es justo eso, rápido:

npm install -g pm2
pm2 start app.js --name api
pm2 startup    # prints the systemd startup command to run
pm2 save       # saves the current process list

A partir de ahí, PM2 es lo único con lo que interactúas: «pm2 logs», «pm2 reload api», «pm2 monit».

👉También conviene saber: «pm2 startup» crea una unidad de systemd, así que la configuración de PM2 en realidad usa systemd por debajo.

Una unidad mínima de systemd para gestionar Node directamente en «/etc/systemd/system/api.service»:

[Unit]Description=My Node APIAfter=network.target

[Service]Type=simpleUser=appWorkingDirectory=/var/www/apiExecStart=/usr/bin/node server.jsRestart=on-failureRestartSec=5Environment=NODE_ENV=productionStandardOutput=journalStandardError=journal

[Install]WantedBy=multi-user.target
Después, «systemctl enable --now api». Los logs están en «journalctl -u api -f».

Si ya usas PM2 y funciona, no migres a systemd solo porque alguien lo haya dicho en Hacker News. La memoria del daemon de PM2 no es motivo para abandonarlo.

Migra cuando tengas un motivo real, como ejecutar media docena de procesos de Node en los que cada megabyte cuenta, o desplegar en un entorno de operaciones donde todos los demás servicios son unidades de systemd y PM2 es la excepción.

¿Cómo se pone NGINX (o Caddy) delante de tu aplicación de Node?

Te conviene un proxy inverso delante de Node por cinco motivos: terminación HTTPS, compresión gzip/brotli, servir archivos estáticos, ejecutar varias aplicaciones en la misma máquina y limitar la tasa de peticiones más fácilmente. Node puede hacer todo esto. NGINX y Caddy lo hacen mejor, y no tumban tu event loop cuando algo falla.

Elige NGINX si alguien de tu equipo ya lo conoce. Elige Caddy si quieres HTTPS en tres líneas de configuración y no te importa un ecosistema más pequeño para configuraciones avanzadas.

Configuración mínima de NGINX

Coloca este bloque de proxy en /etc/nginx/sites-available/api, crea un enlace simbólico en sites-enabled y luego ejecuta nginx -t && systemctl reload nginx.

server {
    listen 80;
    server_name api.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-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_cache_bypass $http_upgrade;
    }
}

Las cabeceras «Upgrade» y «Connection» son las líneas que dan soporte a WebSocket. La propia documentación de NGINX señala que Upgrade es una cabecera hop-by-hop, por lo que necesita un tratamiento explícito al hacer de proxy para el tráfico WebSocket.

Déjalas si tu aplicación usa WebSockets ahora o podría usarlos más adelante. Socket.IO, las suscripciones de GraphQL sobre WebSockets y un número sorprendente de funciones en tiempo real normales dependen de ese handshake de actualización.

El error de producción más habitual que veo en configuraciones de Node es un servidor Socket.IO detrás de NGINX sin esas dos líneas. Las conexiones fallan de forma intermitente, los desarrolladores culpan a Socket.IO y el problema real suele estar en la configuración del proxy.

Caddyfile mínimo

La versión equivalente según el inicio rápido de proxy inverso de Caddy:

api.example.com {
    reverse_proxy 127.0.0.1:3000
}

Ese es el archivo completo. Mientras el dominio apunte al servidor y los puertos 80/443 sean accesibles, Caddy obtiene y renueva HTTPS automáticamente. Según la documentación de Caddy, el HTTPS automático obtiene certificados TLS para los sitios y los mantiene renovados; su guía rápida de proxy inverso también indica que HTTPS es automático cuando Caddy conoce el nombre de host.

Vincula Node a localhost, no a 0.0.0.0

Elijas el proxy que elijas, configura tu aplicación de Node para que escuche en 127.0.0.1:3000, no en 0.0.0.0:3000. En una máquina con Node, lo único que debe estar expuesto a internet es el proxy. Combínalo con UFW, la interfaz de firewall habitual de Ubuntu, para bloquear todo salvo los puertos 22, 80 y 443.

ufw default deny incoming
ufw allow 22/tcp
ufw allow 80/tcp
ufw allow 443/tcp
ufw enable

Si SSH usa un puerto personalizado, permite ese puerto antes de activar UFW.

Vincula a localhost desde el primer día. La reunión en la que alguien admite que la app estaba expuesta porque Node escuchaba en 0.0.0.0 no es una reunión que quieras tener.

¿Cómo se configura HTTPS para tu aplicación de Node.js?

Usa Let’s Encrypt. Es gratuito, automático y todos los navegadores confían en él. Hay dos caminos, según el proxy que hayas elegido.

NGINX + Certbot

Apunta un registro A a la IP de tu VPS y espera a que se propague el DNS.

Instala Certbot:

apt install certbot python3-certbot-nginx

Ejecuta:

certbot --nginx -d api.example.com

Certbot actualiza tu configuración de NGINX y recarga el servidor automáticamente.

En las versiones modernas de Ubuntu, un temporizador de systemd instalado con el paquete de Certbot se encarga de la renovación automáticamente.

Abre https://api.example.com y comprueba que aparece el icono del candado.

La documentación oficial de Certbot también explica la instalación con snap por si el paquete de tu distribución está desactualizado.

Caddy

Añade el dominio al Caddyfile (el ejemplo anterior ya lo incluye) y reinicia Caddy. Mientras el dominio se resuelva correctamente y los puertos 80/443 sean accesibles, el certificado se obtiene automáticamente en el primer arranque. Sin Certbot.

En producción, no termines TLS en el propio Node.

El módulo https de Node funciona perfectamente, pero los proxies inversos como NGINX y Caddy están diseñados específicamente para la terminación TLS. Te ofrecen OCSP stapling, cifrados modernos por defecto, renovación automática de certificados, compatibilidad con HTTP/2 y, en el caso de Caddy, compatibilidad con HTTP/3 de serie.

¿Podrías gestionar todo eso directamente en Node? Claro. Solo que estarías reconstruyendo una infraestructura que tu proxy ya resuelve de maravilla.

¿Cómo es realmente una configuración de Node.js lista para producción?

Hay ocho cosas que dan problemas en producción. La mayoría no aparecen en los tutoriales de instalación porque no encajan en el esquema instalar Node, ejecutar la app. Son la diferencia entre una app que sobrevive al segundo mes y una que no.

• NODE_ENV=production: El paso que más se olvida. En muchos frameworks y bibliotecas de Node, desactiva comportamientos exclusivos de desarrollo y activa optimizaciones de producción. Express, por ejemplo, almacena en caché las plantillas de vista compiladas y devuelve errores más escuetos en producción; su propia documentación habla de una mejora del rendimiento de hasta 3 veces. Define la «variable de entorno» en todas partes.
• Apagado ordenado: Cuando tu VPS se reinicia o PM2 envía «SIGTERM», tu app tiene unos segundos para terminar las peticiones en curso, cerrar las conexiones a la base de datos y salir limpiamente. Configura un controlador «process.on(‘SIGTERM’, …)». El tiempo de apagado predeterminado de PM2 depende de la configuración y del entorno, así que no des por hecho que siempre tendrás mucho tiempo para limpiar.
• Rotación de registros: El módulo «pm2-logrotate» de PM2 se encarga de ello en PM2. El journal de systemd lo gestiona para las unidades de systemd directas. Sin rotación, tus registros se comen el disco en una cuarta parte del tiempo que esperarías.
• Disciplina con .env: Nunca subas secretos al repositorio ni los registres en los logs. Usa «dotenv» en desarrollo local. En producción, define las variables de entorno mediante «Environment=» en tu unidad de systemd o en tu archivo ecosystem de PM2. El día que hagas un «console.log(process.env)» por accidente será el día en que tengas que rotar todas las credenciales.
• Un proxy inverso delante de Node: Vincula Node a localhost y deja que NGINX o Caddy den la cara a internet.
• Un cortafuegos: Con UFW, bloquéalo todo excepto 22, 80 y 443. Sacar SSH del puerto 22 no detendrá a un atacante decidido, pero reduce muchísimo el ruido de los ataques automatizados de fuerza bruta y la basura en los registros de autenticación.
• Monitorización: Un endpoint de comprobación de estado que tu herramienta de monitorización consulte cada minuto. PM2 incluye lo básico. Para algo serio, usa Prometheus y Grafana, o un servicio de disponibilidad alojado como Better Stack o UptimeRobot. Te interesa saber que tu app se ha caído antes de que te lo diga un cliente.

Mantenimiento estimado para este stack: entre una y tres horas al mes.

Actualizaciones con apt, alguna subida de versión de dependencias y un vistazo trimestral al volumen de registros. Ese es el precio de ganar en coste y control.

¿Cuándo no conviene un VPS para Node.js?

Un VPS es mala elección cuando tu carga de trabajo está pensada para otra cosa. Sé sincero sobre en qué lado estás antes de contratarlo.

• Sitios estáticos y contenido SSG: Exportaciones de Next.js, Astro, Gatsby y un blog con Eleventy. Plataformas como Vercel, Netlify o Cloudflare Pages te ofrecen hosting estático con caché global, despliegues basados en Git y recompilaciones automáticas de serie. Para contenido puramente estático, un VPS suele ser infraestructura innecesaria.
• Cargas de trabajo esporádicas y basadas en eventos: Cloudflare Workers y AWS Lambda salen baratos para webhooks que se ejecutan diez veces al día.
• Apps en tiempo real que necesitan más de 100 000 conexiones simultáneas: Un solo VPS no escala horizontalmente. Necesitarás orquestación (Kubernetes, ECS, Nomad) o una plataforma administrada de tiempo real como Ably o Pusher.
• Cargas de trabajo reguladas con mucha normativa: HIPAA, PCI-DSS Level 1, FedRAMP. Una PaaS administrada con certificaciones de cumplimiento integradas te ahorra el sufrimiento de las auditorías. Gestionar tú mismo el cumplimiento en un VPS es un proyecto de varios trimestres que probablemente no quieres.
• No te manejas con Linux ni tienes ganas de aprender: Plataformas como Render, Railway y DigitalOcean App Platform están a medio camino entre un VPS en bruto y una PaaS totalmente administrada. Herramientas como Dokploy añaden flujos de despliegue al estilo Heroku sobre tu propia infraestructura VPS. Sigues obteniendo buena parte de las ventajas de coste y control sin tener que conocer a fondo iptables, las tripas de systemd o la depuración de proxies inversos a la 1 de la madrugada.

Ninguna de estas respuestas es motivo de vergüenza. La mejor decisión técnica es la que encaja con tu carga de trabajo.

Elige tu stack de Node y ponte manos a la obra

Abre esa factura de hosting una vez más.

Estás a punto de sustituir una parte sorprendente de ella por una sola factura de VPS.

👉El stack: Ubuntu 24.04 LTS, Node 24, PM2 (o systemd), NGINX (o Caddy), Let’s Encrypt mediante Certbot (o la función integrada de Caddy).

Pon en marcha el plan de VPS más pequeño que cubra la RAM que calculaste, instala Node, ejecuta tu app en «127.0.0.1», apunta NGINX hacia ella y cambia tu DNS.

Si la app sobrevive a un despliegue, un reinicio y una noche funcionando sin sobresaltos, ya tienes casi todo hecho.

Lo demás es mantenimiento. Una o dos horas al mes, alguna ventana para «apt upgrade» y una actualización trimestral de dependencias. Ese es el trato que hiciste al cambiar una factura por usuario por una tarifa fija, y el VPS autogestionado Stack 4 de DreamHost es un buen punto de partida.

Preguntas frecuentes sobre cómo ejecutar Node.js en un VPS