Tu Deploy "Gratis" en Vercel Te Cuesta Más de lo que Crees — En Libertad Arquitectónica
Tu app funciona. El build pasa. El preview deployment se ve genial. Todo perfecto.
Hasta que tu cliente dice: "¿Puedo llevarlo a mi propio servidor?"
Y descubres que tu app no se despliega en ningún sitio que no sea Vercel.
*El verdadero coste de Vercel no son los dólares del plan Pro. Es la deuda arquitectónica que acumulas silenciosamente con cada feature propietaria que integras. *
El 95% de los proyectos en Vercel podrían funcionar igual o mejor en un VPS de 6 €, Cloudflare Pages, o un Docker en Hetzner. Pero cuando descubres que tu app depende de ISR, Edge Config, Vercel KV, y el SDK de Vercel AI, ya es tarde.
Tu app no es portable. Es una dependencia emocional con una plataforma.
---
La Trampa del "Zero-Config"
Vercel vende "zero-config deployment" como un beneficio. Suena genial.
*La realidad: cada configuración que Vercel abstrae es una decisión que han tomado por ti. *
❌ Crees que controlas tu deploy. En realidad:
- La estrategia de caché es opaca
- El pipeline de build corre en su runtime, no en el tuyo
- Las rutas de API se resuelven con reglas que no puedes inspeccionar
- Los Edge Functions tienen un subconjunto limitado de la API de Node.js
- El timeout de serverless functions es fijo y no negociable
Cuando algo se rompe en producción — una caché servida desde stale, una variable de entorno que no se propaga, un Edge Function que excede el límite de tiempo — no tienes knobs que girar. Solo tickets de soporte.
✅ El enfoque portable: Escribe tu propia configuración desde el día uno. Dockerfile. Nginx o Caddy. CDN configurable. Si tu app se despliega en Vercel y en un VPS con el mismo comando (docker compose up), has ganado.
Para una landing page, Vercel es perfecto. Para una app con autenticación y pagos, es peligroso tener cero control sobre el runtime.
---
ISR: La Feature Más Innovadora — y la Más Pegajosa
Incremental Static Regeneration es genuinamente útil. Generas páginas estáticas que se actualizan bajo demanda.
Pero mira cómo lo implementa Vercel:
Parece inocente. El `revalidate: 60` promete una regeneración cada minuto. Pero la realidad es que Vercel usa una ventana fuzzy — no es un TTL exacto. La página se regenera "cuando Vercel decide" dentro de esa ventana.
Ahora intenta auto-alojar ISR:
Self-hostear ISR requiere: un servidor Node.js custom, Redis compartido entre instancias, y purgado de CDN manual. Netlify tiene On-Demand Builders. Cloudflare tiene su propia versión de ISR. Ninguno es drop-in replacement.
*ISR no es portable por accidente. Fue diseñado para no serlo. *
---
Edge Middleware: La API que No Usarás Fuera de Vercel
Vercel Edge Middleware es potente. Geolocalización, A/B testing, redirecciones en el edge.
Pero su API es propietaria:
Ese @vercel/edge no funciona en Cloudflare Workers. No funciona en Deno Deploy. No funciona en ningún sitio que no sea Vercel.
La misma lógica con un Cloudflare Worker estándar:
La diferencia no es funcional. Es estratégica. Vercel te da una API cómoda que no puedes llevar a otra parte. Cloudflare te da una API estándar (el objeto Request/Response nativo de la Web) que funciona en cualquier runtime edge.
---
El Framework de 5 Pasos para Auditar tu Dependencia de Vercel
Llamémoslo el Marco de Portabilidad Inversa: antes de añadir una feature de Vercel, construye primero la abstracción que te permita quitarla.
1. Audita tu Superficie de API de Vercel
Abre tu package.json. Mira todas las dependencias @vercel/*.
Edge Config, KV, Blob, AI SDK, Edge Middleware, ISR con revalidate.
Etiqueta cada una como:
- Portátil — se puede reemplazar con una API estándar en < 1 día
- Reemplazable con esfuerzo — requiere Redis, CDN configurable, o un worker custom (1-3 días)
- Lock-in crítico — sin equivalente fuera de Vercel (requiere rewrite)
Si tienes más de 2 en la tercera categoría, estás en una posición frágil.
2. Construye una Abstraction Layer por Adelantado
No escribas esto:
Escribe esto:
Tu negocio no debería saber qué cache store usas. Si mañana migras de Vercel KV a Upstash Redis, el cambio es una línea en el archivo de configuración.
3. Benchmark contra Alternativas Más Simples
Despliega tus páginas estáticas en Cloudflare Pages. Tus rutas de API en Fly.io o Railway.
Mide TTFB real con usuarios reales. Te sorprenderá la frecuencia con la que la CDN de Vercel no aporta una mejora medible frente a Cloudflare, que es gratis.
4. Haz un Deployment Fuera de Vercel Antes de que Sea Urgente
Clona tu repo. Despliega en un droplet de DigitalOcean o un VPS de Hetzner con Docker + Caddy.
Corre un Lighthouse audit. Si la diferencia es marginal, tu plan "gratis" de Vercel tiene un impuesto de migración invisible que está acumulando intereses.
5. Adopta Infraestructura Agnóstica al Framework
Astro, SvelteKit, o incluso Next.js desplegado via Docker a un cloud provider genérico.
La clave: framework y plataforma deben ser decisiones independientes. Elegir Next.js no debería obligarte a Vercel. Elegir Vercel no debería obligarte a Next.js.
---
El Síndrome de Estocolmo del Desarrollador
La defensa más común: "Vercel es gratis para proyectos personales."
Cierto. Pero gratis es el gancho clásico del lock-in. El coste no es monetario — es la complejidad y dependencia que se acumula hasta que superas el free tier.
Tu proyecto personal se convierte en tu portfolio. Tu portfolio se convierte en un freelance. Tu freelance escala. Y de repente pagas 200 € al mes porque tu app "necesita ISR", "necesita Edge Config", "necesita Vercel KV".
Y no puedes quitarlos. No sin una rewrite.
"Vercel's DX es imbatible, y el tiempo de developer es caro."
Es cierto a corto plazo. Pero refactorizar fuera de una plataforma acoplada cuesta mucho más tiempo de developer que la "sobrecarga de configuración" de un setup portable.
La decisión real es: pagas complejidad ahora (arquitectura portable, aburrida) o la pagas después (crisis de migración bajo presión de deadline).
---
La Simbiosis Next.js + Vercel es Intencional
Vercel emplea a los mantenedores principales de Next.js. Los RFCs y roadmaps de Next.js se alinean con las capacidades de la plataforma Vercel.
No es una conspiración. Es un modelo de negocio.
Pero como developer, deberías reconocer que elegir Next.js es elegir implícitamente las opiniones arquitectónicas de Vercel. Alternativas como Astro, SvelteKit, o Nuxt no tienen esa lealtad de plataforma. Su build output es genuinamente portable.
*No digo que dejes de usar Vercel. Digo que sepas lo que estás firmando. *
---
Conclusión: La Mejor Arquitectura es la que Puedes Abandonar
Tu app no debería depender de una plataforma para funcionar. Debería funcionar en cualquier sitio que ejecute JavaScript.
Vercel es una herramienta excelente para deploy. Pero trata cada feature propietaria como lo que es: una decisión de arquitectura que un día tendrás que deshacer.
El Marco de Portabilidad Inversa no es teoría. Lo aplico en cada proyecto que envío. El Agente Conversor IAE CNAE que construí para España despliega en Cloudflare Workers, no en Vercel. No porque Vercel sea malo, sino porque cada tool call, cada tool input con Zod validation, y cada Durable Object session es mío — no de su plataforma.
Construye como si fueras a migrar mañana. Porque probablemente lo harás.
Y cuando llegue ese día, no querrás estar mirando 50 archivos que dependen de @vercel/* preguntándote por qué no hiciste esto antes.
Artículos relacionados
- Vercel Deployment Best Practices: The 5 Mistakes Tripling Your Costs
- Vercel Edge Middleware: Los 4 Patrones que el 90% Implementa Mal
- ISR Strategies en Next.js: La Decisión de Renderizado que Separa el Rendimiento del Caos
- Optimización de Serverless Functions en Vercel: El Patrón que Reduce Cold Starts un 70%
- Vercel Deployment Best Practices: Lo Que Nadie Te Cuenta Sobre Observabilidad y Rollbacks
---
¿Quieres recibir contenido como este cada semana? Suscríbete a mi newsletter
