Vercel no Vende Hosting. Vende el Framework que Decide Cómo Escribe tu App — y te lo Da en Alquiler

Todos llaman a Vercel una empresa de hosting. Se equivocan.

Vercel es el vendor de open-source con más influencia en JavaScript ahora mismo — y te alquila los servidores para los que su propio framework fue diseñado.

El debate del "Vercel killer" lleva años apuntando al objetivo equivocado. Se compara precio, latencia y listas de features contra Netlify, Cloudflare Pages o AWS Amplify. Y esa comparación te pierde el punto estructural del negocio. No es que los rivales sean mejores o peores en tabla de especificaciones: es que están jugando un partido distinto que el resto de la industria aún no ha entendido.

*El producto real no es el hosting. Es Next.js. *

Vamos a desmontar la tesis pieza a pieza. Y cuando termines, entenderás por qué la próxima batalla del ecosistema web no se librará por cuántos servidores corre cada uno, sino por quién escribe los defaults que deciden cómo piensa la próxima generación de desarrolladores.

La Jugada Inversa del Lock-In: Legalmente Libre, Arquitectónicamente Atado

Este es el giro que nadie cuenta: Next.js es MIT-licensed. El código es tuyo. Puedes cogerlo, forkearlo y llevarlo a donde te dé la gana sin violar una licencia.

No estás legalmente encerrado.

Este punto merece que nos detengamos, porque contradice todo lo que intuitivamente sospechamos de los ecosistemas que nos atan. Cuando una empresa te da el software gratis y además lo abre con una licencia permisiva, nuestro instinto grita "¿dónde está la trampa?". Pues bien, la trampa no está en la letra pequeña del contrato. Está en la arquitectura que aceptas por defecto cuando escribes tu app.

El next.config.js de tu proyecto asume serverless. Asume edge middleware. Asume streaming. Asume un runtime con características de latencia y caché muy concretas. Cuando el framework te empuja a escribir export const revalidate = 3600 para ISR, o a usar Server Actions para mutaciones, estás tomando decisiones que solo tienen sentido completo dentro del runtime de Vercel.

Migrar a un servidor Node de larga duración o a otro framework no es un redeploy. Es un proyecto de re-arquitectura.

Y ese coste de cambio, no ninguna licencia, es lo que mantiene a los equipos en la plataforma. Es el mismo mecanismo, en espejo, que durante décadas mantuvo a las empresas en bases de datos propietarias: no por el contrato, sino por la deuda estructural acumulada sobre una API concreta.

❌ Lo que la mayoría cree: "Next.js es open source, me voy cuando quiera."

✅ Lo que es verdad: la libertad de licencia y la libertad de migración son cosas distintas. Un app arquitecturada alrededor de Server Actions, streaming y middleware de edge asume semánticas que un Node server pelado no satisface. No es que el código no compile fuera de Vercel: es que se comporta distinto. Los tiempos de caché, las revalidaciones, el comportamiento de los headers: todo se ajusta fino para un runtime gestionado.

El lock-in nunca fue legal. Fue siempre arquitectónico.

Y ojo, esto no es un argumento en contra de Vercel. Es un argumento a favor de la transparencia. Si vas a firmar un compromiso arquitectónico de años, al menos deberías saber qué estás firmando. La mayoría de equipos lo descubren en el peor momento: cuando una factura, una política o una decisión de gobierno corporativo les obliga a salir.

La Evidencia Está en la Estrategia, No en el CDN

Mira la historia con perspectiva. Vercel (como Netlify) empezó vendiendo hosting estático. Luego Next.js 9 introdujo SSR e ISR y Vercel se rebautizó como "frontend cloud".

Ese rebautismo no fue cosmético. Fue un cambio de posición estratégica. Ya no vendías espacio en disco con un CDN encima; vendías un modelo de renderizado. La pregunta "¿dónde corro mi app?" se convirtió en "¿cómo escribo mi app?" — y la segunda pregunta la respondía su framework.

