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:
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.
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:
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:
*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. *
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.
*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. *
Artículos relacionados
- Tu Deploy en Vercel No Es Gratis: El Precio Oculto del Vendor Lock-In Que Pagarás con una Rewrite
- El Precio Oculto del Zero-Config en Vercel: 50ms de Cold Start Que Te Van a Costar Clientes
- Vercel No es un Hosting Barato: Es un Propietario con Cargo de Traslado
- 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
---
¿Quieres recibir contenido como este cada semana? Suscríbete a mi newsletter
