La Mayoría de Developers Despliegan en Vercel Como Si Fuera Shared Hosting
Subes el código. Haces push. Funciona.
Y en producción con tráfico real, todo colapsa.
El problema no es Vercel. Es que usas una plataforma de deployment profesional como si fuera un hosting estático.
Esta guía no repite lo básico. Asume que ya sabes hacer vercel deploy. Lo que vas a ver aquí es la arquitectura de decisiones que la documentación oficial nunca prioriza.
La Arquitectura Real de un Deploy en Vercel
Vercel no es solo "hosting para Next.js". Es una plataforma con tres capas que la mayoría confunde:
→ Edge Network — CDN global, caché de assets estáticos, middleware
→ Serverless Functions — Node.js runtime, APIs, SSR
→ Edge Functions — JavaScript V8 isolates, sin Node.js APIs, latencia mínima
El error crítico es mezclar estas capas sin entender sus trade-offs.
Cuando despliegas sin estrategia, Vercel ejecuta todo en Serverless por defecto. Eso funciona. Pero no es óptimo ni para rendimiento ni para coste.
1. Estructura tu `vercel.json` desde el día uno
La mayoría crea el archivo vercel.json cuando algo falla. Ya es tarde.
Este es el esqueleto que uso en todos mis proyectos de producción:
Tres puntos críticos aquí:
Primero, regions define dónde se despliegan tus Serverless Functions. cdg1 es París, mad1 es Madrid. Si tus usuarios son europeos, esto reduce la latencia de forma significativa.
Segundo, los maxDuration por ruta. Las funciones de webhook necesitan más tiempo. Las funciones de AI aún más. Las APIs estándar deben ser rápidas o hay un problema de arquitectura.
Tercero, headers de seguridad en el nivel de infraestructura, no en el código de la aplicación.
Preview Deployments: La Herramienta de QA que Infrautilizas
La mayoría usa los preview deployments solo para "ver cómo queda". Error.
El preview deployment es tu entorno de staging gratuito con URL pública.
Cada push a cualquier rama genera una URL única e inmutable. Eso significa:
→ Puedes compartirla con el cliente antes de mergear
→ Puedes ejecutar tests E2E contra una URL real
→ Puedes hacer QA en mobile sin configurar nada
Este es el workflow que uso con GitHub Actions:
Cada preview deployment dispara tests automáticos. Si fallan, el PR no se mergea.
Este pipeline solo funciona correctamente si tus environment variables están configuradas por entorno — no globalmente. Vercel permite variables específicas para production, preview, y development. Úsalas.
Caching Estratégico: La Diferencia entre 50ms y 2 segundos
❌ Lo que hace la mayoría:
Cero caching. Cada request hits the database. Con tráfico real, esto es un cuello de botella garantizado.
✅ Lo que debes hacer:
La clave no es cachear todo. Es invalidar selectivamente.
revalidateTag es la función que separa las arquitecturas de producción del prototipo. Cuando actualizas un producto, invalidas exactamente ese cache. No recargas la página. No haces un deploy.
2. Route Segment Config para Control Granular
Tres páginas. Tres estrategias diferentes. Cada una optimizada para su patrón de datos.
El dashboard necesita datos en tiempo real. El blog puede ser relativamente estático. Pricing casi nunca cambia.
Sin esta granularidad, Vercel no puede optimizar nada. Tú tomas las decisiones. Vercel las ejecuta.
Monorepos en Vercel: La Configuración que el 90% Ignora
Si tienes un monorepo con Turborepo y múltiples apps, la configuración por defecto de Vercel es un desastre.
Vercel rebuildeará todas las apps en cada push si no configuras los ignoreBuildStep.
turbo-ignore detecta automáticamente si los cambios afectan a esa app específica. Si no hay cambios relevantes, cancela el build.
En un monorepo activo, esto reduce los builds innecesarios drásticamente.
Para proyectos con Turborepo, también activa Remote Caching de Vercel. Es el mismo mecanismo que turbo-ignore pero para los artefactos de build. Tu CI descarga el cache de builds previos en vez de recompilar desde cero.
Observabilidad: Logs que Realmente Te Dicen Algo
❌ El approach típico:
Revisar logs en el dashboard de Vercel cuando algo falla. Reactive, no proactive.
✅ El approach de producción:
Structured logging desde el primer día + alertas automáticas.
Vercel captura console.log como logs estructurados cuando emites JSON. Puedes filtrar por level, requestId, o cualquier campo del metadata directamente en el dashboard.
Integra Vercel Log Drains con Datadog, Axiom, o Logtail para persistencia y alertas. Los logs nativos de Vercel tienen retención limitada.
Variables de Entorno: El Error de Seguridad más Común
Vercel tiene tres scopes para variables: Production, Preview, Development.
Usa distintos valores por entorno. Tu OPENAI_API_KEY en preview puede apuntar a un proyecto con límites más bajos. Tu DATABASE_URL en preview debe apuntar a una base de datos de staging, nunca a producción.
Una sola variable mal configurada puede significar datos reales en un entorno de test.
Takeaways: Vercel Deployment Best Practices que Importan
→ `vercel.json` desde el día uno — define regiones, memory limits y maxDuration por ruta
→ Preview deployments como staging — conecta Playwright o Cypress a cada preview URL
→ Cache con invalidación por tags — usa unstable_cache + revalidateTag, nunca cacheo estático indiscriminado
→ Route Segment Config granular — cada página con su estrategia: force-dynamic, revalidate: 3600, o false
→ Monorepos con `turbo-ignore` — elimina builds innecesarios y activa Remote Caching
→ Structured logging en JSON — emite objetos con level, requestId y duration desde el primer commit
→ Environment variables por scope — Production, Preview y Development con valores distintos
Vercel deployment best practices no son un checklist que completas una vez. Son decisiones de arquitectura que defines antes de escribir la primera línea de lógica de negocio.
Los proyectos que escalan en Vercel no tienen mejor código. Tienen mejor configuración de infraestructura.
La plataforma es sólida. El trabajo es tuyo.