El hilo conductor no es estático vs. dinámico.

*El hilo conductor es que Vercel controla el framework que decide cómo se renderiza tu app. *

Sea cual sea la dirección que tome el ecosistema, la plataforma de Vercel es el destino por defecto. Los competidores pueden copiar features. No pueden copiar la capa de autoría. Pueden replicar un CDN gestionado, una red de edge, o un sistema de previews. No pueden replicar el hecho de que millones de desarrolladores escriben sus apps pensando en las abstracciones de Next.js — y esas abstracciones se ejecutan de forma nativa solo en un sitio.

Ahí están las señales, encadenadas con una coherencia que no es casualidad:

Diciembre 2021: Vercel adquiere Turborepo, el build tool de referencia.
Luego trae a los creadores de Svelte a su equipo.
Next.js 13 (2022) introduce el App Router con React Server Components y Streaming.

Fíjate en la progresión: primero el build tool, luego talento de frameworks rivales, luego la mayor revolución en la semántica de componentes desde que React existe. Esa secuencia no es un collage de adquisiciones oportunistas. Es una estrategia vertical de control de capas.

Una empresa que posee el build tool, el framework y el runtime puede dictar los defaults de los desarrolladores de principio a fin. No necesita imponerte nada: te lo ofrece como la ruta más fácil, y después de algunos proyectos, el resto de caminos te parecen cuesta arriba.

Compara con Netlify, que no posee ninguna de esas capas y ha luchado por diferenciarse más allá de la conveniencia. Netlify puede ofrecerte un deploy fantástico — y lo hace — pero no puede influir en cómo escribes tu código. Es un anfitrión de decisiones ajenas. Vercel, en cambio, escribe las decisiones.

La diferencia estructural entre Vercel y Netlify no es un CDN. Es un framework.

Y aquí viene la parte incómoda para los arquitectos de la nube: la infraestructura subyacente es commodity. Vercel Functions están documentadas para correr sobre AWS Lambda. La edge network es una capa de routing y caché gestionada por encima.

Esto es importante porque elimina la última excusa para tratar a Vercel como un proveedor de infraestructura. No lo es. Si lo tratas como tal, estás comparando capas equivocadas. La diferenciación no es física. Es developer experience y defaults de caché. Cualquier rival bien financiado — Cloudflare, Fly.io, el propio AWS — puede replicar el rendimiento bruto. Por eso el activo duradero tiene que ser el framework y el workflow que lo rodea.

React Server Components y Server Actions: El Juego Estratégico que Más Importa

Este es el movimiento que más importa.

Server Components y Server Actions mueven el cómputo de vuelta al servidor dentro de un modelo gestionado por el framework. Durante casi una década, la ola dominante fue empujar lógica al cliente: SPAs, hydratación, renderado en el navegador. Next.js y su App Router invierten esa dirección. Ahora el servidor vuelve a ser el lugar natural para los datos, los secretos y la lógica — pero un servidor que nadie ve, porque el framework lo orquesta.

¿Y quién está estructuralmente mejor posicionado para monetizar ese cambio? Exacto: quien controla el runtime de ese servidor gestionado. Vercel cobra por primitivas de renderizado, de caché y de fetching de datos que solo tienen sentido precisas y predecibles dentro de su plataforma.

Pero hay un matiz aún más profundo. Como Next.js es ahora la implementación de referencia de estas APIs de React, Vercel influye en el roadmap de React desde arriba. Cuando el equipo de React diseña una característica nueva, el socio de implementación no es un competidor genérico: es el equipo que mantiene el framework más usado para React. Eso es poder de plataforma que no tiene nada que ver con cuántos servidores corre.

