Vercel Deployment Best Practices: Lo Que Nadie Te Cuenta Sobre Observabilidad y Rollbacks
Vercel deployment best practices reales: observabilidad con OpenTelemetry, rollback estratégico, Edge Config para feature flags y CI/CD con GitHub Actions.
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:
```bash
Configurar variables por entorno usando Vercel CLI
vercel env add NEXT_PUBLIC_API_URL production
vercel env add NEXT_PUBLIC_API_URL preview
vercel env add NEXT_PUBLIC_API_URL development
Listar todas las variables y sus scopes
vercel env ls
```
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.
```json
{
"version": 2,
"regions": ["cdg1", "lhr1"],
"functions": {
"app/api/checkout/route.ts": {
"maxDuration": 30,
"memory": 1024
},
"app/api/webhook/route.ts": {
"maxDuration": 60,
"memory": 512
}
},
"headers": [
{
"source": "/api/(.*)",
"headers": [
{ "key": "Cache-Control", "value": "no-store" },
{ "key": "X-Content-Type-Options", "value": "nosniff" }
]
}
]
}
```
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.
```typescript
// instrumentation.ts en la raíz del proyecto Next.js
export async function register() {
if (process.env.NEXT_RUNTIME === 'nodejs') {
const { NodeSDK } = await import('@opentelemetry/sdk-node');
const { OTLPTraceExporter } = await import(
'@opentelemetry/exporter-trace-otlp-http'
);
const { Resource } = await import('@opentelemetry/resources');
const { SEMRESATTRS_SERVICE_NAME } = await import(
'@opentelemetry/semantic-conventions'
);
const sdk = new NodeSDK({
resource: new Resource({
[SEMRESATTRS_SERVICE_NAME]: 'mi-app-produccion',
}),
traceExporter: new OTLPTraceExporter({
url: process.env.OTEL_EXPORTER_OTLP_ENDPOINT,
}),
});
sdk.start();
}
}
```
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.
```json
{
"checks": [
{
"name": "Performance Budget",
"blocking": true
}
]
}
```
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:
```bash
Listar deployments recientes
vercel ls --scope=tu-team
Hacer rollback instantáneo a un deployment específico
vercel rollback [deployment-url]
O usando el deployment ID
vercel rollback dpl_xxxxxxxxxxxxxxxx
```
La clave está en etiquetar tus deploys estables. Usa Git tags para marcar releases en producción.
```bash
Antes de cada release importante
git tag -a v2.4.1 -m "Release estable: checkout refactorizado"
git push origin v2.4.1
```
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.
```typescript
import { get } from '@vercel/edge-config';
export async function GET() {
const nuevoCheckoutActivo = await get('nuevo-checkout-activo');
if (!nuevoCheckoutActivo) {
// Devuelve el checkout antiguo
return Response.redirect('/checkout-v1');
}
return Response.redirect('/checkout-v2');
}
```
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.
```yaml
.github/workflows/deploy.yml
name: Deploy a Producción
on:
push:
branches: [main]
jobs:
test:
runs-on: ubuntu-latest
steps:
uses: actions/checkout@v4
uses: actions/setup-node@v4
with:
node-version: '20'
cache: 'npm'
run: npm ci
run: npm run type-check
run: npm run test:unit
run: npm run test:integration
deploy:
needs: test
runs-on: ubuntu-latest
steps:
uses: actions/checkout@v4
uses: amondnet/vercel-action@v25
with:
vercel-token: ${{ secrets.VERCEL_TOKEN }}
vercel-org-id: ${{ secrets.VERCEL_ORG_ID }}
vercel-project-id: ${{ secrets.VERCEL_PROJECT_ID }}
vercel-args: '--prod'
```
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.
Lee el artículo completo en brianmenagomez.com
Más sobre mis servicios en brianmenagomez.com
Herramientas: Conversor IAE CNAE · Gestorias cerca de ti · Calculadora IRPF