Guía de despliegue

Desplegar Nuxt en un VPS: SSR, rutas API y control total

Desplegar en un VPS Cloud →

Tutorial

Desplegar Nuxt en un VPS: SSR, rutas API y control total

Desarrollo9 min de lectura6 pasos

Nuxt puede servir un sitio estático, una aplicación SSR o una capa API a través de Nitro; el modo elegido cambia los requisitos del servidor. En un VPS de ServOrbit, controlas el runtime de Node, las variables y el proxy en lugar de soportar las limitaciones de una plataforma cerrada. Esta guía cubre el camino completo: elección del modo de renderizado, build, servicio PM2, dominio, HTTPS, variables de entorno, caché HTTP y monitorización de logs.

Contenido· ¿Por qué alojar Nuxt en un VPS?1/9
  1. 01¿Por qué alojar Nuxt en un VPS?
  2. 02SSR, SSG o SPA: ¿qué modo de renderizado elegir para tu proyecto Nuxt?
  3. 03Lo que puedes hacer con Nuxt en un VPS
  4. 04Capacidades concretas en VPS
  5. 05Instalar y desplegar Nuxt en tu VPS de ServOrbit
  6. 06Variables de entorno y configuración runtime de Nuxt 3
  7. 07Monitorizar logs y diagnosticar errores
  8. 08Diagnosticar problemas comunes
  9. 09Documentación oficial

¿Por qué alojar Nuxt en un VPS?

Las plataformas de alojamiento compartido no soportan Node.js de forma nativa, lo que hace imposible el autoalojamiento de una aplicación Nuxt sin un VPS o servidor dedicado. Un VPS te permite elegir la versión de Node.js que quieras, configurar un reverse proxy (Nginx o Caddy) en el puerto de tu elección y gestionar tus propios certificados TLS — todo sin limitaciones artificiales de CPU o memoria. Es la solución ideal para desarrolladores independientes y PYMEs que quieren controlar su stack de extremo a extremo.

A diferencia de las soluciones PaaS o serverless, un VPS no factura por ejecución ni limita los tiempos de respuesta: una llamada a la API que tarde muy por debajo del segundo no genera ningún coste adicional. Además conservas el control total sobre las cabeceras HTTP, la caché de borde y la configuración TLS.

SSR, SSG o SPA: ¿qué modo de renderizado elegir para tu proyecto Nuxt?

Desplace la tabla

ModoRenderizadoProceso Node necesarioIdeal para
SSR (ssr: true)Por solicitud, del lado del servidorSí — PM2 permanenteApp dinámica, SEO, contenido personalizado
SSG (nuxt generate)En build, HTML estáticoNo — nginx es suficienteBlog, landing page, contenido poco actualizado
SPA (ssr: false)En el navegadorNo — nginx es suficienteDashboard interno, app tras autenticación
Hybrid (routeRules)Por ruta: SSR + SSG mezcladosSí — servidor NitroApp con páginas estáticas y rutas API

Lo que puedes hacer con Nuxt en un VPS

Un VPS de ServOrbit con la plantilla Nuxt preconfigurada te abre cuatro dimensiones que el hosting compartido o las plataformas PaaS cierran:

Capacidades concretas en VPS

  • Servir una aplicación Nuxt en modo SSR para un SEO óptimo y tiempos de carga reducidos — PM2 mantiene el proceso Nitro activo y lo reinicia automáticamente tras un fallo o reinicio del servidor
  • Desplegar un sitio estático generado con nuxt generate y servirlo a través de Nginx sin proceso Node.js permanente — ideal para blogs o landings con poca frecuencia de actualización
  • Alojar múltiples proyectos Nuxt en el mismo VPS gracias a un reverse proxy y Virtual Hosts de Nginx — cada aplicación corre en su propio puerto interno (3000, 3001…)
  • Configurar variables de entorno sensibles (claves API, conexiones DB) directamente en el servidor en /etc/environment o mediante un archivo .env fuera del repositorio Git
  • Habilitar las rutas API de Nitro (server/api/) para exponer una capa backend ligera desde el mismo proceso Node.js, sin un servidor Express separado
  • Automatizar despliegues con un archivo ecosystem de PM2, webhooks de GitHub o un pipeline CI/CD apuntando a tu VPS por SSH
  • Activar HTTPS automáticamente con Let's Encrypt vía Certbot para proteger a tus usuarios sin coste de certificado

