Alojar Next.js en un VPS: servidor Node.js, systemd y Nginx

Una web hecha con Next.js no siempre necesita un servidor en producción. Si exporta HTML y archivos estáticos, puede servirse como una web normal. Si depende de rutas dinámicas, Server Actions, cookies, renderizado bajo demanda o funciones de servidor, necesita un runtime compatible. Next.js documenta el despliegue como servidor Node.js, contenedor Docker o exportación estática; cada opción conserva capacidades distintas.

Esta guía cubre el servidor Node.js autogestionado en un VPS. No es un instalador de Next.js de un clic: tú preparas el código, el proceso, el proxy, las actualizaciones y las copias.

Decide qué salida necesita la aplicación

La documentación oficial de despliegue de Next.js califica la salida estática como limitada frente al servidor Node.js o Docker. Eso describe las capacidades del framework, no una compatibilidad automática de Hostbrid. En Projects, comprueba el plan, la cuota de servicios y la configuración de la imagen Docker. Para tener acceso root y controlar el sistema, compara las opciones VPS.

Revisa el proyecto antes de subirlo

Comprueba package.json, el archivo de lock y los comandos reales. En una aplicación habitual, los scripts de producción se parecen a estos:

{
  "scripts": {
    "dev": "next dev",
    "build": "next build",
    "start": "next start"
  }
}

Usa el mismo gestor de paquetes que generó el lock (npm ci, pnpm install --frozen-lockfile o el equivalente del proyecto), compila y arranca la aplicación en producción. La documentación del CLI permite indicar host y puerto; para probar desde la propia máquina, limita la escucha a 127.0.0.1:

npm ci
npm run build
npm run start -- --hostname 127.0.0.1 --port 3000

La guía vigente de Next.js pide Node.js 20.9 como mínimo; revisa los requisitos de la versión concreta de tu proyecto y usa un runtime compatible. Prueba una ruta con datos, una ruta que no exista, imágenes next/image, formularios, autenticación y llamadas a API. Un build correcto no demuestra que esos servicios externos sigan funcionando.

Ejecuta el servidor como servicio del sistema

En el VPS, crea un usuario Linux sin privilegios y deja el repositorio en un directorio propio, por ejemplo /srv/nextjs/app. Compila con el lockfile, conserva en producción los artefactos y dependencias que necesita next start y configura los secretos fuera del repositorio. Las variables con prefijo NEXT_PUBLIC_ se incluyen en el JavaScript del navegador al compilar; no pongas ahí claves privadas.

Puedes usar una unidad systemd para mantener el proceso y reabrirlo si se cierra inesperadamente:

[Unit]
Description=Next.js application
After=network-online.target
Wants=network-online.target

[Service]
User=nextapp
Group=nextapp
WorkingDirectory=/srv/nextjs/app
Environment=NODE_ENV=production
Environment=PORT=3000
Environment=HOSTNAME=127.0.0.1
EnvironmentFile=/etc/nextjs-app.env
ExecStart=/usr/bin/npm run start -- --hostname 127.0.0.1 --port 3000
Restart=on-failure
RestartSec=5
NoNewPrivileges=true
PrivateTmp=true

[Install]
WantedBy=multi-user.target

Adapta la ruta absoluta de npm a la instalación real y restringe /etc/nextjs-app.env al usuario administrador. Si la aplicación usa archivos subidos, una base de datos, tareas programadas o almacenamiento, configúralos y respáldalos por separado: el directorio .next no sustituye una copia de los datos.

Pon Nginx delante y comprueba el dominio

La guía oficial de self-hosting de Next.js recomienda un proxy inverso en vez de exponer el servidor directamente. Configura Nginx para pasar el tráfico del dominio a 127.0.0.1:3000, conservar Host y las cabeceras X-Forwarded-*, y gestiona HTTPS con el certificado de tu servidor. No abras el puerto 3000 a Internet: expón únicamente el proxy y SSH con acceso restringido.

Este ejemplo muestra el proxy HTTP local; ajusta los nombres del dominio y añade la configuración HTTPS de tu sistema:

server {
    listen 80;
    server_name example.com www.example.com;

    location / {
        proxy_pass http://127.0.0.1:3000;
        proxy_http_version 1.1;
        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;
    }
}

Después, comprueba desde fuera del VPS la portada, una ruta dinámica, una petición inválida, los archivos estáticos, los logs y una reinicialización del servicio. Next.js guarda parte de su caché en disco; en una única instancia puede funcionar con disco persistente, pero decide cómo respaldar o reconstruir esos datos. Varias instancias requieren tratar la caché compartida y la consistencia entre servidores.

Si tu Next.js solo genera archivos estáticos, no pagues por administrar un servidor que la aplicación no necesita. Si requiere SSR y quieres gestionar Node, Nginx y el sistema, empieza por el catálogo VPS; si prefieres publicar la imagen como servicio y el plan cubre tus recursos, revisa Projects y sus límites actuales. Para una aplicación genérica que no sea Next.js, consulta la guía para alojar Node.js.

Fuentes oficiales: desplegar Next.js, self-hosting, requisitos de instalación y opciones del CLI.