¿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
| Modo | Renderizado | Proceso Node necesario | Ideal para |
|---|---|---|---|
| SSR (ssr: true) | Por solicitud, del lado del servidor | Sí — PM2 permanente | App dinámica, SEO, contenido personalizado |
| SSG (nuxt generate) | En build, HTML estático | No — nginx es suficiente | Blog, landing page, contenido poco actualizado |
| SPA (ssr: false) | En el navegador | No — nginx es suficiente | Dashboard interno, app tras autenticación |
| Hybrid (routeRules) | Por ruta: SSR + SSG mezclados | Sí — servidor Nitro | App 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 generatey 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/environmento mediante un archivo.envfuera 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
Contratar un VPS Cloud de ServOrbit
Ve a la página
/vps-cloudy 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.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.
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 installCrea un archivo
.envfuera 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/mydbNuxt 3 lee las variables con prefijo
NUXT_a través deuseRuntimeConfig()— las variablesNUXT_PUBLIC_*se exponen del lado del cliente, las demás solo en el servidor. Nunca hagas commit del archivo.env: añádelo a.gitignoredesde el principio.Construir la aplicación y lanzarla con PM2
Compila la aplicación para producción:
npm run buildNuxt 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 startupEl comando
pm2 startupgenera la línea systemd para ejecutar y que PM2 arranque automáticamente al reiniciar el servidor. Verifica el estado:pm2 status— las instancias deben estaronline. Para recargas sin tiempo de inactividad durante los despliegues:pm2 reload nuxt-app.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.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(norestart) 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 realLos 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 7Para 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).