La mejor forma de hospedar una aplicación Node.js

No existe un único lugar correcto para hospedar Node.js. Un bot de Discord, una API REST, un sitio en Next.js y un webhook que recibe diez llamadas al día tienen necesidades distintas, y la elección equivocada aparece como un bot desconectado, timeouts, una factura alta o fines de semana actualizando un servidor.

La decisión es más sencilla si partes de criterios, comparas las cuatro formas más comunes de hospedar Node.js y llegas a una recomendación por escenario. Si ya elegiste y quieres el paso a paso, mira cómo hospedar una aplicación Node.js.

¿Qué criterios deciden dónde hospedar Node.js?#

Cinco preguntas resuelven la mayoría de los casos:

1. ¿El proceso tiene que estar encendido todo el tiempo? Los bots con Gateway, los servidores WebSocket, las colas y las tareas programadas dentro de la app necesitan un proceso continuo. Una API que solo responde solicitudes no lo necesita, aunque también funciona bien así.
2. ¿Hay conexiones persistentes? WebSocket, Server-Sent Events y las conexiones largas con bases de datos piden un proceso que no se destruya entre solicitudes.
3. ¿Quién va a administrar el servidor? Actualizar el sistema, configurar el firewall, renovar certificados y reiniciar el proceso después de una caída lleva trabajo, y alguien tiene que hacerlo.
4. ¿Cómo es el tráfico? El tráfico constante favorece la capacidad fija y el costo predecible. El tráfico escaso y con picos favorece pagar por uso.
5. ¿Cómo quieres hacer el deploy? Subida de archivos, git push, CLI, pipeline de CI. Cuantos menos pasos manuales, menos errores.

Suma a estos criterios la memoria que usa tu app (mira cómo dimensionar RAM y CPU) y la distancia hasta tus usuarios y tu base de datos.

¿Qué opciones hay para hospedar Node.js?#

VPS#

Un VPS es una máquina virtual con acceso root. Instalas Node.js, subes el código, ejecutas un supervisor que reinicia el proceso y pones un proxy inverso (como nginx) delante para el TLS. Con PM2, por ejemplo, el flujo básico es:

npm install -g pm2
pm2 start index.js --name api
pm2 save
pm2 startup

pm2 save guarda la lista de procesos y pm2 startup genera el script que la recupera después de un reinicio de la máquina (imprime un comando para que lo ejecutes con sudo). Más detalles en PM2 y reinicio automático.

Ventajas: control total, cualquier software, costo fijo. Desventajas: la seguridad, las actualizaciones, las copias de seguridad, los logs y el TLS quedan a tu cargo. Mira qué es un VPS y cuánto cuesta un VPS.

Plataforma de hosting con contenedores#

Subes el código (ZIP, Git o CLI), defines el comando de inicio y las variables de entorno, y la plataforma ejecuta el proceso en un contenedor aislado. No hay sistema operativo que mantener, y el reinicio automático, los logs y el HTTPS normalmente vienen listos.

Ventajas: deploy en minutos, proceso siempre encendido, menos mantenimiento. Desventajas: menos control sobre el sistema (sin root, o con root limitado al contenedor), y cada plataforma tiene sus reglas de puerto, memoria y build. La diferencia entre los modelos está en VPS, cloud o plataforma de hosting.

Serverless#

Entregas funciones, y el proveedor crea un entorno para cada solicitud o evento. El número de entornos sigue a la demanda, incluso hasta cero. A cambio, hay límites: una función estándar de AWS Lambda se ejecuta como máximo 15 minutos por invocación, el payload síncrono tiene un límite de tamaño y el estado en memoria no es fiable entre llamadas. Además existe el cold start, el retraso de la primera llamada en un entorno nuevo.

Ventajas: sin costo con tráfico cero, ideal para picos poco frecuentes. Desventajas: no sirve para procesos continuos ni conexiones persistentes, y el código tiene que escribirse en formato de handler. Mira serverless o contenedores.

Orquestación (Kubernetes y similares)#

Describes contenedores, réplicas y reglas de red, y un orquestador lo reparte todo entre varias máquinas. Es la elección de equipos con muchos servicios y personas dedicadas a operar la infraestructura. Para una app o un bot, es complejidad sin retorno.

¿Cómo se comparan las opciones?#

¿Cuál elegir para cada tipo de proyecto?#