Instalar y desplegar Nuxt en tu VPS de ServOrbit

  1. Contratar un VPS Cloud de ServOrbit

    Ve a la página /vps-cloud y elige el plan adecuado para tu proyecto. Para una aplicación Nuxt en modo SSR, planea al menos 1 vCPU y 1 GB de RAM; 2 GB absorben cómodamente el proceso Nitro, un reverse proxy y los picos de compilación durante los despliegues. Si alojas múltiples aplicaciones Nuxt, empieza con 2 vCPU / 4 GB. Completa el pedido y accede a tu portal de cliente una vez entregado el VPS — normalmente en menos de un minuto.

  2. Instalar Nuxt desde el Marketplace

    Inicia sesión en tu portal de cliente de ServOrbit, navega a la sección Marketplace desde el dashboard de tu VPS y busca Nuxt. Haz clic en la tarjeta y confirma la instalación. El script configura automáticamente Node.js LTS, PM2 como gestor de procesos y Nginx como reverse proxy en el puerto 80 (y 443 si se proporciona un dominio). La operación tarda menos de dos minutos.

  3. Desplegar tu aplicación y configurar las variables de entorno

    Conéctate por SSH (ssh root@<IP-del-VPS>), luego clona tu repositorio en el directorio preparado:

    git clone https://github.com/tu-org/tu-app.git /var/www/nuxt-app
    cd /var/www/nuxt-app
    npm install

    Crea un archivo .env fuera de tu repositorio Git con tus variables de runtime:

    NUXT_PUBLIC_API_BASE=https://api.your-domain.com
    NUXT_SECRET_KEY=your-private-key
    DATABASE_URL=postgres://user:pass@localhost/mydb

    Nuxt 3 lee las variables con prefijo NUXT_ a través de useRuntimeConfig() — las variables NUXT_PUBLIC_* se exponen del lado del cliente, las demás solo en el servidor. Nunca hagas commit del archivo .env: añádelo a .gitignore desde el principio.

  4. Construir la aplicación y lanzarla con PM2

    Compila la aplicación para producción:

    npm run build

    Nuxt 3 genera la carpeta .output/ con el servidor Nitro. Lánzalo con PM2 en modo cluster para usar todos los núcleos CPU:

    pm2 start .output/server/index.mjs -i max --name nuxt-app
    pm2 save
    pm2 startup

    El comando pm2 startup genera la línea systemd para ejecutar y que PM2 arranque automáticamente al reiniciar el servidor. Verifica el estado: pm2 status — las instancias deben estar online. Para recargas sin tiempo de inactividad durante los despliegues: pm2 reload nuxt-app.

  5. Configurar Nginx como reverse proxy y apuntar tu dominio

    La plantilla del Marketplace instala un Virtual Host de Nginx listo para usar en /etc/nginx/sites-available/nuxt-app. Edítalo para especificar tu nombre de dominio y habilitar el caché de activos estáticos:

    server {
        server_name your-domain.com;
    
        location / {
            proxy_pass http://127.0.0.1:3000;
            proxy_http_version 1.1;
            proxy_set_header Host $host;
            proxy_cache_bypass $http_upgrade;
        }
    
        location /_nuxt/ {
            proxy_pass http://127.0.0.1:3000;
            expires 1y;
            add_header Cache-Control "public, immutable";
        }
    }

    Apunta tu registro DNS A a la IP del VPS, luego ejecuta Certbot para obtener un certificado TLS gratuito: certbot --nginx -d your-domain.com. Recarga Nginx: nginx -s reload. Tu aplicación Nuxt ya está disponible por HTTPS.

  6. Automatizar los despliegues siguientes

    Para actualizaciones, crea un script de despliegue en /var/www/nuxt-app/deploy.sh:

    #!/bin/bash
    set -e
    cd /var/www/nuxt-app
    git pull origin main
    npm install --production=false
    npm run build
    pm2 reload nuxt-app
    echo "Despliegue completado"

    Hazlo ejecutable (chmod +x deploy.sh) y lánzalo desde tu pipeline CI/CD por SSH: ssh root@<IP> /var/www/nuxt-app/deploy.sh. pm2 reload (no restart) garantiza una transición fluida — PM2 espera a que cada nueva instancia esté lista antes de cortar la antigua.

Variables de entorno y configuración runtime de Nuxt 3

