Vercel Deployment Best Practices: El Marco de 5 Pasos para Desplegar Sin Pagar el Peaje del Lock-In
Vercel deployment best practices: descubre el marco de 5 pasos para desplegar Next.js sin lock-in. Auditoría de ISR, Edge Runtime y alternativas con OpenNext.
Tu Proyecto Next.js Funciona Perfecto en Vercel. Exactamente por Eso Deberías Preocuparte
Vercel tiene 2,4 millones de desarrolladores. La interfaz es impecable. El deploy con un push a main es casi instantáneo. Las preview deployments funcionan como magia.
El problema es que esa magia no es tuya.
La mayoría asume que Vercel es "solo una plataforma de hosting" y que su app Next.js sigue siendo portable. La realidad es que Vercel ha horneado comportamientos propietarios directamente en el framework: ISR, middleware, optimización de imágenes y Edge Functions tienen semánticas específicas de Vercel.
*Para cuando descubres que no puedes irte, tu arquitectura ya está casada con su runtime. *
Este artículo no va de odiar Vercel. Va de desplegar con los ojos abiertos. El marco de 5 pasos que te propongo no te pide que abandones la plataforma. Te pide que sepas exactamente lo que cuesta quedarte.
El Contrato Invisible: No es Hosting, es un Ecosistema Verticalmente Integrado
Vercel posee el framework (Next.js), controla el runtime (Edge Runtime, Serverless Functions) y diseña las APIs que usas (NextRequest, NextResponse, revalidate, unstable_cache).
*No es una plataforma de hosting. Es un ecosistema verticalmente integrado donde cada capa refuerza la dependencia de la siguiente. *
Next.js tiene más de 20 features propietarias que se comportan de forma diferente — o simplemente no existen — fuera de Vercel. Y el problema no es técnico. Es de timing.
❌ Lo que la mayoría hace: "Funciona en local, desplegamos en Vercel y olvidamos".
✅ Lo que deberías hacer: Asumir desde el día uno que vas a querer — o necesitar — migrar. Construir con portabilidad como requisito, no como afterthought.
Las 4 APIs que Te Atan Sin que te Des Cuenta
Vamos a lo concreto. Estas son las cuatro features de Next.js que más dependencia generan con Vercel:
1. ISR con Revalidación On-Demand
En Vercel, ISR funciona transparente porque ellos proveen la capa de caché como parte de la plataforma. Tu código es simple:
```typescript
// app/page.tsx — funciona en Vercel, pero no fuera
export const revalidate = 3600;
export default async function Page() {
const data = await fetch('https://api.example.com/data');
const json = await data.json();
return <div>{json.title}</div>;
}
```
Si despliegas esto en un Docker self-hosted, ISR se rompe. Next.js espera un cache de sistema de ficheros que se resetea en cada deploy. Para replicar el comportamiento, necesitas Redis + una arquitectura de cache externa que Vercel te daba gratis.
*El ISR es el caballo de Troya del lock-in: parece gratis hasta que intentas salir. *
2. Edge Middleware
El Edge Runtime de Vercel no es Node.js. Solo soporta un subconjunto estricto de Web APIs. Bloquea más de 30 módulos nativos de Node.js: `fs`, `crypto`, `path`, `bcrypt`, `jsonwebtoken`.
```typescript
// middleware.ts — funciona en Vercel, falla en cualquier otro runtime Edge
import { NextResponse } from 'next/server';
import jwt from 'jsonwebtoken'; // ❌ Error: No se puede importar 'jsonwebtoken' en Edge Runtime
export function middleware(request: NextRequest) {
const token = request.cookies.get('token')?.value;
const decoded = jwt.verify(token, process.env.JWT_SECRET!); // ❌ Falla en producción
return NextResponse.next();
}
```
Los equipos descubren esto cuando ya tienen cientos de rutas protegidas por middleware. La "solución" es mover la lógica de vuelta a API routes — perdiendo el beneficio de rendimiento edge que te vendieron.
3. Optimización de Imágenes (`next/image`)
El componente `next/image` usa `sharp` en local, pero en Vercel utiliza su propio servicio de optimización propietario. Si migras, pierdes la optimización automática y necesitas un CDN externo.
4. Serverless Functions con Timeout de 60 Segundos
En el plan Hobby, las serverless functions tienen un timeout máximo de 60 segundos. Para procesos pesados (generación de PDFs, procesamiento de imágenes, webhooks lentos), esto es un callejón sin salida.
Un cold start en Node.js en el plan gratuito puede superar los 1000ms. En un servidor dedicado, ~50ms. *La diferencia es 20x. *
El Precio Oculto del "Zero-Config"
El gancho de Vercel es el "zero-config". Haces push y funciona. Pero ese zero-config tiene un coste: no ves lo que está pasando debajo.
Cuando usas Vercel, estás comprando un bundle:
Hosting serverless en Edge Network
Optimización de imágenes
Caché ISR gestionada
Analytics
Equipo de producto que prioriza nuevas features sobre estabilidad cross-platform
El problema no es que sea caro. Es que *no sabes cuánto te costará salir hasta que ya es tarde. *
El marco que te propongo no es para abandonar Vercel. Es para que elijas quedarte con conocimiento de causa.
El Marco de Portabilidad de 5 Capas
Aquí está el núcleo del artículo. El Marco de Portabilidad de 5 Capas son cinco pasos concretos para auditar tu dependencia de Vercel y construir con opciones reales de salida.
Paso 1: Audita tu Superficie de Ataque Propietaria
Abre tu terminal. Ejecuta esto:
```bash
Busca dependencias directas de Vercel
grep -r "@vercel/" package.json
Busca uso de Edge Runtime en middleware
grep -r "NextRequest\|NextResponse\|edgeRuntime" middleware.ts
Busca páginas con ISR
grep -r "revalidate" app/
Lista módulos bloqueados en Edge Runtime
grep -r "jsonwebtoken\|bcrypt\|fs\|crypto\|path" app/
```
Esto te da un mapa de tu deuda arquitectónica. *No arregles nada todavía. Solo mide. *
Paso 2: Prueba tu Build Fuera de Vercel
Monta un contenedor Docker con `next start`. Ejecuta el mismo test de carga y compara:
Cold starts: Mide cuánto tarda la primera petición
Comportamiento ISR: Verifica que las páginas cacheadas se sirven correctamente tras un re-deploy
Ejecución de middleware: Confirma que no hay imports bloqueados por Edge Runtime
La mayoría descubre diferencias en este paso. *No necesitas migrar. Solo necesitas saber. *
Paso 3: Reemplaza Features Propietarias con Alternativas Agnósticas
Por cada feature de Vercel que uses, ten un plan B que no dependa de la plataforma:
| Feature Vercel | Alternativa Agnóstica |
|---|---|
| ISR | Cache externa (Redis) + revalidación on-demand vía webhook |
| Edge Middleware | API routes normales o reglas de reverse proxy |
| `next/image` | Cloudinary, imgix, o un CDN con optimización |
| Serverless Functions | Docker en VPS (Fly, Railway, o un servidor dedicado) |
Aquí un ejemplo de cómo migrar ISR a un enfoque agnóstico con Redis:
```typescript
// app/page.tsx — versión portable con Redis
import { redis } from '@/lib/redis';
export const dynamic = 'force-dynamic'; // Sin ISR nativo
export default async function Page() {
// Intentar cache en Redis primero
const cached = await redis.get('page:home');
if (cached) {
return <div>{JSON.parse(cached).title}</div>;
}
// Cache miss: obtener datos frescos
const data = await fetch('https://api.example.com/data');
const json = await data.json();
// Guardar en Redis con expiración
await redis.setex('page:home', 3600, JSON.stringify(json));
return <div>{json.title}</div>;
}
```
```typescript
// app/api/revalidate/route.ts — endpoint de revalidación on-demand
import { redis } from '@/lib/redis';
export async function POST(request: Request) {
const { secret } = await request.json();
if (secret !== process.env.REVALIDATION_SECRET) {
return Response.json({ error: 'No autorizado' }, { status: 401 });
}
// Invalidar cache en Redis
await redis.del('page:home');
return Response.json({ revalidated: true });
}
```
*Este enfoque funciona en Vercel, en AWS, en Fly, en tu portátil. Esa es la portabilidad. *
Paso 4: Añade una Capa de Abstracción de Deploy
Configura tu CI/CD para apuntar a múltiples proveedores:
Vercel: Para preview deployments y entorno de staging
AWS Lambda + CloudFront (via OpenNext): Para producción
Docker + VPS: Para failover o entornos regulados
OpenNext es un adaptador open-source que permite desplegar Next.js en AWS Lambda. Tiene más de 2.500 estrellas en GitHub y la comunidad lo mantiene activamente. *No es production-ready para todos los casos de uso, pero probar tu build contra él te revela exactamente dónde está tu dependencia de Vercel. *
```bash
Ejemplo de deploy con OpenNext
npx opennext@latest build
Genera un bundle compatible con AWS Lambda + CloudFront
```
Paso 5: Ejecuta Tests de Integración Contra Ambos Entornos
El verdadero problema no es que el lock-in exista. Es que no sabes que existe hasta que algo se rompe en producción. La solución: tests automatizados que comparen el comportamiento entre Vercel y tu entorno alternativo.
```typescript
// tests/portability.test.ts — test de integración cross-platform
import { expect, test } from 'vitest';
const VERCEL_URL = 'https://tu-app.vercel.app';
const ALTERNATIVE_URL = 'https://tu-app.fly.dev';
test('ISR cache behavior should match across platforms', async () => {
const vercelResponse = await fetch(`${VERCEL_URL}/page-with-isr`);
const alternativeResponse = await fetch(`${ALTERNATIVE_URL}/page-with-isr`);
expect(vercelResponse.status).toBe(alternativeResponse.status);
// La respuesta puede diferir en contenido, pero no en disponibilidad
});
```
*Si no puedes ejecutar el mismo test contra dos plataformas, no tienes portabilidad. Tienes suerte. *
El Contraargumento: El Lock-In es la Feature, No el Bug
Dirás: "Tengo cero planes de irme de Vercel. ¿Para qué complicarme?"
Es una postura razonable. Vercel te da acceso a las últimas features de Next.js antes que nadie. La integración es impecable. El equipo de producto prioriza la experiencia del desarrollador.
El problema no es que te quedes. El problema es que *no tienes ni idea de lo que costaría irte. *
Piénsalo como un seguro. No contratas un seguro de hogar porque planees quemar tu casa. Lo contratas porque si pasa, no te arruinas. El Marco de Portabilidad de 5 Capas es tu seguro arquitectónico.
Y hay un escenario que nadie quiere considerar: ¿qué pasa si Vercel cambia los precios? ¿Si elimina el plan gratuito? ¿Si una empresa adquirente redirige la hoja de ruta? Las plataformas cambian. *Tu código, si lo haces bien, no debería. *
La Acción Concreta
Abre tu terminal ahora. Ejecuta el audit del Paso 1. En 5 minutos sabrás exactamente cuánto de tu app depende de Vercel.
Luego decide si quieres jugar a la lotería o tener un plan.
*El Marco de Portabilidad de 5 Capas no te pide que abandones Vercel. Te pide que elijas quedarte, no que te conformes. *
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