Vercel Deployment Best Practices: El Marco de 5 Pasos para Desplegar Sin Pagar el Peaje del Lock-In
Vercel no es solo hosting: es un ecosistema que te ata a sus APIs. Aprende el marco de 5 pasos para deployar sin pagar el peaje del lock-in. Código real, datos y un framework portable.
Vercel tiene 2,4 millones de desarrolladores. Esto es lo que NO te cuentan sobre construir en una plataforma que posee el framework, controla el runtime y diseña las APIs que usas
El 90% de los desarrolladores trata Vercel como "un Netlify con esteroides". Una plataforma de deploy que te ahorra configurar Nginx, CI/CD y DNS.
*Error. *
Vercel no es hosting genérico. Es un ecosistema verticalmente integrado donde cada decisión de diseño — desde el Edge Runtime hasta ISR pasando por `@vercel/kv` — está optimizada para que te quedes.
El problema no es que Vercel sea malo. Es que la mayoría descubre el peaje del lock-in durante la primera migración o el primer cuello de botella de escalado. Y para entonces, reescribir la capa de datos, el middleware y el sistema de caché ya no es una opción — es una emergencia.
Según datos de este mismo mes de julio de 2026, Vercel procesa 6 millones de deploys diarios, la mitad gestionados por AI agents. La plataforma crece. Pero el coste de salir también.
Vamos a verlo con código, datos y un marco accionable.
---
El Contrato Invisible que Firmas al Hacer Clic en "Deploy"
La jugada maestra de Vercel no son las preview deployments ni el Edge Network. Es hacer que el framework y la plataforma sean indistinguibles.
Cada vez que ejecutas `next build`, corres el pipeline de build de Vercel. Cada vez que usas `next start`, simulas su runtime de servidor. El framework literalmente asume por defecto que tu target de deploy es Vercel.
Esto no es un bug. Es la estrategia de moat.
El coste de cambiar no es "cambiar DNS". Es reescribir tu fetching de datos, tu sistema de caché y tu middleware.
Las 4 APIs que te Atan Sin que te Des Cuenta
1. Edge Middleware — `NextResponse.next()`, `request.cookies`, `request.geo`. Funciona en Vercel. Se rompe en Node.js puro y en Cloudflare Pages.
2. ISR con revalidación on-demand — `revalidatePath('/blog')` y `revalidateTag('posts')` dependen de la API de invalidación de caché propietaria de Vercel.
3. `@vercel/kv`, `@vercel/blob`, `@vercel/postgres` — Cada uno es un servicio propietario sin capa de compatibilidad con Redis, S3 o PostgreSQL estándar.
4. Edge Functions — Sub-50ms de cold start, pero con un límite de 50ms de CPU time y 128MB de memoria. Sin `fs`, sin `child_process`, sin módulos nativos.
Cada una de estas cuatro decisiones te acerca un paso más a un punto donde salir de Vercel no es un cambio de proveedor. Es una reescritura arquitectónica.
---
❌ Lo que la mayoría hace: "Funciona en local, desplegamos en Vercel y olvidamos"
El flujo típico:
```bash
npm run dev # funciona
git push # Vercel hace deploy automático
✅ todo ok... hasta que toca migrar
```
El equipo descubre 18 meses después que su middleware de autenticación usa `request.geo` (Vercel-exclusive), que su sistema de caché depende de `revalidatePath()` y que los datos han migrado a `@vercel/kv`.
La migración ya no es técnica. Es arquitectónica. Y duele.
---
✅ Lo que deberías hacer: El Marco de 5 Pasos para Vercel Deployment Best Practices
He creado un framework llamado "El Principio de la Salida Temprana". Se basa en una idea simple: si no puedes salir de Vercel en una semana, no deberías haber empezado sin saberlo.
Paso 1: Audit de Superficie de Ataque Propietaria — Día 1
Antes de escribir una línea de lógica de negocio, identifica qué APIs de Vercel estás usando y clasifícalas:
```typescript
// ❌ Vercel-exclusive — requiere cambio arquitectónico
import { geolocation } from '@vercel/edge';
import { kv } from '@vercel/kv';
import { revalidatePath } from 'next/cache';
// ✅ Portable — funciona en cualquier runtime
import { Redis } from '@upstash/redis';
import { S3Client } from '@aws-sdk/client-s3';
```
Ratea cada dependencia como:
Trivial de reemplazar (un wrapper, un cambio de import)
Requiere cambio arquitectónico (reescribir lógica de caché, migrar datos)
Si más del 30% de tus dependencias caen en la segunda categoría, tienes un problema de lock-in que no ves porque tu app aún es pequeña.
Paso 2: Test de Deploy Externo — Semana 1, No Mes 12
Monta un despliegue de Next.js en Docker o Node.js puro en la primera semana. No cuando ya tengas 50 endpoints y 15 tablas en `@vercel/postgres`.
```dockerfile
Dockerfile.nextjs — portable, sin Vercel
FROM node:22-alpine
WORKDIR /app
COPY . .
RUN npm ci
RUN npm run build
EXPOSE 3000
CMD ["node", "node_modules/.bin/next", "start"]
```
Corre tu test suite contra esa instancia. Te sorprenderá lo que se rompe.
Lo que suelo encontrar en mis proyectos:
Middleware que accede a `request.cookies` con la API de Next.js y casca fuera de Vercel
Rutas que dependen de `@vercel/analytics` para reporting y no tienen fallback
ISR que sirve páginas stale porque no hay capa de caché externa
Paso 3: Abstrae tu Capa de Datos — No Escribas Contra Vercel Directamente
`@vercel/kv`, `@vercel/blob` y `@vercel/postgres` son cómodos. Pero son propietarios.
```typescript
// ❌ Acoplado a Vercel
import { kv } from '@vercel/kv';
await kv.set('session', data);
// ✅ Portable — abstracción intercambiable
interface CacheStore {
get(key: string): Promise<string | null>;
set(key: string, value: string): Promise<void>;
}
class VercelKvStore implements CacheStore {
async get(key: string) {
const { kv } = await import('@vercel/kv');
return kv.get(key);
}
async set(key: string, value: string) {
const { kv } = await import('@vercel/kv');
return kv.set(key, value);
}
}
class UpstashRedisStore implements CacheStore {
private redis: Redis;
constructor() {
this.redis = Redis.fromEnv();
}
async get(key: string) {
return this.redis.get(key);
}
async set(key: string, value: string) {
return this.redis.set(key, value);
}
}
```
Este patrón te permite cambiar de cache backend tocando una línea. No reescribiendo toda la app.
Paso 4: Middleware Portable — Usa Web APIs Estándar
El middleware de Next.js usa `NextRequest` y `NextResponse`. Son extensiones propietarias del API estándar de `Request`/`Response`.
```typescript
// ❌ Atado a Next.js/Vercel
import { NextResponse } from 'next/server';
import type { NextRequest } from 'next/server';
export function middleware(request: NextRequest) {
const country = request.geo?.country; // Vercel-exclusive
return NextResponse.next(); // Next.js-exclusive
}
```
```typescript
// ✅ Portable — Web API estándar
export async function middleware(request: Request): Promise<Response> {
const url = new URL(request.url);
const country = request.headers.get('x-vercel-ip-country'); // estándar HTTP
const response = new Response(null, {
status: 307,
headers: { Location: country === 'ES' ? '/es' : '/en' }
});
return response;
}
```
Regla de oro: si tu middleware solo usa `Request`/`Response` del estándar Web API, funciona en Vercel, Cloudflare Workers, Deno, Bun y Node.js 22+. Si usa `NextRequest`/`NextResponse`, solo funciona en Vercel.
Paso 5: El Simulacro Trimestral de Migración — Un Sprint Cada 3 Meses
Cada trimestre, dedica un sprint (o un viernes por la tarde) a desplegar tu app en un destino alternativo:
Fly.io para serverless con full Node.js
Railway para despliegues rápidos con Postgres estándar
Cloudflare Pages para edge-first con Workers
Una VPS con PM2 para el enfoque clásico
```bash
Simulacro: deploy a Fly.io
fly launch
fly deploy
¿Se rompió algo? Bien. Ahora sabes qué arreglar.
```
El objetivo no es migrar. Es mantener la opción de migrar.
Si cada trimestre tu app se despliega sin problemas en otro lado, tu arquitectura es portable. Si cada trimestre descubres una nueva dependencia oculta, tienes una deuda técnica que está creciendo en silencio.
---
El Caso del Edge Runtime: ¿Para Qué Sirve Realmente?
Vercel vende Edge Functions como la solución mágica contra los cold starts. Y es cierto: sub-50ms de latencia inicial.
*Pero el 90% de las API routes no necesitan edge latency. *
Si tu función consulta una base de datos en us-east-1, la latencia de red ya es de ~50ms. Que la función arranque en 5ms o 500ms es irrelevante cuando el cuello de botella es la query a la base de datos.
El Edge Runtime tiene limitaciones que no te cuentan en el dashboard:
| Característica | Edge Function | Serverless Function |
|---|---|---|
| Cold start | ~5-50ms | ~200-500ms |
| CPU time | 50ms máximo | 60 segundos |
| Memoria | 128MB | 1024MB |
| `fs` / `crypto` / `child_process` | ❌ No disponible | ✅ Completo |
| Módulos nativos (sharp, bcrypt) | ❌ No | ✅ Sí |
Conclusión: Edge Functions son excelentes para redirects, A/B testing, geolocalización y autenticación. Son terribles para consultas a bases de datos, procesamiento de imágenes, o cualquier operación que requiera más de 50ms de CPU.
No elijas Edge porque "suena rápido". Elige Edge porque has medido el cuello de botella real de tu request path.
---
El Problema de Gobernanza Que Nadie Quiere Mencionar
React tiene una fundación. Vue tiene una fundación. Angular tiene Google. Next.js tiene Vercel — una empresa venture-backed cuyo incentivo es hacer crecer la plataforma, no preservar la neutralidad del framework.
Cada feature de Next.js que mejora el lock-in de Vercel es una feature que hace Next.js peor como framework portable.
La tensión entre "lo que es bueno para los usuarios de Next.js" y "lo que es bueno para el negocio de Vercel" es real, no se reconoce, y crece con cada release.
¿Qué significa esto en la práctica?
El roadmap de Next.js lo dirigen empleados de Vercel. No hay governance externo.
Las RFCs las aprueba Vercel. No hay un comité independiente.
Las features que atan a Vercel (ISR propietario, Edge Runtime exclusivo, data products) tienen prioridad sobre features que mejorarían la portabilidad.
No digo que Next.js sea mal framework. Digo que es un framework cuyo principal stakeholder tiene incentivos que no siempre alinean con los tuyos.
---
Resumen: Las 5 Reglas para Desplegar en Vercel sin Pagar el Peaje
1. Audita tu lock-in el día 1 — identifica qué APIs son Vercel-exclusive antes de escribir negocio sobre ellas
2. Testea fuera de Vercel en la semana 1 — un Dockerfile y un `node next start` te ahorran sorpresas 18 meses después
3. Abstracte tu capa de datos — una interfaz de 3 métodos te permite cambiar de Redis a KV sin reescribir la app
4. Escribe middleware portable — `Request`/`Response` estándar, no `NextRequest`/`NextResponse`
5. Ejecuta un simulacro de migración cada trimestre — si puedes desplegar en otro lado, tienes opciones. Si no, tienes una deuda que crece
Usar Vercel no es malo. Usar Vercel sin saber que estás construyendo sobre APIs que no son tuyas — eso sí es peligroso.
La próxima vez que hagas clic en "Deploy", pregúntate: si mañana necesitara irme, ¿podría hacerlo en una tarde?
Si la respuesta es no, no es que Vercel sea malo. Es que no has diseñado tu sistema para tener una salida.
Eso no es deploy. Es comprar una casa sin comprobar si hay puerta trasera.
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