[{"data":1,"prerenderedAt":165},["ShallowReactive",2],{"seo-verification":3,"blog-desplegar-nextjs-en-un-vps-es":6},{"google":4,"bing":5},"EycwPY2XMyTkVzas3n1ygeNJFGAH513qrMjfDljzsMQ","",{"key":7,"data":8},"blog-desplegar-nextjs-en-un-vps-es",{"id":9,"slug":10,"slugs":11,"title":15,"excerpt":16,"readTime":17,"views":18,"isPinned":19,"publishedAt":20,"updatedAt":21,"category":22,"categories":28,"featuredImage":30,"bgImage":31,"posterImage":32,"relatedSolution":33,"intro":36,"sections":37,"ctaTitle":110,"ctaBody":111,"ctaButton":112,"ctaUrl":113,"relatedPosts":114},46,"desplegar-nextjs-en-un-vps",{"fr":12,"en":13,"ar":14,"es":10},"deployer-nextjs-vps","deploy-a-nextjs-application-on-a-vps","نشر-تطبيق-nextjs-على-vps","Desplegar una aplicación Next.js en un VPS","Despliegue Next.js en un VPS: Node.js, PM2, Nginx, SSL y SSR. Guía completa para desarrolladores y agencias que quieren autoalojar.",13,0,false,"2026-05-05T00:00:00+00:00","2026-09-11T11:34:12+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":27},4,"Desarrollo","developpement","bg-warning\u002F10 text-warning","dev",[29],{"id":23,"name":24,"slug":25,"color":26,"icon":27},null,"\u002Fblog\u002Fcovers\u002Fbg.svg","\u002Fblog\u002Fcovers\u002Fdeployer-nextjs-vps-poster.svg",{"categorySlug":34,"appSlug":35},"desarrollo","nextjs-stack","Next.js combina renderizado del lado del servidor, generación estática y rutas API en un único framework React. Desplegarlo en un VPS en lugar de en una plataforma propietaria le libera de las cuotas de funciones, de los límites de ancho de banda y del vendor lock-in, manteniendo el SSR plenamente operativo.",[38,42,52,55,58,61,83,86,89,92,95,98,101,104,107],{"type":39,"title":40,"body":41},"h2","¿Por qué autoalojar Next.js en un VPS?","Next.js suele asociarse a una plataforma de alojamiento concreta, pero su servidor Node.js standalone funciona perfectamente en cualquier VPS. El autoalojamiento resulta pertinente en cuanto usted utiliza de forma intensiva el SSR, la ISR (regeneración estática incremental) o las rutas API: estas funcionalidades consumen invocaciones facturadas en las plataformas gestionadas, mientras que son gratuitas e ilimitadas en su propio servidor. Usted controla la caché ISR en disco, el ancho de banda de las imágenes optimizadas y el tiempo de ejecución de las funciones, sin límite de 10 segundos.",{"type":43,"title":44,"items":45},"ul","Beneficios concretos de un Next.js autoalojado",[46,47,48,49,50,51],"SSR y rutas API sin cuota de invocaciones ni facturación por función.","Caché ISR persistente en disco, sin revalidaciones perdidas entre despliegues.","Ancho de banda incluido, ideal para sitios con muchas imágenes y vídeos.","Varios proyectos Next.js en un mismo VPS, agrupados bajo Nginx.","Optimización de imágenes `next\u002Fimage` servida localmente sin coste adicional por transformación.","Compilación y despliegue bajo control mediante Git, CI\u002FCD o un simple `git pull` y recompilación.",{"type":39,"title":53,"body":54},"Requisitos de hardware y software","La compilación de Next.js consume mucha memoria: prevea al menos 2 GB de RAM (4 GB para un proyecto grande con muchas páginas), ya que de lo contrario la compilación puede fallar por falta de memoria. Del lado del runtime, 1 o 2 vCPU bastan para servir el SSR. Instale Node.js 18 o 20 LTS, ya sea de forma nativa con `nvm` o mediante una imagen Docker `node:20-alpine`. Active `output: 'standalone'` en `next.config.js` para un despliegue ligero.",{"type":39,"title":56,"body":57},"Build Docker multi-stage: node:20-alpine","Un build Docker multi-stage reduce la imagen final a lo esencial y evita incluir las herramientas de compilación en producción. La estrategia de tres etapas — **deps**, **builder**, **runner** — es la más habitual para Next.js en modo `standalone`.\n\n```dockerfile\n# Etapa 1 — dependencias\nFROM node:20-alpine AS deps\nWORKDIR \u002Fapp\nCOPY package.json package-lock.json .\u002F\nRUN npm ci --omit=dev\n\n# Etapa 2 — compilación\nFROM node:20-alpine AS builder\nWORKDIR \u002Fapp\nCOPY --from=deps \u002Fapp\u002Fnode_modules .\u002Fnode_modules\nCOPY . .\nRUN npm run build\n\n# Etapa 3 — runner (imagen final)\nFROM node:20-alpine AS runner\nWORKDIR \u002Fapp\nENV NODE_ENV=production\nCOPY --from=builder \u002Fapp\u002F.next\u002Fstandalone .\u002F\nCOPY --from=builder \u002Fapp\u002F.next\u002Fstatic .\u002F.next\u002Fstatic\nCOPY --from=builder \u002Fapp\u002Fpublic .\u002Fpublic\nEXPOSE 3000\nCMD [\"node\", \"server.js\"]\n```\n\nLa etapa `deps` instala únicamente las dependencias de producción (`--omit=dev`). La etapa `builder` copia el código fuente completo y ejecuta `npm run build`. La etapa `runner` contiene solo la carpeta `standalone` generada por Next.js, los activos estáticos y la carpeta `public`.",{"type":39,"title":59,"body":60},"Variables de entorno: .env.local vs .env.production","Next.js distingue dos familias de variables según su alcance.\n\n**Variables públicas (`NEXT_PUBLIC_*`)**: se incluyen en el bundle JavaScript en tiempo de compilación y quedan expuestas al navegador. Adecuadas para una URL de API pública, un ID de Google Analytics o un indicador de funcionalidad. Nunca coloque secretos en ellas.\n\n**Variables de servidor**: se leen únicamente en el lado Node (rutas API, Server Components, `getServerSideProps`). Nunca se envían al cliente. Aquí viven las claves de API externas, las cadenas de conexión a la base de datos y los secretos JWT.\n\nEn el VPS, dos enfoques coexisten: inyectar las variables en el entorno del proceso PM2 mediante su archivo de ecosistema (`ecosystem.config.js`), o pasarlas a Docker con `--env-file .env.production`. El segundo es preferible: el archivo permanece en el disco del servidor, fuera del repositorio git.\n\nNota: las variables `NEXT_PUBLIC_*` deben conocerse **en tiempo de compilación**. Si cambia una variable pública tras el build, debe recompilar la aplicación.",{"type":62,"title":63,"steps":64},"steps","Desplegar Next.js paso a paso",[65,68,71,74,77,80],{"title":66,"body":67},"Preparar el servidor","Por SSH, instale Node.js 20 LTS y PM2 (`npm install -g pm2`), o Docker. Clone el repositorio y cree `.env.production` con sus variables (`NEXT_PUBLIC_*` para el cliente, secretos de servidor para las rutas API).",{"title":69,"body":70},"Compilar la aplicación","Ejecute `npm ci` y después `npm run build`. Con `output: 'standalone'`, Next.js genera una carpeta `.next\u002Fstandalone` autónoma que contiene únicamente las dependencias necesarias, lo que aligera notablemente la imagen.",{"title":72,"body":73},"Iniciar el servidor Node","Inicie el servidor con `pm2 start node --name nextjs -- .next\u002Fstandalone\u002Fserver.js` en el puerto 3000, o mediante un contenedor Docker. Configure `pm2 startup` y `pm2 save` para un reinicio automático al arrancar de nuevo el VPS.",{"title":75,"body":76},"Configurar Nginx como frontal","Cree un bloque de servidor que haga `proxy_pass http:\u002F\u002Flocalhost:3000`, transmita las cabeceras `Host` y `X-Forwarded-For`, y sirva directamente `\u002F_next\u002Fstatic\u002F` desde el disco para aliviar a Node. Active la compresión gzip.",{"title":78,"body":79},"Instalar el certificado SSL","Obtenga un certificado Let's Encrypt mediante Certbot para `votredomaine.com`, fuerce la redirección HTTPS y configure la renovación automática. Compruebe que las cabeceras `X-Forwarded-Proto` se transmiten correctamente para el SSR.",{"title":81,"body":82},"Implantar los despliegues","Automatice el ciclo `git pull && npm ci && npm run build && pm2 reload nextjs` mediante un script o un webhook de Git. El `reload` de PM2 garantiza un reinicio sin corte de servicio (zero-downtime) entre dos versiones.",{"type":39,"title":84,"body":85},"Configuración completa de Nginx con upstream","Un bloque Nginx completo para Next.js va más allá del `proxy_pass` mínimo. Es necesario servir los activos estáticos directamente desde el disco, gestionar las cabeceras de caché, activar la compresión y transmitir correctamente la información del cliente.\n\n```nginx\nupstream nextjs_upstream {\n  server 127.0.0.1:3000;\n  keepalive 64;\n}\n\nserver {\n  listen 443 ssl http2;\n  server_name yourdomain.com;\n\n  gzip on;\n  gzip_types text\u002Fplain text\u002Fcss application\u002Fjavascript application\u002Fjson image\u002Fsvg+xml;\n\n  location \u002F_next\u002Fstatic\u002F {\n    alias \u002Fhome\u002Fdeploy\u002Fmyapp\u002F.next\u002Fstatic\u002F;\n    expires 1y;\n    add_header Cache-Control \"public, immutable\";\n  }\n\n  location \u002F {\n    proxy_pass http:\u002F\u002Fnextjs_upstream;\n    proxy_http_version 1.1;\n    proxy_set_header Host $host;\n    proxy_set_header X-Real-IP $remote_addr;\n    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;\n    proxy_set_header X-Forwarded-Proto $scheme;\n  }\n}\n```\n\nEl bloque `upstream` con `keepalive 64` mantiene un grupo de conexiones persistentes hacia Node, evitando la negociación TCP en cada petición. La directiva `proxy_http_version 1.1` es obligatoria para que las conexiones keepalive funcionen realmente.",{"type":39,"title":87,"body":88},"Estrategia ISR: revalidación y persistencia de caché","La ISR (Incremental Static Regeneration) permite a Next.js regenerar una página estática en segundo plano tras un retardo dado, sin una recompilación completa. En un VPS, esto requiere que la caché sobreviva a los reinicios.\n\n```js\n\u002F\u002F app\u002Fproductos\u002F[id]\u002Fpage.tsx (App Router)\nexport const revalidate = 3600; \u002F\u002F regenerar cada hora\n```\n\nLa caché ISR se almacena en `.next\u002Fcache`. Dos opciones para que sobreviva a los redespliegues:\n\n**Opción 1 — volumen persistente**: monte `.next\u002Fcache` fuera de la carpeta de despliegue y restáurela tras cada rebuild.\n\n**Opción 2 — cache handler Redis**: para varias instancias Node o necesidad de compartir entre máquinas, Next.js soporta cache handlers personalizados desde la versión 13.4.\n\nPara sitios con poco tráfico, la opción 1 es suficiente. La opción 2 se vuelve necesaria con varios procesos Node (cluster PM2) o varios VPS detrás de un balanceador de carga.",{"type":39,"title":90,"body":91},"Server Components vs Client Components: impacto en RAM y CPU","Desde Next.js 13 y el App Router, los componentes son **Server Components por defecto**. La distinción tiene consecuencias directas sobre el consumo de recursos de su VPS.\n\n**Server Components** se ejecutan únicamente en el servidor. Pueden leer la base de datos directamente, acceder al sistema de archivos, y no se envían nunca al bundle JavaScript del navegador. El resultado es HTML puro, lo que reduce el tamaño del bundle del cliente y mejora los Core Web Vitals (LCP).\n\n**Client Components** (`'use client'` al principio del archivo) se hidratan en el navegador. Son necesarios para las interacciones del usuario: eventos, estado local, hooks (`useState`, `useEffect`).\n\nLa regla práctica en un VPS: **mantener los Server Components para todo lo que toca a los datos**, y limitar los Client Components a las zonas de interacción.",{"type":39,"title":93,"body":94},"CI\u002FCD: GitHub Actions o Forgejo","Automatizar el despliegue evita errores humanos y garantiza que cada fusión en la rama principal desencadene una recompilación limpia. Dos soluciones habituales en VPS: **GitHub Actions** (si su repositorio está en GitHub) y **Forgejo** (forge autoalojada, alternativa de código abierto a GitHub\u002FGitea).\n\n```yaml\nname: Deploy Next.js\non:\n  push:\n    branches: [main]\njobs:\n  deploy:\n    runs-on: ubuntu-latest\n    steps:\n      - name: Deploy via SSH\n        uses: appleboy\u002Fssh-action@v1\n        with:\n          host: ${{ secrets.VPS_HOST }}\n          username: deploy\n          key: ${{ secrets.VPS_SSH_KEY }}\n          script: |\n            cd \u002Fhome\u002Fdeploy\u002Fmyapp\n            git pull origin main\n            npm ci\n            npm run build\n            pm2 reload nextjs\n```\n\nEn ambos casos, los secretos se configuran en los secretos del repositorio y no aparecen nunca en los registros.",{"type":39,"title":96,"body":97},"Monitorización con PM2","PM2 es a la vez el gestor de procesos y la primera herramienta de monitorización de su aplicación Next.js. Comandos esenciales:\n\n```bash\n# Estado de los procesos\npm2 list\n\n# Registros en tiempo real\npm2 logs nextjs\n\n# Métricas de CPU y RAM\npm2 monit\n\n# Reinicio sin corte de servicio\npm2 reload nextjs\n```\n\nActive `pm2-logrotate` para evitar que los archivos de registro llenen el disco:\n\n```bash\npm2 install pm2-logrotate\npm2 set pm2-logrotate:max_size 50M\npm2 set pm2-logrotate:retain 7\n```\n\nEn producción, guarde la lista de procesos tras cada cambio: `pm2 save`.",{"type":99,"body":100},"tip","Si utiliza la ISR, monte un volumen persistente para la carpeta `.next\u002Fcache` a fin de que las páginas revalidadas sobrevivan a los redespliegues. Sin ello, cada recompilación parte de una caché vacía y provoca un pico de generación sobre la marcha. Para varias instancias Node detrás de un balanceador de carga, externalice esa caché hacia un almacenamiento compartido o Redis con un cache handler personalizado.",{"type":39,"title":102,"body":103},"Resolución de errores comunes en producción","Tres a cinco errores se repiten sistemáticamente en el primer despliegue de una aplicación Next.js en un VPS.\n\n**ENOMEM durante `npm run build`**\nAumente el límite de memoria de Node:\n\n```bash\nNODE_OPTIONS=\"--max-old-space-size=4096\" npm run build\n```\n\n**Port 3000 already in use**\nIdentifique y detenga el proceso que ocupa el puerto:\n\n```bash\nlsof -i :3000\nkill -9 \u003CPID>\n```\n\n**MODULE_NOT_FOUND en producción con `output: 'standalone'`**\nCopie las tres carpetas necesarias:\n\n```bash\ncp -r .next\u002Fstatic .next\u002Fstandalone\u002F.next\u002Fstatic\ncp -r public .next\u002Fstandalone\u002Fpublic\n```\n\n**Bucle de redirección HTTPS con `X-Forwarded-Proto`**\nAsegúrese de que Nginx reenvía `X-Forwarded-Proto: https` y de que su aplicación lee esta cabecera para determinar el protocolo real.",{"type":39,"title":105,"body":106},"Copia de seguridad de .next\u002Fcache","La carpeta `.next\u002Fcache` contiene dos tipos de datos valiosos: las páginas ISR revalidadas y la caché de compilación de Webpack\u002FSWC. Perder esta caché obliga a Next.js a regenerar todas las páginas ISR al primer acceso, lo que puede generar un pico de carga.\n\nEstablezca una copia de seguridad sencilla con `rsync` o `tar` antes de cada despliegue. La caché de Webpack acelera notablemente las recompilaciones posteriores — en un proyecto mediano, una recompilación con caché completa tarda entre un 40 y un 60 % menos que una compilación en frío.",{"type":39,"title":108,"body":109},"Desplegar Next.js con un clic desde el Marketplace","El Marketplace de ServOrbit ofrece una plantilla **Next.js Stack** que configura automáticamente Node.js LTS, PM2, Nginx y PostgreSQL en su VPS. En unos minutos, su entorno de producción está listo para recibir su aplicación React SSR — sin configuración manual.\n\nFrente a la instalación descrita en esta guía, la plantilla se encarga de la puesta en marcha inicial y le permite empezar directamente en el paso «desplegar su código».","Su entorno Next.js listo en unos minutos","La plantilla Next.js Stack configura automáticamente Node.js LTS, PM2, Nginx y PostgreSQL — lista para recibir su aplicación React SSR.","Desplegar mi Next.js Stack","\u002Fmarketplace\u002Fdesarrollo\u002Fnextjs-stack",[115,132,149],{"id":116,"slug":117,"slugs":118,"title":122,"excerpt":123,"readTime":23,"views":18,"isPinned":19,"publishedAt":124,"updatedAt":125,"category":126,"categories":127,"featuredImage":30,"bgImage":31,"posterImage":129,"relatedSolution":130},5,"desplegar-laravel-en-un-vps",{"fr":119,"en":120,"ar":121,"es":117},"deployer-laravel-vps","deploying-laravel-on-a-vps-a-production-guide","نشر-laravel-على-خادم-vps-دليل-الإنتاج","Desplegar Laravel en un VPS: guía de producción","Ponga Laravel en producción en un VPS: PHP, workers, caché, base de datos, reverse proxy y HTTPS bien configurados.","2026-02-09T00:00:00+00:00","2026-09-07T11:26:10+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":27},[128],{"id":23,"name":24,"slug":25,"color":26,"icon":27},"\u002Fblog\u002Fcovers\u002Fdeployer-laravel-vps-poster.svg",{"categorySlug":27,"appSlug":131},"laravel-stack",{"id":133,"slug":134,"slugs":135,"title":139,"excerpt":140,"readTime":141,"views":18,"isPinned":19,"publishedAt":142,"updatedAt":125,"category":143,"categories":144,"featuredImage":30,"bgImage":31,"posterImage":146,"relatedSolution":147},43,"desplegar-una-aplicacion-nodejs-en-un-vps",{"fr":136,"en":137,"ar":138,"es":134},"deployer-nodejs-vps","deploy-a-nodejs-application-on-a-vps","نشر-تطبيق-nodejs-على-vps","Desplegar una aplicación Node.js en un VPS","Despliegue una aplicación Node.js en producción en un VPS: PM2, reverse proxy Nginx, SSL Let's Encrypt y arranque automático con el sistema.",3,"2026-05-08T00:00:00+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":27},[145],{"id":23,"name":24,"slug":25,"color":26,"icon":27},"\u002Fblog\u002Fcovers\u002Fdeployer-nodejs-vps-poster.svg",{"categorySlug":34,"appSlug":148},"nodejs-stack",{"id":150,"slug":151,"slugs":152,"title":156,"excerpt":157,"readTime":141,"views":116,"isPinned":19,"publishedAt":158,"updatedAt":125,"category":159,"categories":160,"featuredImage":30,"bgImage":31,"posterImage":162,"relatedSolution":163},44,"desplegar-una-aplicacion-django-en-un-vps",{"fr":153,"en":154,"ar":155,"es":151},"deployer-django-vps","deploy-a-django-application-on-a-vps","نشر-تطبيق-django-على-vps","Desplegar una aplicación Django en un VPS","Despliegue Django en un VPS: Gunicorn, Nginx, PostgreSQL, Docker y SSL. Guía completa para desarrolladores Python que quieren autoalojar.","2026-05-07T00:00:00+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":27},[161],{"id":23,"name":24,"slug":25,"color":26,"icon":27},"\u002Fblog\u002Fcovers\u002Fdeployer-django-vps-poster.svg",{"categorySlug":34,"appSlug":164},"django",1789665016198]