No es conspiración. Es el diseño del negocio. La relación entre Vercel y React (con la propia Meta detrás) es simbiótica: React marca el rumbo conceptual de los componentes, Next.js lo traduce en defaults concretos, y Vercel lo empaqueta en un runtime que los hace rápidos "out of the box". Cada capa refuerza a la anterior.

Para el desarrollador medio, el resultado es cómodo: escribe componentes, el framework decide. Para el arquitecto cuidadoso, debería ser un recordatorio de que estás dentro de un flujo de decisión de terceros — delicioso mientras tus intereses y los de Vercel estén alineados.

El Marco de Portabilidad de 5 Capas

Si despliegas en Vercel — y la mayoría deberíais, porque la abstracción gestionada vale la pena — necesitas una salida. No por desconfianza. Por higiene. Porque el mismo argumento que usamos contra el entrenamiento de modelos de datos propietarios o contra las bases de datos cerradas se aplica aquí: los costes de salida que no has medido nunca se vuelven facturas de migración cuando menos lo esperas.

Este es mi marco prosaico y funcionando en proyectos reales.

Capa 1: Corre el portability drill antes de comprometerte.

Configura output: 'standalone', haz build y arranca el artefacto en un contenedor Node genérico. Si arranca, has demostrado que tienes salida. Si no arranca, has encontrado tus puntos de lock-in antes de que fueran caros.

Si ese Dockerfile arranca fuera de Vercel, has matado la cerradura legal y has empezado a picar la arquitectónica. No digo que el artefacto sea idéntico en rendimiento — no lo será. Pero tienes un camino, y tener camino es tener opciones. Los equipos que descubren que su app no arranca fuera de Vercel en el momento del despliegue forzado pagan el precio en las peores condiciones imaginables: con fechas límite encima, sin presupuesto y bajo presión.

Capa 2: Audita tu dependencia de paquetes y APIs específicas.

Etiqueta cada dependencia como portable o atada a plataforma. Haz el ejercicio explícito, no mental: crea un archivo en tu repo con la lista.

@vercel/functions, @vercel/analytics, edge middleware, el image loader por defecto: todos son puntos de atadura. Saber cuáles usas es el primer paso para no descubrirlo en una migración. La auditoría no tiene que ser exhaustiva desde el día uno — de hecho, es mejor incremental. Etiqueta las deps nuevas conforme las añades, y dedica una sesión al trimestre a revisar las viejas. En unos meses tendrás un mapa honesto de tu exposición.

Capa 3: Mide el delta real de rendimiento en tu workload.

No te creas el marketing de benchmarks. Esa es una de las trampas más caras del ecosistema: las comparativas que publican los vendors están construidas para favorecer a quien las paga. Despliega la misma app Next.js en Vercel y en un contenedor Node genérico detrás de una CDN.

Compara TTFB y cold-start en tu carga real de trabajo. No en una página de marketing. Mide el percentil 50 y el percentil 95, no solo la media, porque para el usuario la cola larga es lo que percibe. Y mide bajo carga, no en una petición solitaria.

El resultado te dirá si estás pagando por rendimiento físico (probablemente no) o por cero-ops, previews y defaults de caché (probablemente sí). Y eso importa: si pagas por conveniencia, tienes que estar seguro de que la conveniencia justifica el coste. Si pagas por rendimiento, tienes que estar seguro de que no hay alternativa más barata.

Capa 4: Aísla el código serverless-específico.

Middleware, rutas de edge, fronteras de streaming — todo eso vive en una capa de transporte. La lógica de negocio se queda en Server Components portables y route handlers que cualquier runtime puede ejecutar.

La capa 1 del artículo anterior ya lo decía: middleware es transporte, nunca negocio. Cuando escribes lógica de autenticación, redirecciones o A/B testing en el middleware de edge, te estás acoplando a una capa que solo existe conceptualmente en entornos serverless. Si esa lógica la mueves a una función normal o a un Server Component, se vuelve agnóstica.

