El Problema de Vercel No es el Precio. Es que Construyes tu Proyecto sobre APIs que No Son Tuyas
Vercel no es solo hosting. ISR, Edge Middleware y @vercel/og te atan a su plataforma. Aprende a auditar tu dependencia con el Framework de Portabilidad Forzada.
Tu Proyecto Next.js Funciona Perfecto en Vercel. Exactamente por Eso Deberías Preocuparte
El 90% de los desarrolladores trata Vercel como "un hosting". Como Netlify pero más rápido. Como una plataforma de deploy intercambiable.
*Error. *
Vercel no es solo donde pones tu código. Es quien decide cómo se ejecuta, qué APIs puedes usar, y cómo de caro te va a salir irte.
La narrativa oficial es que Edge Runtime usa estándares web — Request, Response, fetch. Que Next.js es open source. Que puedes migrar cuando quieras.
*La realidad es que muchas features de Next.js —ISR con revalidación on-demand, Edge Middleware, Image Optimization, generación de OG con @vercel/og— o no funcionan o funcionan distinto fuera de Vercel. *
No es que Vercel sea malo. Es tan bueno que te hace olvidar que algún día podrías querer irte. Y cuando llega ese día —por regulación de datos, por costes, o porque tu cliente exige otro proveedor— descubres que tu arquitectura entera está cableada a una sola plataforma.
El problema no es el lock-in binario. Es el lock-in incremental. Cada nueva feature que añades es un clavo más en el ataúd de tu portabilidad.
---
El Contrato Invisible: No es Hosting, es un Ecosistema Verticalmente Integrado
Vercel controla tres capas que ningún otro proveedor puede replicar:
1. El framework — Next.js. Lo crearon, lo mantienen, y el roadmap lo decide Vercel como empresa.
2. El runtime — Edge Runtime. Basado en Web APIs, pero con gaps significativos respecto a Node.js.
3. La plataforma — Vercel. Donde todo funciona porque diseñaron las features sabiendo exactamente cómo iban a ejecutarse.
❌ Lo que la mayoría cree: "Vercel es un hosting como otro cualquiera. Next.js es open source. Puedo cambiarme cuando quiera."
✅ La realidad: Cada feature que usas —ISR, middleware con lógica de routing, Image Optimization con el loader de Vercel— es código que depende de la plataforma. El open source no garantiza neutralidad cuando el 80% de los contributors trabajan para la misma empresa.
Cloudflare Pages es el ejemplo perfecto. También tiene Edge Functions y un runtime basado en estándares web. Pero su integración con Next.js es notablemente peor. Middleware tiene bugs. ISR no existe. La optimización de imágenes requiere configuración manual.
*Esto no es incompetencia de Cloudflare. Es que Vercel tiene acceso anticipado al roadmap de Next.js y puede diseñar features que son difíciles de replicar sin ese conocimiento previo. *
---
Las 4 APIs que Te Atan Sin que te Des Cuenta
1. ISR con Revalidación On-Demand
Incremental Static Regeneration es una de las features más potentes de Next.js. Generas páginas estáticas y las actualizas bajo demanda cuando los datos cambian.
El problema: `revalidatePath` y `revalidateTag` son APIs de Next.js 13+ App Router que dependen del sistema de caché de Vercel. Fuera de Vercel, o no funcionan o requieren una configuración de caché que no existe.
```typescript
// ✅ Esto funciona en Vercel
import { revalidateTag } from 'next/cache'
export async function POST(request: Request) {
const data = await request.json()
// Actualiza la entrada en caché
revalidateTag(`post-${data.slug}`)
return Response.json({ revalidated: true })
}
// ❌ En otro hosting, revalidateTag puede no tener efecto
// porque el sistema de caché subyacente no es el mismo
```
El `unstable_cache` de Next.js —ahora estable en 2026— es otro ejemplo. Cachea datos a nivel de framework, pero el almacenamiento real depende de Vercel. Si migras a un VPS con `next start`, esa caché simplemente desaparece.
2. Edge Middleware
El middleware de Next.js se ejecuta en el Edge Runtime. Esto significa que corre antes de que la request llegue a tu servidor, con latencias mínimas.
El problema: Edge Runtime no soporta módulos nativos de Node.js. Ni `fs`, ni `path`, ni `crypto` completo. Los paquetes npm que dependen de estas APIs simplemente fallan.
```typescript
// ✅ Edge Middleware — funciona en Vercel
import { NextResponse } from 'next/server'
import type { NextRequest } from 'next/server'
export function middleware(request: NextRequest) {
const country = request.geo?.country || 'ES'
const response = NextResponse.next()
response.cookies.set('country', country)
return response
}
// ❌ El mismo middleware ejecutado como Node.js middleware tradicional
// No tendría acceso a request.geo (API de Vercel)
// Y tendrías que implementar la detección de país con otra librería
```
El límite de tamaño del middleware es de 1.5MB sin comprimir. Si tu lógica crece, no puedes escalar el middleware —tienes que repensar la arquitectura.
3. Image Optimization con el Loader de Vercel
Next.js Image component es increíble. Redimensiona, optimiza y sirve imágenes en formato moderno (WebP, AVIF) automáticamente.
El problema: el loader por defecto usa el servicio de optimización de imágenes de Vercel. Cambias de plataforma, y o configuras un loader personalizado o las imágenes se rompen.
```typescript
// ✅ Configuración que funciona en Vercel
// next.config.js
module.exports = {
images: {
remotePatterns: [
{ protocol: 'https', hostname: 'cdn.midominio.com' }
]
}
}
// ✅ La misma app, pero portable — con loader personalizado
// components/ImageWrapper.tsx
import Image from 'next/image'
function CustomLoader({ src, width, quality }: { src: string; width: number; quality?: number }) {
return `${process.env.NEXT_PUBLIC_IMAGE_SERVICE_URL}/${src}?w=${width}&q=${quality || 75}`
}
export function PortableImage(props: any) {
return <Image loader={CustomLoader} {...props} />
}
```
*La abstracción está ahí —el loader API de Next.js—, pero el 90% de los proyectos no la usa. * Y cuando migran, tienen que refactorizar cada imagen del sitio.
4. OG Image Generation con @vercel/og
Generar imágenes Open Graph dinámicamente es una feature que parece menor hasta que la necesitas. `@vercel/og` usa Satori y Resvg —librerías que convierten JSX a SVG y luego a PNG.
Solo funciona en Edge Runtime. Específicamente, en el Edge Runtime de Vercel.
```typescript
// ✅ Funciona en Vercel Edge Functions
import { ImageResponse } from '@vercel/og'
export async function GET(request: Request) {
return new ImageResponse(
(
<div style={{ display: 'flex', fontSize: 60, color: 'white', background: 'black' }}>
Mi Título OG
</div>
),
{ width: 1200, height: 630 }
)
}
// ❌ Alternativa portable con sharp
// Requiere Node.js runtime y una función serverless normal
import sharp from 'sharp'
import { createCanvas, loadFont } from 'canvas'
export async function GET(request: Request) {
const canvas = createCanvas(1200, 630)
const ctx = canvas.getContext('2d')
// ... lógica de dibujo manual
const buffer = canvas.toBuffer('image/png')
return new Response(buffer, { headers: { 'Content-Type': 'image/png' } })
}
```
La alternativa portable existe (sharp, canvas, puppeteer), pero requiere más código, más dependencias, y un runtime Node.js completo que no tienes en Edge Functions.
---
El Marco de 5 Pasos para Auditar tu Dependencia de Vercel
Llamémoslo el Framework de Portabilidad Forzada. No esperes a que el cliente te pida migrar. Hazlo ahora.
Paso 1: Audit de Superficie de Ataque Propietaria
Abre tu proyecto y busca sistemáticamente:
`@vercel/*` en `package.json` — cada paquete es un punto de依赖性
`import from 'next/server'` con APIs no estándar
Uso de `unstable_` APIs que cambian entre versiones
`next.config.js` con opciones específicas de Vercel (image loader, headers, rewrites)
Paso 2: Abstrae Detrás de Interfaces
Cada pieza de infraestructura que dependa de Vercel merece su propia abstracción.
```typescript
// CacheProvider — intercambiable entre Vercel y otras plataformas
interface CacheProvider {
get(key: string): Promise<unknown>
set(key: string, value: unknown, ttl?: number): Promise<void>
revalidate(tag: string): Promise<void>
}
// Implementación para Vercel (usa revalidateTag)
// Implementación para Redis (usa Redis client)
// Implementación para Cloudflare (usa KV)
```
Paso 3: Despliega en un Alternativa Durante el Desarrollo
No esperes al último día. Crea un workflow que deploye automáticamente a Netlify, a un Docker self-hosted, o a Cloudflare Pages. Que falle en desarrollo, no en producción.
```bash
Añade un script en package.json
"deploy:portable": "next build && next start --port 3001"
```
Si `next start` se rompe porque tu app depende de variables de entorno de Vercel o de APIs que solo existen en su infraestructura, prefieres saberlo ahora.
Paso 4: Prefiere Web APIs sobre APIs Propietarias
Cada vez que puedas elegir entre una API estándar y una específica de Vercel, elige la estándar.
Usa `Web Crypto` en vez de `crypto` de Node.js
Usa `fetch` nativo en vez de `node-fetch`
Evita el acceso al filesystem (`fs`) en funciones serverless o edge
Usa `Response.json()` en vez de `NextResponse.json()` cuando no necesites features específicas
Paso 5: Documenta tu Deuda Arquitectónica Explícitamente
Crea un `ARCHITECTURE.md` en la raíz de tu proyecto que responda:
¿Qué features requieren Vercel específicamente?
¿Qué coste estimado (en tiempo de desarrollo) tendría migrar cada una?
¿Cuál es el plan de migración para cada feature?
¿Hay features que simplemente no son portables y requerirían reescribirse?
*La mayoría de los equipos no documenta esto porque asume que nunca migrará. Esa asunción es la que hace que migrar sea tan doloroso. *
---
La Objeción que Siempre Surge
"Mi proyecto es pequeño. Nunca voy a necesitar migrar de Vercel."
La mayoría de los proyectos no necesitan migrar. Pero el lock-in no es binario. Es incremental.
Cada nueva feature que depende de Vercel aumenta el coste de salida. Cuando tu startup crece y necesitas cumplir con regulaciones de datos (GDPR, soberanía europea), o cuando el coste de Vercel empieza a subir, o cuando un cliente exige que despliegues en su propia infraestructura... descubres que migrar cuesta semanas de trabajo que no habías presupuestado.
*No se trata de dejar Vercel. Se trata de poder hacerlo sin que duela. *
---
El Mejor Momento para Preparar la Salida es Antes de que la Necesites
Vercel no es el enemigo. Es una plataforma excelente que ha democratizado el deploy para frontend developers.
El problema no es usarla. El problema es usarla como si fuera la única opción.
El Framework de Portabilidad Forzada no te pide que dejes Vercel. Te pide que construyas como si pudieras irte mañana. Que abstraigas. Que documentes. Que pruebes en otros entornos.
Porque la magia de Vercel —esa experiencia de desarrollo impecable— no debería convertirse en tu prisión arquitectónica.
*Tu proyecto funciona perfecto en Vercel hoy. Asegúrate de que pueda funcionar igual de bien fuera de él mañana. *
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