Cloudflare Pages vs Workers: cuándo usar cada uno y cómo escalar

En 2022 la respuesta era fácil: si tenías un sitio estático, Pages. Si tenías lógica de servidor, Workers. Pero en 2026 esa frontera se ha difuminado hasta el punto de que elegir mal te puede costar semanas de deuda técnica. Este artículo es la guía que me habría gustado tener antes de empezar a migrar Agentikas.

Qué son realmente Pages y Workers

Cloudflare Workers es el producto original: una plataforma serverless donde subes un script JavaScript y se ejecuta en el edge. Cada request pasa por tu código. Puedes hacer cualquier cosa — renderizar HTML, procesar formularios, llamar a APIs, modificar headers. Es la infraestructura pura.

Cloudflare Pages apareció después como capa opinionada encima. Pages está pensada para aplicaciones frontend: te da Git integration, deploy previews por PR, asset hosting global, y opcionalmente un Worker asociado para la parte dinámica. Si tu sitio es React estático, subes el build y ya está. Si necesitas algo de lógica, Pages inyecta un Worker detrás.

Durante años la distinción fue clara:

• Sitios estáticos → Pages
• APIs y lógica compleja → Workers

Pero con Next.js entrando en escena — un framework que mezcla estático, SSR y edge computing en la misma aplicación — la elección se volvió más sutil.

Lo que comparten

Ambos corren en la misma red edge de Cloudflare (275+ localizaciones). Ambos tienen tier gratuito generoso (100K requests/día en Workers, invocaciones ilimitadas en Pages). Ambos soportan nodejs_compat, fetch API, y las mismas primitivas básicas. Si lo único que te preocupa es "¿puedo correr código en el edge de Cloudflare?", la respuesta es sí en los dos.

La diferencia está en el modelo mental y, crucialmente, en las herramientas que los rodean.

Dónde divergen

Límites de tamaño

• Pages: 25 MB por archivo comprimido, sin límite total.
• Workers (free): 3 MB comprimido, 10 MB sin comprimir.
• Workers (paid, $5/mes): 10 MB comprimido.

Para una app Next.js de tamaño medio esto suele no ser problema — el worker bundle suele rondar el MB. Pero si importas librerías pesadas (el SDK de AWS S3 tiene 3 MB por sí solo, Puppeteer ni te cuento), la diferencia importa.

Modelo de deploy

Pages tiene Git integration nativa. Conectas tu repo a GitHub y cada push despliega automáticamente. Las branches generan preview URLs. Es la experiencia Vercel de Cloudflare.

Workers tradicionalmente se desplegaban con wrangler deploy desde la terminal o CI. No había Git integration oficial, aunque Cloudflare la añadió recientemente en beta. Si quieres push-to-deploy tienes que montar GitHub Actions.

Este detalle operacional mata más proyectos de los que imaginas. Si tu equipo espera deploys automáticos, Pages te ahorra una tarde de setup.

Adapters para Next.js

Aquí está el drama real.

Para Pages: @cloudflare/next-on-pages. Es un wrapper sobre vercel build que convierte el output de Next.js al formato que Pages espera. Funcionó bien durante dos años pero está en modo mantenimiento. No soporta features modernas de Next.js (ISR, Cache Components, streaming sin fricciones) y falla en combinaciones sutiles con monorepos y Turbopack.

Para Workers: @opennextjs/cloudflare. Es el adapter moderno, creado por OpenNext — el proyecto que lanzó el estándar de adapters para Next.js fuera de Vercel. Soporta todas las features modernas, y desde marzo de 2026 es el camino oficial recomendado por el propio equipo de Next.js para desplegar en Cloudflare.

El Next.js 16.2 Adapter API dejó claro que el futuro está en Workers + OpenNext. Cloudflare está desarrollando su propio adapter oficial basado en OpenNext, que saldrá a lo largo de 2026.

Traducido: si empiezas un proyecto nuevo con Next.js en Cloudflare hoy, ve directamente a Workers + OpenNext. Si ya tienes Pages, migrar pronto te ahorra dolor.

Debuggear errores de runtime

Probablemente la mayor diferencia práctica. En Pages, cuando algo falla en el Worker asociado, los logs salen en la consola de Cloudflare Dashboard con cierto delay y metadata limitada. En Workers, wrangler tail te da streaming en tiempo real de cada request, con acceso al request/response completo y stack traces.

Cuando estás debuggeando un 500 misterioso, esta diferencia es la que decide si pasas 10 minutos o 3 horas.

La decisión en 2026

Quédate en Pages si...

• Tu app es mayormente estática (landing, portfolio, blog simple)
• No te importa estar en un adapter sin futuro
• Necesitas Git integration auto-deploy ya mismo
• Estás haciendo algo que ya funciona y no quieres tocar

Muévete a Workers si...

• Usas Next.js 15+ con features modernas (Server Actions, ISR, streaming, Cache Components)
• Tienes o vas a tener un monorepo con packages compartidos
• Necesitas debuggear bien (wrangler tail es oro)
• Quieres estar alineado con el futuro oficial de Next.js en Cloudflare

Los productos no están muertos — Cloudflare sigue dando soporte a Pages y seguirá. Pero el dinero y la atención se están moviendo a Workers.

Escalar Workers: de uno a muchos

Una vez eliges Workers como plataforma, llega el siguiente problema: tu proyecto crece. Lo que empezó como una app Next.js se convierte en tres — una landing, una plataforma, un CMS. Compartes componentes, queries y utilidades entre ellas, y descubres que tienes el mismo código copiado en varios sitios.

La solución es un monorepo. La regla práctica que aplicamos: npm workspaces primero (cero setup, resuelve el 80%), Turborepo el día que duela el build (no antes), Nx solo para equipos grandes. Hay un post separado en este blog profundizando en las tres herramientas si te interesa el detalle.

El futuro inmediato

El trabajo del grupo de Adapters de Next.js va a reescribir el panorama en los próximos meses. Cloudflare está desarrollando su propio adapter oficial basado en OpenNext. Netlify y AWS están haciendo lo mismo. Todos consumirán la misma Adapter API estable de Next.js 16.2.

Lo que eso significa para ti:

• El código que escribas hoy con OpenNext sobrevivirá a esa transición. El adapter oficial de Cloudflare será compatible.
• La feature parity entre plataformas será mucho mayor. Hasta ahora, una feature de Next.js podía tardar meses en llegar a Cloudflare si llegaba. Con la Adapter API, llega igual en todas.
• Los bugs específicos de plataforma se reducirán. Cuando todos los adapters pasan el mismo test suite, los quirks desaparecen.

En resumen: 2026 es el año en que Next.js en Cloudflare se convierte en un producto de primera clase, no en un deploy alternativo con asteriscos.

Qué me llevo

Después de migrar Agentikas de Pages a Workers + OpenNext, tres lecciones:

1. Elige el adapter de futuro, no el que ya conoces. El coste de cambiar después es mayor que el coste de aprender el nuevo ahora.
2. No sobredimensiones la infraestructura. npm workspaces resuelve el 80% del valor. Turborepo es útil cuando duele el build. Nx es para equipos grandes.
3. Documenta los gotchas. Las cosas que te tomaron horas descubrir — compatibility_date, transpilePackages, hoisting — no están en la documentación oficial. Escríbelas tú para el próximo que venga.

Si estás empezando hoy un Next.js en Cloudflare: Workers + OpenNext + npm workspaces. Sin Pages, sin Turborepo todavía, sin Nx. Avanzas rápido y tu código es compatible con el futuro oficial del ecosistema. El día que los builds tarden demasiado, añades Turborepo. Que no es hoy.

---

En Agentikas construimos infraestructura para la web agéntica. Nuestro blog es open source y el código de toda la migración que menciono está en github.com/agentikas/agentikas-blog.