Mejor alojamiento para Next.js: plataformas gestionadas vs VPS

Next.js es un framework de React capaz de generar dos tipos de salida muy diferentes, y tu elección de alojamiento se deriva directamente de cuál despliegas. Un sitio 100% estático no es más que un conjunto de archivos que sirve un CDN ; una app renderizada en el servidor es un proceso Node.js de larga duración que debe mantenerse vivo. Confunde ambos y acabarás pagando de más por un sitio estático, o desplegando una app dinámica donde no puede ejecutarse. Esta guía explica los modos de renderizado y luego compara con honestidad el compromiso entre una plataforma gestionada y un VPS auto-alojado.

Primero, decide cómo se renderiza tu app

La pregunta más importante es si tu aplicación es estática o necesita un servidor en el momento de la petición. Next.js soporta ambos, y tienen requisitos de alojamiento completamente distintos.

• Exportación estática - con output: 'export', Next.js genera HTML, CSS y JavaScript planos en el momento del build. No hay servidor : el resultado es una carpeta de archivos que cualquier host estático o CDN puede servir. Barato y sencillo, pero descarta todo lo que se ejecuta por petición.
• Renderizado en servidor (SSR / ISR / rutas API) - el renderizado en servidor, la regeneración estática incremental, los manejadores de rutas y el middleware ejecutan código cuando llega una petición. Eso necesita un runtime Node.js que ejecute tu build y se mantenga vivo para responder a las peticiones.

Puedes comprobar qué usa tu proyecto : si depende de getServerSideProps, componentes de servidor que hacen fetch en la petición, rutas API bajo app/api o pages/api, o revalidación ISR, es una app de servidor. Si cada página se puede generar por adelantado, la exportación estática es una opción.

Opción 1: una exportación estática en cualquier host estático

Si tu app es 100% estática, el alojamiento es trivial y barato. Configura la salida en export, haz el build y despliega la carpeta generada en un host estático o CDN :

// next.config.js
module.exports = {
  output: 'export',
};

# el build produce una carpeta estatica 'out/'
npm run build

# 'out/' ahora contiene HTML, CSS y JS que puedes subir a cualquier sitio

La carpeta out/ son solo archivos, así que funciona en cualquier host estático con un CDN global y HTTPS gratuito. Es el mismo modelo que cubrimos en nuestra guía sobre alojamiento de sitios estáticos. El inconveniente es que una exportación estática no puede hacer renderizado en servidor, ISR, optimización de imágenes al vuelo ni rutas API - esas funciones sencillamente no existen sin un servidor.

Opción 2: una plataforma gestionada

Las plataformas gestionadas construyen tu app desde un push de Git y ejecutan el servidor por ti, encargándose del escalado, el TLS y el pipeline de build. Vercel es la más destacada aquí porque es la empresa que desarrolla Next.js, así que su plataforma sigue de cerca las nuevas funciones del framework. Otras plataformas como Netlify también soportan Next.js mediante sus propios adaptadores.

El atractivo es real : haces git push y la plataforma ejecuta todo el flujo, así que no hay servidor que parchear ni proxy inverso que configurar. El compromiso es el control y el coste. Trabajas dentro del modelo de build y ejecución de la plataforma, y una tarificación por uso puede dispararse a medida que crecen el tráfico, la ejecución de funciones y el ancho de banda. Para un proyecto pequeño, los planes gratuitos o bajos son generosos ; para una app con mucha carga, la factura crece con el uso, que es precisamente el punto en el que el auto-alojamiento empieza a resultar atractivo.

Opción 3: auto-alojamiento en un VPS

Como una app Next.js renderizada en servidor es al final un proceso Node.js, puedes ejecutarla tú mismo en un VPS - igual que alojarías cualquier app Node. Es la opción más flexible y normalmente la más barata a gran escala, a cambio de asumir tú mismo el trabajo de operaciones. El build produce un servidor que arrancas con next start :

# en el servidor: instalar deps y hacer build
npm ci
npm run build

# arrancar el servidor de produccion (puerto 3000 por defecto)
npm run start

Como con cualquier proceso Node de larga duración, no deberías ejecutar next start a mano en una sesión SSH. Usa un gestor de procesos como PM2 para mantenerlo vivo y reiniciarlo tras un fallo o un reinicio, y pon un proxy inverso delante. Es exactamente el patrón de nuestra guía sobre alojar una app Node.js :

# mantener vivo el servidor Next.js con PM2
pm2 start "npm run start" --name next-app
pm2 startup
pm2 save

Luego apunta Nginx al proceso Node para que termine el TLS y reenvíe el tráfico público al puerto 3000 :

server {
  listen 80;
  server_name yourapp.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;
  }
}

Añade HTTPS con un certificado automatizado gratuito (herramientas como Certbot lo dejan en una sola línea). Para dimensionar la máquina, los criterios son los mismos que para cualquier app web - primero la memoria, luego la CPU - cubiertos en nuestra guía sobre elegir el mejor VPS para un proyecto web. Proveedores centrados en una buena relación recursos-precio, como Contabo o Hetzner, ofrecen RAM y vCPU generosos a un coste mensual bajo, lo que encaja bien con un build y un runtime Node.

Cómo se comparan las opciones

Enfoque	Ejecuta qué	Gestionas	Ideal cuando
Exportación estática	Archivos en un CDN (sin servidor)	Solo un build y subida	Cada página se puede pre-generar
Plataforma gestionada	SSR, ISR, rutas API	Solo tu código y variables de entorno	Quieres publicar rápido, poco trabajo de ops
VPS (auto-alojado)	SSR, ISR, rutas API	SO, Node, PM2, Nginx, TLS	Quieres control y coste predecible

Cómo decidir

Parte de cómo se renderiza tu app, no del marketing de un proveedor. Si cada página se puede generar por adelantado, publica una exportación estática y alójala a bajo coste en un CDN. Si necesitas SSR, ISR o rutas API, necesitas un runtime Node.js - y entonces se reduce a un compromiso familiar : una plataforma gestionada es la forma más rápida de publicar y el menor trabajo de operaciones, mientras que un VPS es más barato a gran escala y te da el control total, a cambio de ejecutar tú mismo Node, un gestor de procesos, un proxy inverso y el TLS. Elige la opción más pequeña que cubra lo que tu app realmente necesita, y sube de nivel solo cuando el escalado o la carga operativa se conviertan en el verdadero cuello de botella.