Vercel No es un Hosting Barato: Es un Propietario con Cargo de Traslado
Vercel no es un host barato: es vendor lock-in con ISR, Edge Functions y analytics propietarios. Framework de 5 pasos para auditar tu dependencia y salir sin reescribir.
Vercel No es un Hosting Barato: Es un Propietario con Cargo de Traslado
La sabiduría convencional dice: Vercel es la forma más fácil de desplegar Next.js con zero-config. Pinchas un repo, tecleas un `git push`, y en segundos tienes preview deployments, SSL, CDN global, y un dashboard que te hace sentir que dominas la infraestructura.
*La realidad es que Vercel optimiza para la experiencia de registro, no para la de salida. *
Cada feature que te enamora en el dashboard —ISR en el edge, Edge Config, KV storage, Analytics, Cron Jobs, Speed Insights— es un ancla que ata tu código a su runtime propietario. No es que Vercel sea mal hosting. Es que su modelo de negocio no es venderte servidores; es hacer que sea tan cómodo quedarse que el coste de irte sea psicológica y técnicamente prohibitivo.
Elegir Vercel por simplicidad no es elegir un host. Es firmar un contrato arquitectónico que será más caro de romper que migrar de AWS a Azure. Y lo peor es que la mayoría de los equipos no leen la letra pequeña hasta que están pagando la fianza de salida.
El Lock-In No es un Bug. Es la Feature
Vercel no es "hosting con esteroides". Es un runtime propietario disfrazado de plataforma de deploy. La compañía ha construido un ecosistema donde cada integración vertical —desde el almacenamiento KV hasta el sistema de análisis— está diseñada para funcionar impecablemente dentro de sus fronteras y fallar silenciosamente fuera de ellas.
*El mayor error que cometen los equipos es tratar Vercel como si fuera un Apache compartido pero con mejor UI. *
No lo es. Apache compartido ejecuta PHP estándar. Lo subes a cualquier servador y funciona. Vercel ejecuta un runtime que modifica el comportamiento de tu framework en tiempo de build, inyecta dependencias, sobreescribe configuraciones de rutas, y te ofrece APIs que simplemente no existen en ningún otro lugar.
| Feature | ¿Funciona fuera de Vercel? |
|---------|---------------------------|
| ISR (Incremental Static Regeneration) en el edge | ❌ No. Self-hosted requiere un cache handler personalizado como `@neshca/cache-handler`. Ni siquiera funciona out of the box con `next start`. |
| Edge Functions (`@vercel/edge`) | ❌ No. Cloudflare Workers y Netlify Edge Functions usan APIs distintas. `NextRequest` y `NextResponse` no existen fuera de Vercel. |
| Edge Config | ❌ No. No hay equivalente self-hosted. Es un feature flag store que solo vive en el edge de Vercel. |
| KV Storage | ❌ No. Es una integración con Redis gestionada por Vercel. Migrar a Upstash o Redis propia requiere reescribir todas las queries. |
| Analytics / Speed Insights | ❌ No. `@vercel/analytics` y `@vercel/speed-insights` inyectan tracking que solo funciona en el dominio de Vercel. |
| Cron Jobs | ⚠️ Parcialmente. Vercel los ejecuta como Edge Functions con un scheduler interno. Fuera, necesitas cron jobs externos o un worker. |
| Cache API (`revalidatePath`, `revalidateTag`) | ❌ No. Funciona solo en infraestructura de Vercel. Self-hosted necesitas un adapter de caché. |
Cada checkmark en esa tabla no es una feature. Es una dependencia que tendrás que romper si decides irte. Y el problema no es que existan estas dependencias; el problema es que se presentan como "features gratuitas" cuando en realidad son mecanismos de retención.
Para entender la magnitud del problema, basta con observar cómo funciona la industria del software en 2026. Así como el marketing de redes sociales ha visto tácticas que funcionaban hace dos años volverse contraproducentes —como los chatbots de IA intrusivos en mensajes privados que la gente rechaza activamente—, el hosting de aplicaciones ha seguido una trayectoria similar. Lo que antes era una ventaja competitiva (automatización, integración profunda, "todo en una caja") se ha convertido en una fuente de dependencia que los equipos no anticiparon.
Cuando Snapchat forzó su chatbot de IA en las bandejas de entrada de todos los usuarios en 2023, la calificación de la app en la App Store estadounidense cayó a 1,67 estrellas, con el 75% de las reseñas otorgando una estrella. Los usuarios no habían pedido esa integración. Del mismo modo, los equipos de desarrollo no pidieron explícitamente un runtime propietario que secuestrara su lógica de negocio. Simplemente aceptaron la comodidad sin preguntar por el coste de salida.
El Precio Oculto del "Zero-Config"
Vercel se vende como "funciona sin configurar nada". Y es verdad —para el primer deploy. Pero ese zero-config inicial es el cebo. El anzuelo está en las decisiones arquitectónicas que tomas sin saber que las estás tomando.
El problema es que el build system de Vercel aplica heurísticas que cambian el comportamiento de tu app. Detecta automáticamente tu framework, inyecta build plugins, variables de entorno, y sobreescribe rutas. No te pide permiso. Te lo oculta tras un dashboard bonito.
*Tu app se comporta distinto en `vercel dev` que en `next dev`. *
Y se comporta distinto en producción Vercel que en un Docker container. Esto no es una exageración. Es un hecho comprobable: el middleware de Next.js, que debería ser estándar, se ejecuta en el edge de Vercel con APIs que no forman parte del estándar web. Las Server Actions que usan `revalidateTag` funcionan porque Vercel inyecta su propio sistema de caché. Fuera de ahí, todo se rompe.
Los equipos descubren esto cuando su staging environment se rompe silenciosamente después de que una actualización de Vercel cambia una heurística de build. O cuando intentan mover su app a un VPS para ahorrar costes y descubren que el ISR no funciona, el middleware lanza errores, y las analytics dejan de recoger datos. No es que hayan hecho algo mal. Es que nunca les dijeron que estaban atados.
Es un fenómeno similar al que ocurre en el marketing con los avatares de IA generados por inteligencia artificial. Según la encuesta Sprout Social Pulse, el 46% de los usuarios de redes sociales dicen no sentirse cómodos con que las marcas utilicen influencers de IA. La investigación citada por expertos del sector muestra que el contenido generado por IA, incluidos los avatares, es percibido por las audiencias como publicidad deshumanizada, carente de la empatía y el toque humano que genera confianza. Los equipos de marketing adoptaron estas herramientas por su comodidad y bajo coste inicial, pero el coste a largo plazo —pérdida de confianza, backlash, regulación— superó con creces el beneficio inmediato.
Con Vercel ocurre exactamente lo mismo. La comodidad inicial de "pinchar y desplegar" oculta un coste arquitectónico que solo se manifiesta cuando intentas ejercer tu libertad de elección.
❌ El enfoque débil: "Mi app es pequeña, nunca necesitaré migrar. Esto no me aplica."
✅ El enfoque real: "El lock-in más peligroso es el que no planificas. Hoy es un side project. Mañana es una startup con 50.000 usuarios y una deuda arquitectónica que duele."
El Caso Real: Lo Que Duele No es la Migración Técnica. Es la Arquitectónica
Imagina que tu app usa ISR para páginas de producto. Tienes 10.000 URLs que se regeneran bajo demanda con `revalidateTag`. Funciona perfecto en Vercel. Las páginas se sirven rápido, la invalidación ocurre en milisegundos, y tu equipo ni siquiera piensa en ello.
Ahora decides migrar a un servidor propio o a Cloudflare Pages.
El problema no es mover los ficheros. El problema es que `revalidateTag` no existe fuera de Vercel. No es que tengas que reconfigurar algo. Es que tienes que implementar tu propio sistema de invalidación de caché con Redis, un worker de purga, y un adapter personalizado. Necesitas decidir cómo almacenas el mapa de tags a URLs, cómo purgas de forma atómica, y cómo aseguras que la regeneración no deje tu sitio serviendo contenido obsoleto.
Eso no es "ajustar la configuración". Es una reescritura que puede llevar semanas.
Y si además usas Edge Config para feature flags y Middleware para redirecciones basadas en geolocalización —todo integrado con `@vercel/edge`— la migración se convierte en un proyecto de varias semanas. Cada integración es un módulo que dejará de funcionar. Cada API propietaria es una deuda que vence.
*El verdadero coste de Vercel no son los euros del plan Pro. Es el trabajo de ingeniería necesario para salir. *
Piensa en ello en términos de ingeniería: una migración de AWS a Azure, aunque tediosa, implica mover servicios equivalentes. RDS a Azure SQL. S3 a Blob Storage. Lambda a Azure Functions. Son caros y requieren trabajo, pero el mapa de equivalencias está trazado. Hay guías, herramientas, y consultores que lo han hecho cientos de veces.
Migrar desde Vercel no tiene ese mapa. Porque Vercel no es un servicio de infraestructura: es una plataforma que te vende productividad a cambio de lealtad. Y como cualquier plataforma que opera con ese modelo, la salida es el producto que nunca quisieron que compraras.
El Marco de 5 Pasos para Auditar tu Dependencia de Vercel
Llamémoslo El Marco de Portabilidad Forzada. Funciona así: asumes que mañana mismo Vercel desaparece o cambia sus precios drásticamente, y tu app tiene que funcionar en otro sitio en un plazo máximo de una semana. ¿Cuánto tardas en tenerla operativa? ¿Puedes responder a esa pregunta con precisión?
Si no puedes, este marco es para ti.
Paso 1: Audit de Superficie de Ataque Propietaria
Abre tu `package.json`. Busca todo lo que empiece por `@vercel/`.
```json
// package.json — busca estas dependencias
"@vercel/analytics": "^1.0.0",
"@vercel/speed-insights": "^1.0.0",
"@vercel/edge": "^1.0.0",
"@vercel/kv": "^1.0.0",
"@vercel/blob": "^1.0.0"
```
Cada una de esas líneas es un punto de anclaje. Pero no te detengas en `package.json`. El lock-in más peligroso no está en las dependencias declaradas, sino en las tácitas: middleware que usa `NextRequest`, Server Actions que llaman a `revalidateTag`, page layouts que asumen ISR en el edge, cron jobs definidos en `vercel.json`, y variables de entorno que solo existen en el dashboard de Vercel.
El objetivo es tener visibilidad total de lo que te ata. Haz una hoja de cálculo con cada dependencia, su propósito, y una estimación del esfuerzo necesario para reemplazarla. Este documento, por sí solo, ya te está dando información que probablemente no tenías.
Paso 2: Abstrae las Dependencias Detrás de Interfaces
No importes `@vercel/kv` directamente en tu lógica de negocio. Esa es la receta para el desastre. Crea un adapter que desacople tu código de la implementación concreta:
```typescript
// cache-adapter.ts — abstracción portable
export interface CacheAdapter {
get(key: string): Promise<string | null>;
set(key: string, value: string, ttl?: number): Promise<void>;
invalidate(tag: string): Promise<void>;
}
// vercel-implementation.ts
import { kv } from '@vercel/kv';
export const vercelCache: CacheAdapter = {
get: (key) => kv.get(key),
set: (key, value, ttl) => kv.set(key, value, { ex: ttl }),
invalidate: (tag) => kv.del(tag),
};
// redis-implementation.ts — para cuando migres
import { Redis } from '@upstash/redis';
export const redisCache: CacheAdapter = {
get: (key) => redis.get(key),
set: (key, value, ttl) => redis.setex(key, ttl!, value),
invalidate: async (tag) => { / lógica de purga por tag / },
};
```
El resto de tu código no sabe si estás en Vercel, Redis, o SQLite. Eso es portabilidad real. Y lo mejor es que este patrón no es específico de caché: aplícalo a Edge Config, Blob Storage, Analytics, y cualquier otra integración propietaria. Cada adapter que escribes es una póliza de seguro contra el lock-in.
Paso 3: Despliega en un Segundo Proveedor y Tira la Suite de Tests
No esperes a necesitar migrar. Configura un staging en Netlify, Cloudflare Pages o un servidor propio. Corre tu test suite completo.
Vas a encontrar sorpresas. Siempre las hay. Middleware que falla porque `NextRequest` no existe fuera del contexto de Vercel, ISR que no regenera porque el cache handler no está configurado, analytics que no recolectan datos porque el script de tracking apunta a un endpoint inexistente, cron jobs que no se ejecutan porque no hay scheduler.
Resuélvelas ahora, no cuando estés contra reloj. Cada error que encuentres en staging es una oportunidad para hacer tu código más robusto. Cada dependencia que descubras es una lección sobre cómo no diseñar sistemas.
Este paso tiene un beneficio colateral importante: te obliga a escribir tests que cubren el comportamiento real de tu app en diferentes entornos, lo que mejora la calidad general del software.
Paso 4: Sustituye Middleware Propietario por Web Standards
`NextRequest` y `NextResponse` son comodidades de Vercel. Pero el estándar web es `Request` y `Response`. Y los estándares web son la única garantía de portabilidad real a largo plazo.
```typescript
// ❌ Atado a Vercel
import { NextRequest, NextResponse } from 'next/server';
export function middleware(request: NextRequest) {
const country = request.geo?.country;
return NextResponse.redirect(new URL(`/${country}`, request.url));
}
// ✅ Portable
export function middleware(request: Request) {
const country = request.headers.get('x-vercel-ip-country') || 'ES';
return Response.redirect(new URL(`/${country}`, request.url));
}
```
El segundo bloque funciona en cualquier runtime que soporte el estándar web. Cloudflare Workers, Deno, Bun, Node 20+. No importa dónde despliegues: el código es el mismo.
Este principio aplica a más que middleware. Tus Server Actions deberían devolver `Response` estándar. Tus API routes deberían usar `Request` y `Response` nativos. Cada vez que usas una abstracción propietaria, pregúntate: "¿Puedo escribir esto con APIs estándar del navegador?" Si la respuesta es sí, hazlo. Si es no, pregúntate por qué estás usando esa feature.
Paso 5: Documenta un Pipeline de Build Agnóstico
Tu `next.config.js` no debería tener flags específicas de Vercel que rompan en otros entornos. Un buen pipeline de build es aquel que produces el mismo artefacto independientemente de dónde se ejecute.
```typescript
// next.config.ts — portable
const nextConfig = {
output: process.env.DOCKER ? 'standalone' : undefined,
images: {
// No uses imágenes solo de Vercel Blob
remotePatterns: [
{ protocol: 'https', hostname: '**.vercel-storage.com' },
{ protocol: 'https', hostname: '**.s3.amazonaws.com' },
{ protocol: 'https', hostname: '**.cloudinary.com' },
],
},
};
export default nextConfig;
```
Un único comando para build local, Vercel, y Docker. Sin sorpresas, sin configuraciones mágicas que solo existen en el dashboard de Vercel, sin heurísticas de build que cambian silenciosamente el comportamiento de tu aplicación.
Documenta también el proceso de deploy: qué variables de entorno son necesarias, qué secretos hay que configurar, qué pasos de post-build se requieren. Este documento es tu salvavidas cuando llegue el momento de migrar.
La Alternativa Real No es Netlify. Es AWS
La comparación justa no es Vercel vs. Netlify. Es Vercel vs. AWS con Docker. Cambiar de un proveedor propietario a otro similar no resuelve el problema fundamental; solo cambia el nombre del casero.
El camino más pragmático para apps Next.js en producción que necesitan portabilidad es un despliegue Dockerizado en AWS Fargate o ECS con un CDN por delante (CloudFront). No es la opción más sexy, pero es la que te da libertad real.
❌ Pierdes: instant rollbacks, preview deployments, zero-config, la sensación de que todo es mágico.
✅ Ganas: control total sobre caching, escalado, costes, la libertad de irte cuando quieras, y la capacidad de auditar cada aspecto de tu infraestructura.
El trade-off es simple: complejidad operativa hoy vs. deuda arquitectónica mañana. Y la mayoría de los equipos elige la primera opción no porque sea mejor, sino porque es más fácil de vender al negocio. "Lo desplegamos en dos clics" suena mejor que "invertimos dos semanas en configurar un pipeline de CI/CD reproducible".
*La mayoría de equipos subestima la deuda arquitectónica hasta que es demasiado tarde. *
Así como los equipos de marketing que adoptaron avatares de IA sin preguntarse cómo reaccionaría su audiencia, los equipos de desarrollo adoptan Vercel sin preguntarse cómo será la migración. El patrón es el mismo: una solución que parece barata y rápida hoy, pero que acumula un coste oculto que se dispara cuando intentas cambiar de dirección.
Y al igual que la regulación está alcanzando a la IA generativa —con la Ley de IA de la UE y la FTC estadounidense impulsando requisitos de divulgación obligatoria para contenido generado por IA—, el mercado del hosting está madurando hacia una exigencia de portabilidad. Los equipos que ya han pasado por una migración dolorosa están empezando a exigir transparencia sobre las dependencias propietarias antes de firmar contratos.
La Única Pregunta Que Importa
No es "¿Vercel es bueno o malo?". Vercel es excelente para ciertos casos: proyectos pequeños, MVPs rápidos, prototipos que validan una idea, apps internas con pocos usuarios. Para esos escenarios, la velocidad de desarrollo que ofrece es inigualable.
La pregunta real es:
*¿Sabes exactamente lo que te costaría irte? Sí o no. *
Si no puedes responder con un número de días de ingeniería y una lista de dependencias, tu arquitectura ya está comprometida. No importa lo bien que funcione hoy. No importa lo bonito que sea el dashboard. Estás construyendo sobre terreno que no controlas.
El Marco de Portabilidad Forzada te lleva menos de un día de implementar. Y te ahorrará semanas —o meses— cuando llegue el momento de salir. No porque Vercel sea malo, sino porque cualquier plataforma que controla tu runtime es un riesgo que merece ser medido.
Porque en 2026, el verdadero lujo no es el zero-config. Es poder elegir dónde corre tu código. Es tener la certeza de que, si mañana las condiciones cambian, tu aplicación no se queda atrapada en un ecosistema del que no puedes escapar.
La portabilidad no es un lujo. Es el requisito mínimo para llamarte profesional.
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