Hosting de sitios vs hosting de aplicaciones (Node, Python, bots)

La palabra "hosting" cubre dos servicios muy distintos. Uno guarda archivos y los entrega a quien los pida. El otro ejecuta tu programa y lo mantiene vivo. Contratar el equivocado está detrás de muchos mensajes del tipo "mi bot no arranca" o "el panel no acepta Node".

Ninguno de los dos gana en todos los casos. La elección depende de lo que hace tu proyecto cuando nadie lo está visitando.

¿Qué es el hosting de sitios?#

Es un servicio que almacena los archivos del sitio y los entrega por el protocolo HTTP. MDN lo describe como un servidor web estático: envía al navegador los archivos alojados tal como están.

Este modelo suele venir con extras: panel de control, correo del dominio, certificado TLS y, en muchos planes, PHP con una base de datos MySQL ya instalados. Subes los archivos por FTP o con el explorador de archivos del panel, y el proveedor se encarga de cómo funciona el servidor. En general no eliges la versión del runtime ni instalas paquetes por tu cuenta.

Sirve bien para sitios corporativos, portafolios, blogs en WordPress y landing pages. Mira también qué es un sitio estático y dónde alojarlo.

¿Qué es el hosting de aplicaciones?#

Es un servicio que ejecuta tu código en un proceso que permanece encendido. Eliges el lenguaje (Node.js, Python, Java, Go y otros), subes el proyecto, y la plataforma lanza el comando de inicio y lo mantiene en marcha.

MDN llama servidor dinámico al que tiene, además del servidor HTTP, un servidor de aplicaciones y normalmente una base de datos: el código genera o modifica la respuesta antes de enviarla. En un hosting de aplicaciones esa capa es tuya. Un ejemplo mínimo en Node.js con Express 5:

// server.mjs (o "type": "module" en el package.json para usar .js)
import express from "express";

const app = express();

app.get("/", (req, res) => {
  res.send("¡Hola! Esta respuesta la armó el código, no un archivo.");
});

// El puerto viene del entorno; 3000 es solo el valor local de desarrollo.
const port = process.env.PORT ?? 3000;
app.listen(port, () => console.log(`Escuchando en el puerto ${port}`));

La clave está en app.listen: el programa nunca termina. Mientras siga en pie, el sitio responde. Si se cae, el sitio se cae. Por eso el hosting de aplicaciones ofrece reinicio automático, logs y control de memoria.

¿Cuál es la diferencia en la práctica?#

La segunda fila lo decide casi todo: si algo tiene que estar en marcha aunque no haya visitas, es una aplicación.

¿Qué proyectos exigen hosting de aplicaciones?#

• Bots. Un bot de Discord mantiene abierta una conexión WebSocket con el Gateway. Sin proceso continuo, queda offline. Lo mismo vale para bots de Telegram con long polling y de WhatsApp.
• APIs. Un backend en Express, FastAPI o Spring recibe peticiones, consulta la base de datos y responde. Necesita runtime y puerto, no un directorio de archivos. Mira cómo alojar una aplicación Node.js.
• Sitios con renderizado en el servidor. La documentación de Next.js enumera cuatro formas de publicar: servidor Node.js, contenedor Docker, exportación estática y adaptadores. El servidor Node.js y Docker admiten todas las funciones; la exportación estática es limitada y no ofrece lo que depende del servidor.
• Workers y tareas programadas. Colas, scrapers y rutinas que se ejecutan cada hora necesitan un proceso propio.
• Conexiones en tiempo real. Chat, notificaciones y juegos usan WebSocket, que exige un proceso persistente.

¿Qué proyectos funcionan bien en un hosting de sitios?#

• Sitio corporativo, portafolio y página de producto en HTML y CSS.
• Blog o tienda en WordPress (PHP y MySQL, con instalación en un clic).
• Front-end generado como estático: React con Vite, Astro, Next.js con output: "export" y similares, siempre que no dependan de código en el servidor.

La regla práctica: si el resultado del build es una carpeta de archivos que funciona al abrirla en el navegador, un hosting de archivos basta. Si el proyecto necesita un comando como node server.mjs o python main.py para existir, necesita hosting de aplicaciones.

¿Cómo saber cuál elegir?#

Responde en orden:

1. ¿El proyecto tiene un comando de inicio? Sí: aplicación. No: sigue.
2. ¿Necesita guardar datos que cambian (usuarios, pedidos, sesiones)? Sí, y en un lenguaje que no es PHP: aplicación, con una base de datos. Sí, y en WordPress: el hosting de sitios ya lo trae todo.
3. ¿Quieres elegir la versión del lenguaje y las dependencias? Sí: aplicación.
4. ¿Solo necesitas mostrar páginas y quieres el menor costo y el menor mantenimiento? Hosting de archivos.

Fuera de estos dos existen el VPS y la nube genérica, en los que administras el servidor entero. Dan más libertad y más trabajo; la comparación está en VPS o hosting compartido.

¿Qué cambia al migrar de uno a otro?#

De sitio a aplicación, pasas a indicar lo que antes era invisible: el comando de inicio, el puerto en el que escucha el programa y las variables de entorno (claves, URL de la base de datos). Guarda los secretos en variables, nunca en el código.

De aplicación a sitio estático, renuncias al código en el servidor: formularios, inicio de sesión y APIs tienen que pasar a servicios externos o quedarse en otra aplicación. Mucha gente separa las dos partes, con el front-end estático por un lado y la API por el otro, conectados por llamadas HTTP.

Cómo hacerlo en Square Cloud#

Si las preguntas de arriba apuntaron a una aplicación, Square Cloud es hosting self-service de ese tipo: subes el proyecto, defines el archivo principal y la memoria, y se ejecuta en un contenedor aislado. El contenedor está siempre encendido, sin modo de suspensión, con reinicio automático (activado por defecto en el deploy desde el panel) si el proceso termina con error. Eso sirve tanto para un servidor Node.js o Python como para un bot.

Para sitios, el camino depende del tipo. Entre diversos runtimes, hay uno para sitios estáticos (HTML, CSS y JavaScript listos), en el que nginx está siempre en línea sirviendo tus archivos y cada actualización queda en línea al instante. Para servidores, hay runtimes como Node.js, TypeScript, Python y PHP. Consulta los runtimes disponibles hoy en Runtimes. Toda aplicación web recibe un subdominio *.squareweb.app con HTTPS. A partir del plan Standard, apuntas un dominio propio creando en tu registrador los registros DNS que muestra el panel, y el dominio sigue registrado a tu nombre.

El archivo de configuración squarecloud.app es opcional: el panel lo genera en el deploy (runtime, memoria y archivo principal), y escribirlo a mano en la raíz del proyecto es la alternativa. La RAM del plan es un pool compartido entre tus aplicaciones, con un mínimo de 512 MB por aplicación web, y todos los planes incluyen analytics web sin cookies.

Los detalles del hosting de sitios están en la página de Sites.