Tu Deploy en Vercel No Termina Cuando el Build Pasa
El build pasa. La URL de preview funciona. Das por terminado el trabajo.
Eso no es producción. Es optimismo con un dominio personalizado.
El problema real con Vercel deployment best practices no es el deploy inicial. Es todo lo que pasa después.
La mayoría de developers domina el flujo básico: conectas el repositorio, configuras las variables de entorno, y Vercel hace el resto. Pero cuando algo falla en producción, no tienes trazabilidad. No sabes qué función tardó 8 segundos. No sabes qué deploy rompió el checkout. Y el rollback manual te cuesta tiempo real.
Estos son los patrones que cambian eso.
---
El Error Más Costoso: Variables de Entorno Sin Estrategia
La mayoría gestiona las variables de entorno así:
❌ Mal approach:
→ Añades NEXT_PUBLIC_API_URL en el dashboard de Vercel para production
→ La misma variable apunta a producción en preview deployments
→ Tu equipo de QA valida con datos reales
→ Un developer borra accidentalmente un registro de base de datos
Esto ocurre porque Vercel permite tres scopes distintos: Production, Preview, y Development. La mayoría solo configura uno.
✅ Approach correcto:
En preview, NEXT_PUBLIC_API_URL debe apuntar a tu entorno de staging. En production, a tu API real. Nunca al revés.
Vercel.json Como Fuente de Verdad
No gestiones la configuración solo desde el dashboard. El dashboard cambia. El código no miente.
Definir maxDuration y memory por función específica es Vercel deployment best practices que el 90% ignora. Una función de webhook no necesita 3GB de memoria. Una función de procesamiento de imágenes sí.
---
Observabilidad Real: Más Allá de los Logs del Dashboard
El dashboard de Vercel te da logs. Eso no es observabilidad.
La observabilidad real no es ver logs. Es entender el comportamiento de tu sistema antes de que un usuario te reporte el error.
Vercel integra de forma nativa con dos herramientas que deberías activar desde el día uno: Vercel Analytics y Speed Insights.
Pero hay un nivel más profundo: OpenTelemetry.
Este archivo instrumentation.ts es una feature de Next.js que Vercel ejecuta automáticamente. Conecta tu app a cualquier backend compatible con OpenTelemetry: Grafana, Honeycomb, o Datadog.
El resultado: traces completos de cada request, incluyendo tiempo de base de datos, tiempo de rendering, y latencia de APIs externas. Sin esto, estás adivinando.
Alertas Proactivas con Checks de Deployment
Vercel permite configurar Deployment Protection y checks automáticos. La mayoría no los configura.
Combina esto con Vercel Checks API para bloquear deploys que no pasen tus criterios de rendimiento. Un deploy que degrada el LCP en un 30% no debería llegar a producción automáticamente.
---
Rollback Estratégico: El Plan Que Necesitas Antes de Necesitarlo
Cuando algo falla en producción, cada segundo cuenta.
Vercel guarda todos tus deploys anteriores. Un rollback instantáneo existe. El problema es que nadie define el proceso hasta que hay una incidencia.
❌ Sin estrategia de rollback:
→ Algo falla en producción
→ Buscas el deploy anterior en el dashboard
→ Intentas recordar cuál era el estable
→ Pierdes tiempo mientras los usuarios están afectados
✅ Con estrategia de rollback:
La clave está en etiquetar tus deploys estables. Usa Git tags para marcar releases en producción.
Así sabes exactamente qué commit corresponde a cada deploy en Vercel. El rollback pasa de ser una búsqueda a ser un comando.
Feature Flags Como Alternativa al Rollback
El rollback perfecto es el que no necesitas hacer.
Integra flags de feature directamente en tu lógica de Next.js. Vercel Edge Config es la herramienta nativa para esto.
Edge Config tiene latencia de lectura extremadamente baja porque se distribuye globalmente. Cambias un flag desde el dashboard y el comportamiento cambia en milisegundos. Sin redeploy. Sin rollback. Sin incidencia.
---
Pipeline de CI/CD que Realmente Protege Producción
El pipeline por defecto de Vercel es: push a main → deploy a producción.
Eso es aceptable para proyectos personales. Para producción real, necesitas una capa más.
Bloquear el deploy automático de Vercel desde el dashboard (opción "Ignore Build Step") y gestionarlo desde GitHub Actions te da control total. El deploy a producción solo ocurre si los tests pasan.
Esto es Vercel deployment best practices en su forma más directa: no dejes que Vercel decida cuándo desplegar. Tú decides.
---
Los Takeaways que Importan
→ Variables de entorno por scope: Production, Preview, y Development deben tener configuraciones distintas. Nunca compartas credenciales reales con preview deployments.
→ `vercel.json` en el repositorio: La configuración que no está en código es configuración que alguien borrará accidentalmente.
→ OpenTelemetry desde el día uno: Conectar tu app a un backend de trazas antes de necesitarlo te ahorra horas de debugging en producción.
→ Rollback como proceso, no como improviso: Define el comando de rollback, etiqueta tus releases estables con Git tags, y practica el proceso antes de una incidencia real.
→ Edge Config para feature flags: El rollback más rápido es el que no requiere un redeploy. Edge Config te da control de comportamiento en tiempo real.
→ CI/CD externo para producción: GitHub Actions bloqueando el deploy automático de Vercel es la diferencia entre un pipeline profesional y uno que despliega código roto.
El deploy es el comienzo del trabajo, no el final. Los proyectos que escalan son los que tienen observabilidad, rollback documentado, y configuración como código desde el primer commit.
Artículos relacionados
- Resend en Producción: Monitorización, Analíticas y Gestión de Bounces que Nadie Te Explica
- MCP en Producción: El Pattern de Composición que Nadie Te Explica
- Sanity Webhooks y Content Pipelines: La Arquitectura que Nadie Te Explica
---
¿Quieres recibir contenido como este cada semana? Suscríbete a mi newsletter