• Bot de Discord, Telegram (long polling) o WhatsApp: un contenedor siempre encendido, en una plataforma o en un VPS. Serverless no mantiene la conexión abierta.
• API REST con tráfico constante: plataforma de contenedores o VPS. Costo predecible y sin cold start.
• Servidor WebSocket o de tiempo real: un contenedor. Mira cómo hospedar un servidor WebSocket.
• Sitio en Next.js con renderizado en el servidor: un contenedor con next start, o una plataforma que soporte Next.js. Mira cómo hospedar una app Next.js.
• Webhook o tarea corta con tráfico escaso: serverless suele compensar.
• Quieres aprender Linux y redes: un VPS. El tiempo de administración se convierte en estudio, no en costo.
• Varios servicios y un equipo de infraestructura: orquestación.

Si dudas entre dos opciones, elige la que exige menos mantenimiento para tu caso. Migrar después es sencillo cuando el código sigue las reglas de la siguiente sección.

¿Qué aplica en cualquier hosting?#

Una app Node.js bien preparada funciona en cualquiera de las opciones de arriba. Los puntos que más problemas evitan:

• Usa la versión LTS activa de Node.js. Es la que recibe correcciones durante más tiempo; el calendario oficial muestra cuál es y cuándo deja de tener soporte cada versión.
• Lee el puerto y los secretos del entorno. Nunca escribas una contraseña ni un token en el código: usa variables de entorno.
• Instala a partir del lockfile con npm ci, y deja en dependencies todo lo que la app importa en runtime.
• Escribe los logs en stdout, no en archivos que nadie lee.
• Expón una ruta de salud y gestiona la señal SIGTERM, que los hostings y los supervisores envían antes de detener el proceso.

Un servidor mínimo que sigue estas reglas, sin dependencias:

import http from "node:http";

const port = Number(process.env.PORT) || 3000;

const server = http.createServer((req, res) => {
  if (req.url === "/health") {
    res.writeHead(200, { "Content-Type": "application/json" });
    res.end(JSON.stringify({ status: "ok", uptime: process.uptime() }));
    return;
  }
  res.writeHead(200, { "Content-Type": "text/plain; charset=utf-8" });
  res.end("Hola desde Node.js\n");
});

server.listen(port, () => console.log(`Escuchando en el puerto ${port}`));

// Cierra con calma cuando la plataforma lo pide (deploy nuevo, reinicio)
process.on("SIGTERM", () => {
  console.log("SIGTERM recibido, cerrando conexiones");
  server.close(() => process.exit(0));
});

Guárdalo como index.mjs y ejecútalo con node index.mjs. En http://localhost:3000/health debe aparecer {"status":"ok",...}. server.close() deja de aceptar conexiones nuevas, cierra las inactivas y llama al callback cuando terminan las solicitudes en curso.

Cómo hacerlo en Square Cloud#

En Square Cloud, una aplicación Node.js sigue el modelo de plataforma de contenedores de la tabla: cada aplicación se ejecuta en un contenedor aislado, siempre encendido, sin cold start ni modo de suspensión. El reinicio automático viene activado en el deploy desde el panel y vuelve a arrancar el proceso que termina con un error, así que no necesitas PM2. Subes el código con un ZIP en el panel, con la CLI, desde GitHub (la GitHub Action oficial o un webhook) o con la extensión de VS Code.

Las reglas de la sección anterior valen aquí igual. Al iniciar, la plataforma ejecuta npm install cuando no existe node_modules, con NODE_ENV=production: lo que está en devDependencies no se instala, así que todo lo que la aplicación importa debe estar en dependencies. No hay paso de build, así que compila en el CI o pon el build en el comando de inicio. Una aplicación web escucha en 0.0.0.0, en el puerto de la variable PORT que define la plataforma, y lo que escribes en stdout aparece en los logs en tiempo real del panel. Las variables de entorno surten efecto en el siguiente reinicio, sin volver a subir el código.

La RAM del plan es un pool compartido: como mínimo 256 MB por aplicación de fondo, como un bot, y 512 MB por aplicación web. El Hobby empieza en R$12,49 al mes, con 1 GB de RAM y 1 vCPU. No hay autoscaling: defines la RAM de cada aplicación y, a partir del Standard, puedes repartir un dominio entre varias aplicaciones con load balancing. Entre diversos runtimes, como Node.js, TypeScript (sin paso de build) y Python, consulta los runtimes disponibles hoy en Runtimes y las funciones de deploy en Funciones.