[{"data":1,"prerenderedAt":215},["ShallowReactive",2],{"seo-verification":3,"blog-desplegar-nuxt-en-un-vps-ma-es":6,"promo-bar-likely":214},{"google":4,"bing":5},"EycwPY2XMyTkVzas3n1ygeNJFGAH513qrMjfDljzsMQ","",{"key":7,"data":8},"blog-desplegar-nuxt-en-un-vps-ma-es",{"id":9,"slug":10,"slugs":11,"title":15,"excerpt":16,"readTime":17,"views":18,"isPinned":19,"noindex":19,"publishedAt":20,"updatedAt":21,"category":22,"categories":28,"featuredImage":30,"bgImage":31,"posterImage":32,"relatedSolution":33,"intro":36,"sections":37,"ctaTitle":156,"ctaBody":157,"ctaButton":158,"ctaUrl":159,"relatedPosts":160},47,"desplegar-nuxt-en-un-vps",{"fr":12,"en":13,"ar":14,"es":10},"deployer-nuxt-vps","deploy-a-nuxt-application-on-a-vps","نشر-تطبيق-nuxt-على-vps","Desplegar una aplicación Nuxt en un VPS","Desplegar Nuxt en un VPS: Nitro, PM2, Nginx, SSL, modos de renderizado, routeRules, variables de entorno y errores de producción.",12,1,false,"2026-05-04T00:00:00+00:00","2026-11-08T01:13: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-nuxt-vps-poster.svg",{"categorySlug":34,"appSlug":35},"desarrollo","nuxt-stack","Nuxt y su motor Nitro producen un artefacto Node.js autónomo, perfectamente adaptado al autoalojamiento en un VPS. Este enfoque le libera de las cuotas de funciones cloud y le da control total sobre la caché, las cabeceras HTTP y las estrategias de renderizado página a página. Esta guía cubre la instalación completa: elección del modo de renderizado, configuración del proyecto, build, variables de entorno, supervisión con PM2, proxy inverso Nginx y HTTPS, registros, hasta la resolución de los errores que bloquean la producción.",[38,42,54,83,86,89,114,117,120,143,146,149,153],{"type":39,"title":40,"body":41},"h2","¿Por qué autoalojar Nuxt en un VPS?","Con Nitro, Nuxt genera un build portable (`preset: node-server`) que arranca como un simple servidor Node a la escucha en un puerto. Esta portabilidad es ideal para un VPS: dispone del renderizado del lado del servidor, de las rutas `server\u002Fapi` y de la caché de rutas sin depender de un runtime edge propietario.\n\nEl autoalojamiento elimina las cuotas de funciones y le permite ajustar el almacenamiento en caché, la compresión y el número de instancias Node. Para una aplicación Vue 3 en producción con autenticación, llamadas a API de servidor y un SEO cuidado, el VPS ofrece la estabilidad de un servidor persistente y un costo fijo, sin sorpresas de facturación por invocación.\n\nAun así, hace falta un servidor que acepte un proceso Node.js permanente: la mayoría de los alojamientos compartidos no lo permiten, lo que descarta desde el principio el SSR y las rutas de servidor. En un VPS también elige la versión de Node.js, el proxy inverso (Nginx o Caddy) y la gestión de los certificados TLS, sin un tope artificial de CPU o memoria.",{"type":43,"title":44,"items":45},"ul","Beneficios concretos de un Nuxt autoalojado",[46,47,48,49,50,51,52,53],"Rutas de servidor `server\u002Fapi` ilimitadas, sin facturación por llamada.","SSR e hidratación Vue 3 servidos desde un servidor Node persistente y estable.","Build Nitro portable (`node-server`), fácil de contenerizar y de reproducir.","Caché de rutas y reglas `routeRules` (SSR, SSG, ISR, SWR) controladas desde el servidor.","Varias apps Nuxt en un mismo VPS detrás de Nginx, cada una en su puerto interno (3000, 3001…).","Variables de entorno en runtime (`runtimeConfig`) gestionadas directamente en su servidor.","Control total sobre las cabeceras HTTP (CSP, HSTS, cache-control) vía middleware Nitro.","Un sitio pregenerado con `nuxt generate`, servido solo por Nginx, sin proceso Node.js permanente.",{"type":55,"title":56,"headers":57,"rows":62},"comparison","SSR, SSG, SPA o híbrido: ¿qué modo de renderizado elegir?",[58,59,60,61],"Modo","Renderizado","Proceso Node.js","Ideal para",[63,68,73,78],[64,65,66,67],"SSR (por defecto)","En cada petición, en el servidor","Sí, supervisado por PM2","Aplicación dinámica, SEO, contenido personalizado",[69,70,71,72],"SSG (`nuxt generate`)","En el build, como HTML estático","No, Nginx sirve `.output\u002Fpublic`","Blog, web corporativa, contenido que cambia poco",[74,75,76,77],"SPA (`ssr: false` + `nuxt generate`)","En el navegador","No, basta con Nginx","Panel interno, aplicación tras autenticación",[79,80,81,82],"Híbrido (`routeRules`)","Por ruta: SSR, prerenderizado, SWR, ISR","Sí, servidor Nitro","Aplicación que mezcla páginas estáticas y rutas API",{"type":39,"title":84,"body":85},"Requisitos de hardware y software","Como con cualquier framework moderno, el build de Nuxt consume memoria: apunte a 2 GB de RAM como mínimo (el build puede hacerse en CI si su VPS es más modesto). En runtime, 1 vCPU y 1 GB bastan para el servidor Nitro con carga ligera; suba a 2 vCPU \u002F 2 GB para aplicaciones con muchas rutas `server\u002Fapi` simultáneas, y a 2 vCPU \u002F 4 GB si varias aplicaciones Nuxt comparten el VPS.\n\nEn cuanto a versiones, parta de Nuxt 4: Nuxt 3 llegó al final de su vida útil el 31 de julio de 2026 y ya no recibe correcciones ni parches de seguridad. El despliegue descrito aquí es el mismo para ambas versiones, ya que es Nitro quien produce el servidor. Instale una línea LTS de Node.js que siga mantenida, Node.js 24 o 26 (Node.js 20 está fuera de soporte desde el 30 de abril de 2026), mediante `nvm` o una imagen `node:24-alpine`, junto con PM2 para la supervisión de procesos. `node-server` es el preset que Nitro aplica por defecto a un build de producción: declararlo en `nuxt.config.ts` solo lo hace explícito. Se requiere un dominio que apunte a su VPS para el certificado TLS. Ubuntu 22.04 o 24.04 LTS sigue siendo la base recomendada.",{"type":39,"title":87,"body":88},"Partir de la plantilla Nuxt Stack","La plantilla Nuxt Stack del Marketplace de ServOrbit prepara un VPS Ubuntu 24.04 con Node.js en la línea LTS actual del repositorio de NodeSource, PM2 instalado de forma global, Nginx y PostgreSQL. Le ahorra la instalación del runtime: los pasos siguientes empiezan entonces en la configuración del proyecto.\n\nEs un entorno de ejecución, no una aplicación con pantalla de inicio de sesión: se accede por SSH (`ssh root@\u003Cip-del-vps>`) para subir el código. En el primer acceso, Nginx sirve su página por defecto en el puerto 80; quedan por preparar el virtual host de su aplicación, el certificado de Let's Encrypt (Certbot no viene preinstalado) y su código. PostgreSQL solo escucha en local, con autenticación peer para el usuario del sistema `postgres` (`sudo -u postgres psql`): suficiente para conectar una `DATABASE_URL` en `127.0.0.1` sin exponer la base de datos.",{"type":90,"title":91,"steps":92},"steps","Desplegar Nuxt paso a paso",[93,96,99,102,105,108,111],{"title":94,"body":95},"Configurar el proyecto para Node","Defina el preset Nitro en `nuxt.config.ts`:\n\n```ts\nexport default defineNuxtConfig({\n  nitro: { preset: 'node-server' }\n})\n```\n\nDeclare sus secretos en `runtimeConfig` únicamente en el lado del servidor — nunca en `runtimeConfig.public`. En el VPS, instale Node.js 24 LTS con `nvm install 24 && nvm use 24 && nvm alias default 24`, luego PM2 de forma global: `npm install -g pm2`. En la plantilla Nuxt Stack, Node.js y PM2 ya están instalados.",{"title":97,"body":98},"Compilar la aplicación","Clone el repositorio e instale las dependencias:\n\n```bash\ngit clone https:\u002F\u002Fgit.sudominio.com\u002Fsu-org\u002Fsu-app.git \u002Fsrv\u002Fnuxt-app\ncd \u002Fsrv\u002Fnuxt-app\nnpm ci\nnpm run build\n```\n\nNitro produce una carpeta `.output` autónoma que contiene `server\u002Findex.mjs` y los assets estáticos en `.output\u002Fpublic`. Esa carpeta es todo lo que el VPS necesita para servir la aplicación en producción — también puede ensamblarla en CI y transferirla por rsync para evitar el build en el servidor.",{"title":100,"body":101},"Crear el archivo de entorno","Cree `\u002Fsrv\u002Fnuxt-app\u002F.env` con sus variables de runtime. Todas las variables con prefijo `NUXT_` sobreescriben las claves correspondientes de `runtimeConfig` al arrancar:\n\n```bash\nNUXT_MY_SECRET_KEY=valor-produccion\nNITRO_HOST=127.0.0.1\nNITRO_PORT=3000\n```\n\nNunca incluya este archivo en el repositorio. Asegúrese de que pertenece al usuario que ejecuta PM2 y solo es legible por ese usuario (`chmod 600`).\n\nCon `NITRO_HOST=127.0.0.1`, Nitro solo escucha en la interfaz local: únicamente Nginx puede alcanzarlo y el puerto 3000 no queda expuesto a Internet.",{"title":103,"body":104},"Arrancar el servidor Nitro con PM2","Inicie la aplicación en modo cluster pidiendo a Node que cargue el archivo de entorno: Nuxt no lee `.env` en producción y la línea de comandos de PM2 no tiene una opción dedicada.\n\n```bash\npm2 start \u002Fsrv\u002Fnuxt-app\u002F.output\u002Fserver\u002Findex.mjs \\\n  --name nuxt-app -i max \\\n  --node-args=\"--env-file=\u002Fsrv\u002Fnuxt-app\u002F.env\"\npm2 save\npm2 startup\n```\n\n`-i max` lanza una instancia por vCPU; este modo cluster es lo que permite las recargas sin corte del último paso. El comando `pm2 startup` muestra una línea para copiar y pegar que crea el servicio systemd. Ejecútela con permisos de administrador. Verifique que la aplicación está en línea: `pm2 status` debe mostrar el estado `online`.",{"title":106,"body":107},"Configurar Nginx como reverse proxy","Cree `\u002Fetc\u002Fnginx\u002Fsites-available\u002Fnuxt-app`:\n\n```nginx\nserver {\n    listen 80;\n    server_name sudominio.com www.sudominio.com;\n\n    location \u002F_nuxt\u002F {\n        root \u002Fsrv\u002Fnuxt-app\u002F.output\u002Fpublic;\n        expires 1y;\n        add_header Cache-Control \"public, immutable\";\n    }\n\n    location \u002Ffavicon.ico {\n        root \u002Fsrv\u002Fnuxt-app\u002F.output\u002Fpublic;\n    }\n\n    location \u002F {\n        proxy_pass http:\u002F\u002F127.0.0.1:3000;\n        proxy_http_version 1.1;\n        proxy_set_header Upgrade $http_upgrade;\n        proxy_set_header Connection 'upgrade';\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        proxy_cache_bypass $http_upgrade;\n    }\n}\n```\n\nActive el sitio y pruebe la configuración: `ln -s \u002Fetc\u002Fnginx\u002Fsites-available\u002Fnuxt-app \u002Fetc\u002Fnginx\u002Fsites-enabled\u002F && nginx -t && systemctl reload nginx`.",{"title":109,"body":110},"Activar HTTPS con Let's Encrypt","Instale Certbot y el plugin de Nginx, luego genere el certificado:\n\n```bash\napt install certbot python3-certbot-nginx\ncertbot --nginx -d sudominio.com -d www.sudominio.com\n```\n\nCertbot modifica automáticamente el bloque Nginx para escuchar en el puerto 443 y forzar la redirección HTTP → HTTPS. Verifique que `X-Forwarded-Proto` se transmite correctamente a Nitro — sin ello, `useRequestHeaders()` en el lado del servidor y las redirecciones basadas en el protocolo pueden comportarse incorrectamente. La renovación automática la gestiona el timer systemd de Certbot, comprobable con `systemctl status certbot.timer`.",{"title":112,"body":113},"Actualizar sin interrupción del servicio","Para una actualización, el reload de PM2 (no el restart) garantiza la continuidad. Agrupe los comandos en un script `\u002Fsrv\u002Fnuxt-app\u002Fdeploy.sh`, que `set -e` detiene en el primer error, antes de cualquier recarga:\n\n```bash\n#!\u002Fbin\u002Fbash\nset -e\ncd \u002Fsrv\u002Fnuxt-app\ngit pull origin main\nnpm ci\nnpm run build\npm2 reload nuxt-app\n```\n\nHágalo ejecutable (`chmod +x deploy.sh`) y llámelo desde su pipeline de CI\u002FCD por SSH. En modo cluster, PM2 sustituye las instancias una a una: la nueva versión toma el relevo antes de que se detenga la antigua. Para un rollback, vuelva al commit anterior, reconstruya y recargue. Si el build se hace en CI, transfiera únicamente la carpeta `.output` por rsync y recargue sin reconstruir en el servidor.",{"type":39,"title":115,"body":116},"Variables de entorno: públicas, privadas y recarga","Nuxt organiza su configuración de ejecución en dos niveles. Las claves situadas bajo `runtimeConfig.public` se envían al navegador y siguen siendo legibles en el servidor: URL pública de la API, identificador de analítica. Las demás claves de `runtimeConfig` nunca salen del servidor: claves secretas, acceso a la base de datos.\n\nAl arrancar, una variable de entorno sustituye a la clave correspondiente si sigue la convención `NUXT_\u003CNOMBRE>`, o `NUXT_PUBLIC_\u003CNOMBRE>` para una clave pública: `NUXT_PUBLIC_API_BASE` reemplaza `runtimeConfig.public.apiBase`. Un valor leído de otra forma, por ejemplo `process.env.OTRA_VARIABLE` escrito en `nuxt.config.ts`, solo se toma durante el build y queda congelado en el artefacto.\n\nEn la práctica, cambiar una URL de API o una clave no exige reconstruir: se modifica el `.env` en el servidor y se recarga PM2 (`pm2 reload nuxt-app`). La misma carpeta `.output` puede así servir preproducción y producción con dos archivos de entorno distintos. La única condición es que el proceso cargue ese archivo, ya que Nuxt deja de leer `.env` una vez construida la aplicación: de ahí la opción `--env-file` que se pasa a Node al arrancar con PM2.",{"type":39,"title":118,"body":119},"Optimizar el renderizado con routeRules","Una de las fortalezas de Nuxt en un VPS es la granularidad de las estrategias de renderizado página a página, sin cambiar de infraestructura. En `nuxt.config.ts`, las `routeRules` permiten mezclar SSR, SSG, ISR y SWR en un único despliegue Nitro.\n\nLas páginas estáticas (blog, avisos legales, landing pages) pueden pregenerarse en el build con `prerender: true`: Nitro las sirve desde disco, sin Node. Las páginas semi-dinámicas (listas de productos, dashboards públicos) se benefician de `swr: 60` para una caché de un minuto invalidada en segundo plano. El SSR completo queda reservado para las páginas personalizadas que dependen de la sesión o del perfil del usuario.\n\nEste enfoque reduce la carga sobre Node sin necesitar un CDN de pago o una capa de caché externa — su Nginx almacena lo que Nitro pregenera.",{"type":55,"title":121,"headers":122,"rows":126},"Nitro server vs Docker vs Vercel\u002FNetlify para alojar Nuxt",[123,124,125],"Enfoque","Ventajas","Limitaciones",[127,131,135,139],[128,129,130],"Nitro `node-server` + PM2","Simple, ligero, recarga sin downtime, costo fijo VPS","Supervisión a gestionar, servidor único sin alta disponibilidad nativa",[132,133,134],"Docker en VPS","Aislamiento, reproducibilidad, rollback por imagen, compose multi-app","Imagen a construir y almacenar, memoria adicional por contenedor",[136,137,138],"Vercel \u002F Netlify","Configuración cero, CDN edge global, previews por PR","Cuotas de funciones, costo variable, sin control sobre la infraestructura",[140,141,142],"Kamal (despliegue zero-downtime)","Orquesta Docker y kamal-proxy, despliegue con un solo comando (`kamal deploy`)","Herramienta Ruby (gem o imagen Docker), configuración inicial más larga, pensado para equipos",{"type":39,"title":144,"body":145},"Registros: leerlos, rotarlos y cruzarlos con Nginx","PM2 centraliza la salida de la aplicación: `pm2 logs nuxt-app` sigue el flujo en directo (salida estándar y errores) y `pm2 logs nuxt-app --lines 100` muestra las últimas líneas. Los archivos se escriben en `~\u002F.pm2\u002Flogs\u002F`, un `-out.log` y un `-error.log` por aplicación, con el número de instancia como sufijo en modo cluster.\n\nEstos archivos no rotan por sí solos. El módulo pm2-logrotate los rota al superar los 10 MB y conserva 30 por defecto; ajuste estos umbrales al tamaño de su disco:\n\n```bash\npm2 install pm2-logrotate\npm2 set pm2-logrotate:max_size 50M\npm2 set pm2-logrotate:retain 7\n```\n\nCuando el navegador recibe un 502 o un 504, mire primero del lado de Nginx: `\u002Fvar\u002Flog\u002Fnginx\u002Ferror.log` indica si no pudo alcanzar `127.0.0.1:3000` (proceso detenido, puerto erróneo) o si Nitro tardó demasiado en responder.",{"type":39,"title":147,"body":148},"Resolución de problemas: errores comunes en producción","**`Error: listen EADDRINUSE: address already in use :::3000`**\nUn proceso ya ocupa el puerto 3000. Identifíquelo con `ss -tlnp | grep 3000` y detenga la instancia PM2 huérfana: `pm2 delete nuxt-app` seguido de un reinicio limpio. Evite lanzar múltiples instancias sin un load balancer — configure el `cluster_mode` de PM2.\n\n**`502 Bad Gateway` en Nginx**\nNitro no está arrancado o escucha en el puerto incorrecto. Compruebe `pm2 status` y revise los logs: `pm2 logs nuxt-app --lines 50`. Verifique también que la directiva `proxy_pass` en Nginx apunta a `http:\u002F\u002F127.0.0.1:3000` (no a `localhost` que puede resolver a IPv6 si el proceso solo escucha en IPv4).\n\n**`useRuntimeConfig()` devuelve undefined**\nLas variables `NUXT_*` solo se leen cuando arranca el proceso Nitro: tras modificar `.env`, recargue con `pm2 reload nuxt-app`. Compruebe que el archivo se carga realmente mediante `--node-args=\"--env-file=…\"` y no exportado en el shell actual, que desaparece con la sesión SSH. Si el valor falta solo en el navegador, la clave debe declararse bajo `runtimeConfig.public` y la variable llevar el prefijo `NUXT_PUBLIC_`.\n\n**Las rutas `server\u002Fapi` devuelven 404 en producción**\nCompruebe que su build incluye la carpeta `server\u002F` en `.output`. Un `nitro.preset` mal configurado (por ejemplo `static` en vez de `node-server`) genera un sitio estático sin servidor. Reconstruya con `npm run build` tras verificar `nuxt.config.ts`.\n\n**`X-Forwarded-Proto` ignorado, bucle de redirección**\nSi Nuxt redirige HTTP → HTTPS en bucle, significa que el middleware de redirección ve `http` pese al HTTPS del cliente. Asegúrese de que Nginx transmite `proxy_set_header X-Forwarded-Proto $scheme` y que su `nuxt.config.ts` no fuerza la redirección HTTPS dos veces junto a Certbot.",{"type":150,"title":151,"body":152},"tip","Supervisión y métricas con PM2","Más allá del simple `pm2 status`, PM2 expone un panel en tiempo real con `pm2 monit`: CPU, memoria, reinicios y logs de procesos. Para una aplicación Nuxt bajo carga, active el modo cluster para usar todos los vCPU disponibles:\n\n```bash\npm2 start .output\u002Fserver\u002Findex.mjs --name nuxt-app -i max\n```\n\nPM2 distribuye automáticamente las peticiones entre los workers. Exporte estas métricas a Prometheus y Grafana para recibir alertas sobre reinicios inesperados — señal de un bug o fuga de memoria a corregir antes de que afecte a los usuarios.",{"type":150,"title":154,"body":155},"La documentación oficial","Para la configuración avanzada y los cambios de versión, consulte la \u003Ca href=\"https:\u002F\u002Fnuxt.com\u002Fdocs\">documentación oficial de Nuxt\u003C\u002Fa> (routeRules, `runtimeConfig`, módulos), la \u003Ca href=\"https:\u002F\u002Fnitro.build\u002Fdeploy\u002Fruntimes\u002Fnode\">página de Node.js de Nitro\u003C\u002Fa> para las variables `NITRO_PORT` y `NITRO_HOST`, y la \u003Ca href=\"https:\u002F\u002Fpm2.keymetrics.io\u002Fdocs\u002Fusage\u002Fcluster-mode\u002F\">documentación del modo cluster de PM2\u003C\u002Fa>. Esta guía cubre la puesta en línea en un VPS; la documentación del editor sigue siendo la referencia para los ajustes finos.","Despliegue su Nuxt con total autonomía","El VPS Cloud de ServOrbit incluye una plantilla con Node.js, PM2, Nginx y SSL automático, ideal para alojar sus aplicaciones Nuxt 3 con SSR y rutas de servidor.","Desplegar mi VPS Nuxt","\u002Fvps-cloud",[161,178,195],{"id":162,"slug":163,"slugs":164,"title":168,"excerpt":169,"readTime":23,"views":18,"isPinned":19,"noindex":19,"publishedAt":170,"updatedAt":171,"category":172,"categories":173,"featuredImage":30,"bgImage":31,"posterImage":175,"relatedSolution":176},5,"desplegar-laravel-en-un-vps",{"fr":165,"en":166,"ar":167,"es":163},"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},[174],{"id":23,"name":24,"slug":25,"color":26,"icon":27},"\u002Fblog\u002Fcovers\u002Fdeployer-laravel-vps-poster.svg",{"categorySlug":27,"appSlug":177},"laravel-stack",{"id":179,"slug":180,"slugs":181,"title":185,"excerpt":186,"readTime":187,"views":18,"isPinned":19,"noindex":19,"publishedAt":188,"updatedAt":21,"category":189,"categories":190,"featuredImage":30,"bgImage":31,"posterImage":192,"relatedSolution":193},43,"desplegar-una-aplicacion-nodejs-en-un-vps",{"fr":182,"en":183,"ar":184,"es":180},"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.",8,"2026-05-08T00:00:00+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":27},[191],{"id":23,"name":24,"slug":25,"color":26,"icon":27},"\u002Fblog\u002Fcovers\u002Fdeployer-nodejs-vps-poster.svg",{"categorySlug":34,"appSlug":194},"nodejs-stack",{"id":196,"slug":197,"slugs":198,"title":202,"excerpt":203,"readTime":204,"views":205,"isPinned":19,"noindex":19,"publishedAt":206,"updatedAt":207,"category":208,"categories":209,"featuredImage":30,"bgImage":31,"posterImage":211,"relatedSolution":212},44,"desplegar-una-aplicacion-django-en-un-vps",{"fr":199,"en":200,"ar":201,"es":197},"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.",3,7,"2026-05-07T00:00:00+00:00","2026-11-04T16:30:25+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":27},[210],{"id":23,"name":24,"slug":25,"color":26,"icon":27},"\u002Fblog\u002Fcovers\u002Fdeployer-django-vps-poster.svg",{"categorySlug":34,"appSlug":213},"django",true,1794270591213]