Next.js
Deployment en otras plataformas
Compara despliegues de Next.js en servidores Node, contenedores, serverless, adapters y export estático, junto con sus requisitos operativos.
- Última actualización
- Actualizada
- Nivel
- Profundización
Next.js
Compara despliegues de Next.js en servidores Node, contenedores, serverless, adapters y export estático, junto con sus requisitos operativos.
Next.js no necesita Vercel para funcionar. Puede ejecutarse como un servidor Node.js, contenedor, servicio serverless, plataforma con adapter o export estático cuando las funciones usadas lo permiten. La pregunta correcta no es “¿el host soporta Next.js?”, sino qué capacidades del framework puede ejecutar correctamente y con qué garantías operativas.
Next.js application
├─ static assets
├─ prerendered output
├─ server routes
├─ Server Components
├─ Actions and Route Handlers
├─ image optimization
├─ cache and revalidation
└─ streaming
↓
deployment target
├─ Node process
├─ containers
├─ serverless functions
├─ platform adapter
└─ static hostingUna aplicación simple puede funcionar en casi cualquier servidor Node. Una aplicación con Cache Components, PPR, Server Actions, múltiples réplicas y revalidación necesita más coordinación.
Un proceso next start puede ejecutar el conjunto completo de funciones del framework sobre Node.js. La infraestructura adicional mejora escalado, distribución y rendimiento:
Streaming es importante para revelar Server Components y PPR progresivamente. Si un proxy bufferiza toda la respuesta, la aplicación puede seguir funcionando, pero pierde el beneficio de entrega progresiva.
pnpm build
pnpm startAdecuado para:
Ventajas:
Responsabilidades:
const nextConfig = {
output: "standalone",
};Genera un output autocontenido con dependencias necesarias para ejecutar el servidor. Es útil en Docker porque reduce lo que debes copiar.
Todavía debes incluir:
.next/static.public.No convierte la aplicación en un binario ni añade automáticamente observabilidad o caché compartida.
build image
→ run immutable container
→ health check
→ load balancer
→ multiple replicasVentajas:
Cuida:
Cada route o grupo de routes puede convertirse en función.
Ventajas:
Trade-offs:
No asumas que una plataforma serverless reproduce exactamente cache, ISR o streaming de otra. Verifica el adapter y la documentación del proveedor.
const nextConfig = {
output: "export",
};Genera archivos estáticos. Funciona para rutas resolubles sin runtime servidor.
No puede ejecutar después del deploy:
Puedes consumir APIs externas desde cliente, pero entonces cambian SEO, seguridad, loading y arquitectura.
Next.js 16.2 estabilizó una API de adapters para que plataformas traduzcan el output de build a su infraestructura. Un adapter puede mapear:
Esto mejora portabilidad, pero no hace idénticas todas las plataformas. Cada proveedor sigue teniendo límites, regiones, logs, almacenamiento y costes propios.
Antes de elegir un adapter, revisa:
Para self-hosting coloca Nginx, Caddy, HAProxy o un balanceador administrado delante del proceso:
internet
→ TLS / WAF / rate limit / body limits
→ reverse proxy
→ Next.js serverAporta:
Configura streaming sin buffering indebido. No caches respuestas privadas ni RSC payloads con una key incorrecta.
Con una sola instancia, la memoria local puede parecer suficiente. Al escalar:
request A → instance 1
request B → instance 2Problemas:
Necesitas, según el caso:
Distingue:
browser/CDN cache
Next.js route/cache components
application cache
provider cache
DB cacheEn self-hosting con varias réplicas, una invalidación debe llegar a las instancias relevantes. Si cada proceso mantiene su propia memoria, un usuario puede alternar entre versiones.
Define:
next/image funciona con next start si el entorno incluye las dependencias necesarias, como sharp según la configuración.
En varias réplicas, el mismo resize puede repetirse. Opciones:
/_next/image.No elimines query params del optimizador en el proxy.
Coloca el servidor cerca de la base. Revisa:
En Kubernetes, veinte pods no deberían abrir cada uno cien conexiones si PostgreSQL solo tolera doscientas.
El filesystem local puede servir para:
No sirve como almacenamiento compartido de uploads. Usa S3, R2, Blob Storage o equivalente.
Next.js maneja requests web. Infraestructura adicional puede ser necesaria para:
No mantengas una request abierta durante un trabajo que debería sobrevivir a un reinicio.
Health endpoint:
/live → proceso responde
/ready → dependencias críticas disponiblesNo conviertas readiness en una consulta costosa en cada segundo. Al apagar:
El orquestador necesita tiempo suficiente para graceful shutdown.
Una plataforma compatible debe permitir:
Incluye versión/commit en logs para saber qué instancia atendió un fallo.
Un mismo artefacto puede promocionarse entre entornos si los valores privados se leen en runtime. Pero:
NEXT_PUBLIC_* → queda en build
static metadata → puede quedar en build
prerendered content → puede depender del buildSi staging y production requieren valores públicos distintos, debes reconstruir o entregar configuración runtime visible desde servidor.
Evalúa con una matriz:
Para un SaaS de inventario:
Next.js containers
→ load balancer
→ PostgreSQL managed
→ Redis shared
→ object storage
→ queue worker
→ observabilityLas pages y Actions corren en Node. Redis coordina rate limit/cache. Los uploads van a storage. Un worker procesa importaciones de Excel y emails.
Puede faltar streaming, caché coordinada o adapter correcto.
Sesiones y revalidación divergen.
Elimina el beneficio de streaming.
Obliga a mover auth y datos al cliente.
No persiste ni se comparte.
Ejecuta el trabajo varias veces.
Satura PostgreSQL.
CI/CD para Next.js convierte build, tests, migraciones y despliegue en un proceso repetible y recuperable.