Next.js
Deployment en Vercel
Explica cómo desplegar Next.js en Vercel con previews, variables por entorno, funciones, caché, regiones, observabilidad, rollback y control de costes.
- Última actualización
- Actualizada
- Nivel
- Aplicación
Next.js
Explica cómo desplegar Next.js en Vercel con previews, variables por entorno, funciones, caché, regiones, observabilidad, rollback y control de costes.
Desplegar Next.js en Vercel significa ejecutar el framework sobre una plataforma que entiende sus rutas, builds, funciones, caché, imágenes, previews y streaming. La integración reduce trabajo operativo, pero no elimina decisiones sobre regiones, datos, seguridad, límites, costes, rollback y observabilidad.
Git push / pull request
↓
Vercel build
├─ instala dependencias
├─ valida framework y rutas
├─ ejecuta next build
└─ genera assets y funciones
↓
Deployment inmutable
├─ URL de preview
├─ static assets/CDN
├─ server functions
├─ cache/revalidation
└─ observabilidad
↓
Promoción o production deploymentCada deployment es una versión independiente. Production no es una carpeta que se modifica en sitio: un dominio apunta a un deployment concreto y puede volver a apuntar a uno anterior durante un rollback.
Estas capacidades son de plataforma. APIs como Server Components, Route Handlers o next/image pertenecen al framework y también pueden ejecutarse en otras infraestructuras compatibles.
Se ejecuta localmente con servicios y secretos de desarrollo.
Se crea desde una rama o pull request. Sirve para revisar:
Preview normalmente usa NODE_ENV=production. Si necesitas distinguirlo, usa una variable explícita como APP_ENV=preview o metadata confiable de Vercel.
Recibe tráfico del dominio principal. Debe usar:
Nunca permitas que un preview apunte accidentalmente a una base de datos productiva con permisos de escritura amplios.
Vercel permite asignarlas por entorno. Clasifica:
server secret
→ DATABASE_URL, AUTH_SECRET, provider tokens
public build value
→ NEXT_PUBLIC_ANALYTICS_ID
runtime environment marker
→ APP_ENVLos valores NEXT_PUBLIC_* se incorporan al bundle durante el build. Cambiarlos sin reconstruir no modifica un deployment ya generado.
Buenas prácticas:
Un deployment ejecuta normalmente:
install
→ framework detection
→ next build
→ output analysis
→ upload assets/functionsFija:
No confíes en que Vercel resolverá una discrepancia entre lockfiles o una versión local diferente. Reproduce next build localmente y en CI.
El preview debe ser una etapa de validación, no solo un enlace visual.
Checklist:
noindex y canonical correcto.Protege previews que muestran datos internos. robots.txt no es control de acceso.
El dominio se conecta al deployment productivo mediante DNS. Revisa:
www o dominio alterno.Secure correctos.Una redirección permanente mal configurada puede quedar cacheada por navegadores y buscadores. Prueba primero con redirect temporal cuando la migración aún no es definitiva.
La aplicación puede ejecutarse cerca del usuario, pero la latencia total depende de dónde viven:
user in Colombia
→ function in nearby region
→ database in distant region
→ latency still highColoca el runtime cerca de la fuente principal o utiliza una arquitectura distribuida consciente. No elijas Edge o múltiples regiones solo por marketing.
Las rutas dinámicas pueden ejecutarse como funciones. Considera:
Una request web no es un worker durable. Procesos largos, emails masivos, generación pesada o sincronizaciones pertenecen a colas y workers.
En serverless evita abrir una conexión nueva sin pooling por cada ejecución. Usa:
Las migraciones no deberían ejecutarse desde cada función al arrancar. Se coordinan en CI/CD o un job único.
Vercel puede integrar las capas de caché de Next.js, pero todavía debes diseñar:
router.refresh() no invalida por sí mismo una entrada servidor. Después de una mutación usa la API adecuada y verifica el resultado en production.
En multi-region o múltiples instancias, comprueba que la plataforma coordine invalidación y caché según las garantías documentadas. No asumas que una variable global funciona como caché compartida.
next/image se integra con el optimizador de la plataforma. Revisa:
sizes.Para uploads usa object storage. El filesystem de una función no es almacenamiento persistente compartido.
Un deployment saludable necesita:
No registres cookies, Authorization headers, FormData completa o tokens.
Rollback de código puede apuntar el dominio a un deployment anterior. Pero el sistema incluye más que código:
code version
+ database schema
+ cache
+ queues
+ external contractsSi una migración destructiva ya eliminó una columna, volver al código anterior puede fallar. Usa estrategia expand/contract:
Mide:
Una arquitectura con demasiadas funciones, invalidaciones globales o imágenes no optimizadas puede aumentar costes sin mejorar UX.
pull request
→ preview deployment protegido
→ SEO noindex
→ smoke test home/portfolio/services
→ comprobar Sanity development
→ merge main
→ production build
→ domain nicoo.dev
→ Search Console y Web VitalsLa variable del dataset de Sanity debe diferenciar preview y production. El dominio canónico y las Open Graph images deben apuntar a producción.
Cuando un deploy falla:
Puede alterar datos reales.
Un prefijo o prop cliente puede exponerlos.
Rompe la versión todavía activa y el rollback.
Desaparecen o no se comparten.
Un cambio de runtime rompe el build.
La plataforma no reemplaza límites de dominio, DAL, seguridad o colas.
Un deployment exitoso puede fallar bajo tráfico real.
NEXT_PUBLIC_* utilizadas por el bundle.Deployment en otras plataformas separa los requisitos del framework de la infraestructura específica de un proveedor.