El panorama 2026

Con la historia y los fundamentos claros, toca hacer la foto del presente. En 2026 la plataforma de Cloudflare ya no es una colección de productos sueltos alrededor de una CDN: es un plano único donde compute, almacenamiento e IA comparten runtime, despliegue y facturación. Y hay un movimiento estratégico que conviene entender desde el primer día, porque decide dónde inviertes tu tiempo: Workers se ha convertido en el centro de todo, y Pages ha pasado a modo mantenimiento.

Un solo plano, tres capas

La foto de 2026 es la de una aplicación full-stack que cabe entera en el edge. No hay que pegar servicios de proveedores distintos con credenciales y colas de red entre ellos: las tres capas viven en la misma red, se hablan por bindings y se despliegan juntas.

Lo importante no es la lista de productos, sino que comparten sustrato. Un Worker consulta D1, guarda en R2 y llama a un modelo de Workers AI sin salir de la red y sin gestionar credenciales entre servicios: todo es un binding en el mismo objeto env. Concretamente, compartir sustrato significa varias cosas que en otras nubes exigirían pegamento y configuración manual:

• Un despliegue, no uno por servicio: wrangler deploy publica compute, rutas y accesos a datos de una sola vez.
• Una factura, no la suma de proveedores con precios y unidades distintas que reconciliar.
• Un modelo de acceso uniforme: bindings en env, sin cadenas de conexión ni claves sueltas por ahí.
• Un entorno local con wrangler dev, que emula datos, colas e IA en tu máquina, no solo el compute.

Así se ve una aplicación entera declarada en un solo manifiesto wrangler.jsonc, donde cada capa es un binding:

{
  "name": "mi-app",
  "main": "src/index.js",
  "compatibility_date": "2026-01-01",
  "assets": { "directory": "./public" },
  "kv_namespaces": [{ "binding": "CACHE", "id": "..." }],
  "r2_buckets": [{ "binding": "MEDIA", "bucket_name": "media" }],
  "d1_databases": [{ "binding": "DB", "database_name": "app" }],
  "ai": { "binding": "AI" }
}

Un vistazo a ese archivo cuenta toda la historia: compute con main, frontend con assets, tres formas de datos con kv, r2 y d1, e IA con ai, todo en el mismo lugar y todo accesible desde env.

Workers, el centro de gravedad

Si tuvieras que aprender una sola cosa de toda la plataforma, sería Workers. Todo lo demás se conecta a él: el almacenamiento se consulta desde un Worker, la IA se invoca desde un Worker, las webs se sirven desde un Worker. No es un producto más entre otros; es el punto por el que pasa todo lo demás.

flowchart TB
W[Workers en el centro] --> S[Almacenamiento KV R2 D1 DO]
W --> AI[IA Workers AI y Vectorize]
W --> A[Static Assets y SSR]
W --> Q[Colas y Workflows]
P[Pages en mantenimiento] -.migra a.-> W
style W fill:#fab387,color:#11111b
style P fill:#45475a,color:#cdd6f4

# El mismo CLI para todo: crear, desarrollar en local y desplegar.
# Workers es la puerta de entrada a compute, datos e IA.
wrangler init mi-app
wrangler dev
wrangler deploy

La consecuencia práctica para ti es enorme: no tienes que aprender diez productos independientes con diez formas de autenticarse y desplegarse, sino un centro y un patrón que se repite. Domina el ciclo de un Worker —recibir una Request, hablar con sus bindings, devolver una Response— y todo lo demás son capas que se enchufan a ese ciclo.

Pages entra en mantenimiento

Durante años hubo dos formas de desplegar en Cloudflare, y elegir entre ellas era una fuente constante de confusión:

En 2026 esa dualidad se resuelve. Workers alcanzó paridad total con Pages: sirve assets estáticos, hace SSR, gestiona dominios y ofrece las integraciones que antes eran exclusivas de Pages. La paridad no es una promesa vaga; se concreta en capacidades que antes obligaban a elegir:

• Assets estáticos servidos directamente por el Worker, con caché en el edge.
• SSR y frameworks como Astro, Next o Remix, desplegados como un Worker más.
• Dominios y rutas personalizados sin pasar por un producto aparte.
• Integración con Git y previews por rama, el flujo que era la joya de Pages.

Con esa paridad completa, Cloudflare ha puesto Pages en modo mantenimiento: sigue funcionando y no desaparece de golpe, pero las novedades llegan a Workers, y los proyectos nuevos deben empezar ahí.

Por qué esta consolidación importa

Para quien ya tiene un proyecto en Pages, la transición está guiada: la mayoría de los sitios migran cambiando el flujo de despliegue y declarando sus assets, sin reescribir la aplicación. Y para quien empieza de cero, la decisión es trivial: un solo camino, sin bifurcación que sopesar. Has cerrado el nivel de fundamentos: sabes qué es el edge, de dónde viene, por qué la cercanía importa y en qué se diferencia de la nube regional. A partir de aquí dejamos la teoría y empezamos a escribir Workers de verdad.

El resto del track se organiza justo alrededor de ese centro: