El Problema de Vercel No es el Precio. Es que Construyes tu Proyecto sobre APIs que No Son Tuyas

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:

El framework — Next.js. Lo crearon, lo mantienen, y el roadmap lo decide Vercel como empresa.
El runtime — Edge Runtime. Basado en Web APIs, pero con gaps significativos respecto a Node.js.
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.

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.

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.

*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.

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.

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.

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. *