Separar transporte de negocio tiene un beneficio colateral que nadie menciona: testear. La lógica de negocio portable se testea con herramientas genéricas de Node. La lógica de transporte requiere emular el runtime concreto. Mantener la primera limpia hace que tu suite de tests sobreviva a cualquier migración.

Capa 5: Fija versiones de Next.js y sigue el roadmap de React.

Porque las decisiones del framework — no la factura del hosting — son las que ahora mueven tu arquitectura y tu coste futuro de migración. Cada major de Next.js ha traído cambios de API sustanciales: del Pages Router al App Router, de getServerSideProps a Server Components. Si dejas que las versiones floten con rangos ^, estás aceptando sorpresas silenciosas. Si fijas versiones y controlas las actualizaciones como decisiones explícitas, mantienes el control del cuándo y el cómo.

El roadmap de React merece seguimiento atento, no como espectáculo, sino como señal de inversión: las APIs que React estabiliza en un release, Next.js las convierte en defaults en el siguiente. Saber qué viene te permite anticipar costes de migración con seis meses de margen en lugar de descubrirlos en el changelog de un lunes.

El Verdicto que Nadie Quiere Dar

Vercel no es caro. Compararlo con "Nginx + un servidor Node" por coste es comparar una manzana con el huerto entero.

Lo que pagas es la abstracción gestionada: previews con cero operaciones, defaults de caché, optimización de imágenes y fuentes. El argumento real no es que Vercel sea barato. Es que su foso vive en la capa del framework, así que las comparaciones de precio contra cómputo bruto se pierden el producto real.

Si tu app es un CRUD trivial, tienes razón: Vercel es overkill. Comunícate con un VPS y Node, y habrás terminado. Pero aquí está el matiz que la mayoría no ve: si eliges un CRUD trivial, probablemente no necesites Next.js — y si lo necesitas, probablemente tu caso no sea tan trivial. La frontera entre "overkill" y "necesario" se ha movido mucho con el App Router, porque el coste de montar renderizado híbrido, streaming y caché a mano es alto.

Pero la decisión de adoptar Next.js ya es, implícitamente, una apuesta por la arquitectura de Vercel. Los equipos que hacen esa apuesta deberían al menos entender lo que firman. No para arrepentirse, sino para tomar decisiones informadas en cada paso: qué features usar, cuáles evitar, dónde construir adaptadores.

La conclusión es incómoda: el cinco pasos de este marco no es para escapar de Vercel. Es para poseer tu arquitectura aunque te quedes.

Y la mayoría os quedaréis. Con razón. El producto es bueno, la experiencia de desarrollo es la mejor de su categoría, y el coste de migración para la mayoría de apps reales es desproporcionado frente al beneficio. La higiene de portabilidad no es para irse: es para saber qué tienes, valorarlo como decisión propia y no como accidente.

---

Resumen de Puntos Clave

El producto real de Vercel es Next.js; el hosting es casi un canal de distribución.
El lock-in es arquitectónico, no legal. Next.js es MIT-licensed; tu arquitectura no lo es.
Server Components y Server Actions mueven el cómputo al servidor dentro de un modelo que Vercel monetiza.
La infraestructura es commodity (AWS Lambda debajo); el foso es la capa de autoría.
Aplica el Marco de Portabilidad de 5 Capas: portability drill, auditoría de dependencias, medición real, aislamiento de código serverless y versiones pinadas.
La relación Vercel-React es simbiótica: Vercel influye en el roadmap de React desde arriba al ser la implementación de referencia.
La portabilidad no es para irse: es higiene para decidir quedarse con conocimiento.

La próxima batalla del ecosistema web no se librará por cuántos servidores corre cada uno. Se librará por quién escribe los defaults que deciden cómo piensa la próxima generación de desarrolladores.

Y ese campo de batalla ya tiene un dueño.

Vercel no Vende Hosting. Vende el Framework que Decide Cómo Escribe tu App — y te lo Da en Alquiler