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
- Edge Middleware —
NextResponse.next(),request.cookies,request.geo. Funciona en Vercel. Se rompe en Node.js puro y en Cloudflare Pages. - ISR con revalidación on-demand —
revalidatePath('/blog')yrevalidateTag('posts')dependen de la API de invalidación de caché propietaria de Vercel. - `@vercel/kv`, `@vercel/blob`, `@vercel/postgres` — Cada uno es un servicio propietario sin capa de compatibilidad con Redis, S3 o PostgreSQL estándar.
- Edge Functions — Sub-50ms de cold start, pero con un límite de 50ms de CPU time y 128MB de memoria. Sin
fs, sinchild_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:
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:
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.
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.cookiescon la API de Next.js y casca fuera de Vercel - Rutas que dependen de
@vercel/analyticspara 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.
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.
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
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
- Audita tu lock-in el día 1 — identifica qué APIs son Vercel-exclusive antes de escribir negocio sobre ellas
- Testea fuera de Vercel en la semana 1 — un Dockerfile y un
node next startte ahorran sorpresas 18 meses después - Abstracte tu capa de datos — una interfaz de 3 métodos te permite cambiar de Redis a KV sin reescribir la app
- Escribe middleware portable —
Request/Responseestándar, noNextRequest/NextResponse - 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.
Artículos relacionados
- Vercel Deployment Best Practices: El Framework de 5 Pasos para Desplegar Sin Pagar el Peaje del Lock-In
- El Problema de Vercel No es el Precio. Es que Construyes tu Proyecto sobre APIs que No Son Tuyas
- Vercel en Producción: La Guía Definitiva de Deployment que Nadie Escribe
- Vercel No es un Hosting Barato: Es un Propietario con Cargo de Traslado
- El Precio Oculto del Zero-Config en Vercel: 50ms de Cold Start Que Te Van a Costar Clientes
---
¿Quieres recibir contenido como este cada semana? Suscríbete a mi newsletter