Nuxt 3 distingue dos niveles de variables a través de useRuntimeConfig():

- runtimeConfig.public.* → disponibles en el cliente y en el servidor (p. ej. URL de API pública, claves de seguimiento)
- runtimeConfig.* (no público) → solo en el servidor (p. ej. claves secretas, credenciales DB)

Las variables de entorno las sobreescriben automáticamente en runtime siguiendo la convención NUXT_<NOMBRE>. Esto significa que no necesitas recompilar para cambiar una URL de API o una clave de acceso: basta con modificar el archivo .env en el servidor y recargar PM2 (pm2 reload nuxt-app). Especialmente útil para entornos múltiples (staging, producción) que comparten el mismo artefacto de build.

Para secretos críticos (tokens de DB, claves de cifrado), prefiere las variables del sistema en /etc/environment sobre un archivo .env en el directorio de la aplicación.

Monitorizar logs y diagnosticar errores

PM2 centraliza los logs de tu aplicación Nuxt en tiempo real. Comandos clave:

pm2 logs nuxt-app          # flujo en directo (stdout + stderr)
pm2 logs nuxt-app --lines 100  # últimas 100 líneas
pm2 monit                  # dashboard CPU / memoria en tiempo real

Los logs se persisten en ~/.pm2/logs/. Configura la rotación de logs para evitar llenar el disco:

pm2 install pm2-logrotate
pm2 set pm2-logrotate:max_size 50M
pm2 set pm2-logrotate:retain 7

Para errores de Nginx (502, 503 cuando PM2 está caído), consulta /var/log/nginx/error.log. Un error 502 persistente generalmente indica que el proceso PM2 no está corriendo (pm2 status) o que el puerto 3000 no es accesible desde el proxy.

Diagnosticar problemas comunes

Tres situaciones aparecen con frecuencia al desplegar una aplicación Nuxt en un VPS:

Error 502 Bad Gateway. Nginx no puede alcanzar el proceso Nitro en el puerto 3000. Causas habituales: pm2 start no se ha ejecutado o se ha detenido (pm2 status para verificar), el puerto 3000 está bloqueado por el firewall (ufw allow 3000 temporalmente para probar), o la aplicación falló al arrancar (pm2 logs nuxt-app --lines 50 para leer el último error).

Variables de entorno sin resolver. useRuntimeConfig() devuelve undefined en el cliente para una variable que debería ser pública. Verifica que la variable tiene el prefijo NUXT_PUBLIC_ en tu archivo .env, y que has recargado PM2 tras el cambio: pm2 reload nuxt-app. Las variables de entorno solo se leen cuando arranca el proceso Nitro, no en tiempo real.

Página en blanco en producción tras nuxt generate. El HTML estático se muestra pero los datos dinámicos están vacíos. No es un problema de servidor — es un problema de baseURL: en el lado servidor durante el prerender, un $fetch con ruta relativa no tiene origen. Pasa la URL completa de tu API en NUXT_PUBLIC_API_BASE y usa useAsyncData con useFetch especificando esa base explícitamente en las páginas que requieren contenido rastreable.

Consejo de rendimiento: modo cluster de PM2. El comando pm2 start .output/server/index.mjs -i max --name nuxt-app arranca tantas instancias como núcleos CPU disponibles y distribuye automáticamente la carga entre ellas. En un VPS de 2 vCPU obtienes dos workers Nitro activos, duplicando el rendimiento en rutas SSR. Verifica con pm2 status que todas las instancias están online.

Documentación oficial

Para la configuración avanzada, las opciones propias de la herramienta y los cambios de versión, consulta la documentación oficial de Nuxt. Esta guía cubre la puesta en línea en un VPS de ServOrbit; la documentación del editor sigue siendo la referencia para los ajustes finos (routeRules, Nitro presets, módulos oficiales).

Despliegue Nuxt en pocos minutos en un VPS Cloud ServOrbit

Disfrute de un VPS Cloud de alta disponibilidad con instalación de Nuxt en 1 clic, Node.js preconfigurado y soporte ágil, sin sorpresas desagradables en la factura.

¿Necesita ayuda?

Consulte nuestro centro de ayuda y nuestra FAQ, o contacte con nuestro equipo: llamada, WhatsApp o correo electrónico. Soporte en francés, inglés y árabe.

Escribir por WhatsAppse abre en una pestaña nueva