Por qué combinamos Cloudflare y Vercel en vez de elegir uno solo

Cloudflare protege y acelera una parte enorme de todo el tráfico de internet a nivel global, y Vercel se convirtió en el estándar de facto para desplegar aplicaciones construidas con Next.js. Son dos plataformas que, por separado, ya son gigantes en su categoría — y cuando un proyecto necesita tanto la velocidad de una red de borde como la lógica de servidor de una aplicación real, la pregunta ya no es cuál elegir, sino cómo combinarlas bien.

Los números respaldan esa escala: según el reporte de tecnologías web de W3Techs, Cloudflare sirve alrededor del 23% de todos los sitios web del mundo, y su red maneja cerca del 20% de todo el tráfico de solicitudes de internet a nivel global. Del lado de Vercel, más de 2 millones de sitios corren directamente sobre su plataforma, mientras que Next.js —el framework que la propia Vercel creó y mantiene— supera 1 millón de desarrolladores activos mensuales, con miles de empresas verificadas usándolo en producción, desde startups hasta compañías como Amazon o IBM.

Lo que Cloudflare hace mejor que casi nadie

Cloudflare dejó de ser “solo” una red de protección contra ataques hace tiempo. Hoy es una plataforma completa para correr aplicaciones en el borde de su red —lo que se conoce como edge computing— con presencia en más de 300 ciudades del mundo. Eso significa que el código no corre en un solo servidor lejano, sino literalmente en el punto más cercano a quien está visitando el sitio.

Para sitios estáticos o semi-estáticos —como el que construimos con Astro para nuestra propia web— esto se traduce en tiempos de carga consistentemente rápidos sin importar desde qué país entre alguien, y sin que nosotros tengamos que administrar ningún servidor. El despliegue es automático: cada vez que subimos un cambio a nuestro repositorio, Cloudflare lo publica solo, en segundos.

No es casualidad que la relación entre ambas tecnologías sea tan directa: en enero de 2026, Cloudflare adquirió al equipo detrás de Astro, el framework que ya usábamos para construir nuestro propio sitio. Astro sigue siendo open source, pero ahora tiene el respaldo directo de la misma infraestructura donde lo desplegamos, lo que en la práctica significa menos fricción entre el framework y la plataforma que lo aloja.

Lo que más valoramos en la práctica es el modelo de costos: el ancho de banda no tiene el mismo tipo de límite agresivo que sí existe en otras plataformas de hosting moderno. Cuando un sitio empieza a recibir tráfico real, esa diferencia se nota directamente en la factura.

Más allá del hosting estático, Cloudflare también ofrece piezas de infraestructura que antes solo existían por separado: bases de datos serverless, almacenamiento de archivos compatible con los estándares del mercado, colas de trabajo, y modelos de inteligencia artificial corriendo directamente en su red (Workers AI). Es justamente esa última pieza la que estamos evaluando ahora para automatizar parte del análisis de contenido de nuestro sistema interno — tener el modelo corriendo lo más cerca posible del dato, en vez de hacer viajar la información hasta un proveedor externo.

Para explorar esta parte de Cloudflare con criterio, en vez de ir a ciegas, usamos internamente una guía especializada que prioriza siempre la documentación oficial y actualizada de Cloudflare sobre el conocimiento genérico que cualquier asistente de IA ya trae por defecto — algo importante en una plataforma que agrega funciones nuevas todo el tiempo, donde una respuesta desactualizada puede llevar a decisiones de arquitectura equivocadas.

npx skills add https://github.com/cloudflare/skills --skill cloudflare

Dónde entra Vercel

Cloudflare es excelente para lo que es fundamentalmente estático o de borde. Pero cuando un proyecto necesita lógica de servidor más compleja —autenticación de usuarios con sesiones reales, tareas programadas que corren todos los días, o una aplicación que necesita renderizar contenido distinto según quién la esté viendo— Vercel sigue siendo, en nuestra experiencia, el complemento más natural. La relación aquí es la misma que con Cloudflare y Astro, solo que con un origen distinto: Next.js no fue adquirido por Vercel, Vercel es la empresa que creó y sigue manteniendo Next.js desde el inicio, así que la plataforma y el framework nunca están desalineados entre sí.

Ahí está la diferencia práctica que guía cuándo usar cada uno: si lo que se necesita es servir contenido lo más rápido posible en todo el mundo sin mucha lógica de por medio, Cloudflare gana. Si lo que se necesita es una aplicación con estado, con tareas automáticas corriendo en segundo plano y una base de datos relacional detrás, Vercel —combinado con un proveedor de base de datos como Supabase— resuelve ese escenario con menos fricción.

No es una competencia entre las dos. Es un mapa de responsabilidades: nuestro sitio público vive en Cloudflare porque es velocidad pura orientada a quien nos visita, y nuestro panel interno de gestión y análisis de datos vive en Vercel porque necesita sesiones de usuario reales, tareas programadas diarias, y una base de datos que otras herramientas externas también consultan.

npx skills add https://github.com/vercel/vercel --skill vercel-cli

Cuál usar y para qué

Con todo esto ya explicado, la comparación directa ayuda a decidir rápido: si la necesidad es servir contenido rápido en todo el mundo, Cloudflare gana; si la necesidad es lógica de servidor con estado, Vercel gana. Así se ve lado a lado.

La lección real

Ninguna plataforma resuelve todos los problemas igual de bien, y perseguir “una sola tecnología para todo” suele terminar en compromisos que no benefician a nadie. Lo que sí notamos, después de aplicar este mismo patrón en más de un proyecto, es que la combinación correcta depende de separar bien qué parte del sistema es contenido y qué parte es lógica de negocio — una vez que esa línea está clara, elegir dónde vive cada pieza deja de ser una discusión técnica interminable y se vuelve una decisión bastante evidente. Es el mismo criterio que usamos para decidir cuándo un sitio ya acumuló demasiada deuda técnica para seguir parchando: la pregunta nunca es “qué tecnología es mejor en general”, sino “qué necesita resolver esta parte específica del sistema”.

Tener la arquitectura correcta desde el día uno deja de ser un detalle técnico y se convierte en una ventaja competitiva medible, sobre todo a medida que un proyecto crece y empieza a depender de datos, sesiones de usuario y contenido al mismo tiempo.