Qué cambió: Workers absorbe las capacidades de Pages

Durante años la plataforma de Cloudflare tuvo una costura visible. A un lado, Pages: la forma cómoda de publicar un front-end, con integración con Git, despliegue en cada push y previsualizaciones por rama. Al otro, Workers: la plataforma de cómputo completa, con todos los bindings, cron, estado durable y comunicación entre servicios. Cada proyecto empezaba con una decisión que no debería haber existido nunca, porque los dos lados acababan necesitándose. En marzo de 2026 esa costura se cerró: Workers alcanzó la paridad total con Pages en assets estáticos, renderizado en servidor y dominios, y las peticiones de assets pasaron a ser gratis en ambos. Este nivel entero trata de esa convergencia; esta primera lección explica exactamente qué se movió y por qué el resultado no es un producto más grande, sino un modelo más simple.

Por qué hubo dos productos

Antes de contar qué se movió, conviene entender por qué había algo que mover. Las convergencias de plataforma se leen mal cuando se cuentan como correcciones de un error pasado, y esta no lo fue.

La existencia de dos productos no fue un error de diseño: fue el resultado honesto de dos necesidades que, cuando aparecieron, no se sabían resolver con la misma herramienta. Workers nació como cómputo en el edge, y su unidad mental era la función que responde a una petición. Servir cuatro mil archivos de un build de front-end desde esa unidad era posible pero incómodo, y sobre todo caro conceptualmente: cada imagen, cada hoja de estilo, cada fragmento de JavaScript pasaba por la maquinaria pensada para ejecutar lógica.

Conviene recordar de dónde venía esa incomodidad, porque explica por qué la solución tardó. Un Worker se factura por invocación, y una página moderna dispara decenas de peticiones por visita entre estilos, fuentes, imágenes y fragmentos de código. Servir todo eso a través de la unidad de cómputo significaba pagar por entregar bytes que no requerían ningún cálculo, y ninguna cantidad de azúcar sintáctico podía arreglar ese desajuste de fondo: el problema no era la ergonomía, era el modelo de precios.

Pages nació para tapar exactamente ese hueco. Traía lo que un equipo de front-end espera: conectas un repositorio, cada push produce un despliegue, cada rama tiene su URL, y el hosting estático es gratuito e ilimitado. A cambio, su acceso a la plataforma era de segunda clase. Los bindings llegaron tarde y parciales, no había cron nativo, y el modelo de funciones basado en el directorio functions/ se sentía como una capa añadida sobre lo que en el fondo era un CDN con buena ergonomía de despliegue.

El problema no era que ninguno de los dos fuera bueno. Era que el proyecto medio necesitaba las dos mitades. Un sitio con un formulario que escribe en una base de datos, un blog con una ruta de búsqueda, una tienda con un webhook de pagos: en todos ellos el front-end vivía cómodo en Pages y la lógica quería vivir en Workers. La costura entre productos se convertía en una costura dentro de la arquitectura.

Y esa costura no era gratuita. Un equipo que elegía las dos mitades acababa manteniendo dos proyectos con dos configuraciones, dos historiales de despliegue que había que sincronizar a mano, y una llamada de red entre piezas que conceptualmente eran la misma aplicación. La alternativa, quedarse en un solo lado, significaba renunciar a algo: o a la comodidad del front-end, o al acceso completo a la plataforma. Ninguna de las dos renuncias tenía una justificación técnica; ambas eran el peaje de una frontera de producto.

flowchart TD
N[Un proyecto real full stack] --> D{Donde lo despliego}
D -->|Pages| P[Assets gratis y previews pero plataforma limitada]
D -->|Workers| W[Plataforma completa pero estaticos incomodos]
P --> C[Costura entre dos proyectos]
W --> C
C --> U[Convergencia de 2026 en un solo Worker]
style C fill:#f38ba8,color:#11111b
style U fill:#a6e3a1,color:#11111b

Qué se movió exactamente

La convergencia no fue una función suelta, sino el cierre deliberado de todas las razones por las que alguien seguía eligiendo Pages. Conviene enumerarlas, porque cada una era un motivo real y ninguna se resolvió con un rodeo. El criterio para considerar cerrada una razón no fue que existiera algún mecanismo equivalente, sino que ese mecanismo costase lo mismo y se comportase igual bajo carga real; sin ese listón, la lista habría estado completa años antes y nadie habría migrado nada.

La pieza que hizo que la paridad fuera real y no meramente técnica es la económica. Nadie habría movido un sitio de tráfico alto a un modelo que cobrase por cada imagen servida, por muy elegante que fuera el manifiesto. Al no contar como invocación las peticiones que resuelve un asset, Workers iguala exactamente la economía de Pages para la parte estática y reserva el coste para el cómputo que de verdad aporta valor. Pages y Workers comparten además el mismo plan de pago, de modo que la migración tampoco cambia la factura base.

Hay un cuarto elemento que se anuncia menos y se nota mucho: el eje de las previsualizaciones cambia de sitio. En Pages, la URL de previsualización colgaba de la rama del repositorio, lo que ataba el ciclo de revisión a una convención de Git. En Workers cuelga de la versión desplegada, que es una unidad más precisa porque coincide exactamente con lo que se publica. La diferencia parece cosmética hasta que la usas: subir una versión y promoverla a producción pasan a ser dos actos separados, y eso convierte el despliegue en una decisión reversible en lugar de un salto.

Falta señalar la dirección de la absorción, que es lo que da nombre a este nivel. Workers no adoptó el modelo de Pages ni se convirtió en un producto de hosting con funciones añadidas. Ocurrió lo contrario: mantuvo su propio modelo mental —un punto de entrada, un objeto env, un manifiesto— y encajó dentro de él las capacidades que faltaban, hasta que servir archivos dejó de ser un producto separado para ser un bloque de configuración. Esa asimetría importa, porque significa que lo que aprendiste sobre Workers sigue siendo válido y solo se amplía, mientras que lo que sabías de Pages se traduce.

Un solo modelo

El efecto práctico se ve mejor en el manifiesto que en la documentación. Lo que antes exigía dos proyectos, dos configuraciones y pegamento entre ellos cabe ahora en un archivo que describe la aplicación entera:

{
  "name": "mi-app",
  "main": "src/index.ts",
  "compatibility_date": "2026-03-01",
  "assets": {
    "directory": "./dist",
    "binding": "ASSETS",
    "not_found_handling": "single-page-application"
  },
  "d1_databases": [
    { "binding": "DB", "database_name": "app", "database_id": "..." }
  ],
  "triggers": { "crons": ["0 3 * * *"] }
}

Ese archivo declara un front-end estático servido gratis, un punto de entrada de código que atiende la API y el renderizado en servidor, una base de datos accesible desde ese código, y una tarea programada que corre de madrugada. Es una sola unidad: se versiona junta, se despliega junta y comparte el mismo env. La aplicación full-stack deja de ser un ensamblaje de servicios con un contrato de red entre ellos para convertirse en un artefacto único.

El código que acompaña a ese manifiesto es igual de escueto, y muestra la propiedad más importante del modelo: el mismo handler que responde la API tiene delante los assets sirviéndose solos. Cuando llega una petición, el edge intenta primero encontrar un archivo que la resuelva; si lo encuentra, lo entrega y tu código ni se entera, lo que mantiene esa petición gratuita. Solo cuando no hay archivo cae en tu handler. Ese orden por defecto es el que permite que front-end y API convivan sin que tengas que enrutar los estáticos a mano.

export default {
  async fetch(request, env) {
    const url = new URL(request.url);
    if (url.pathname.startsWith("/api/")) {
      const { results } = await env.DB.prepare("SELECT * FROM notas").all();
      return Response.json(results);
    }
    return env.ASSETS.fetch(request);
  },
};

El comando también se unifica. Donde había dos verbos de despliegue distintos, ahora hay uno:

npm run build
npx wrangler deploy

Y con el mismo manifiesto puedes trabajar en local con los bindings simulados, algo que en el mundo de dos productos exigía arrancar dos procesos y hacer que se hablaran entre ellos:

npx wrangler dev

Qué implica para tus proyectos

La convergencia divide a los proyectos en tres grupos con urgencias muy distintas, y confundirlos es el error más común al leer un anuncio de este tipo. Una noticia de plataforma nunca significa lo mismo para quien empieza que para quien mantiene, y tratar ambos casos con la misma prisa produce migraciones innecesarias o retrasos caros, según hacia qué lado se equivoque uno.

Para lo que empieza hoy, la decisión desaparece: no queda ningún argumento a favor de arrancar en Pages, porque no hay ahorro, no hay comodidad exclusiva y sí hay un techo garantizado el día que necesites algo que solo existe en Workers. La lección de cierre de este nivel desarrolla el patrón concreto con el que conviene nacer.

Para lo que ya existe, la urgencia es baja y la dirección es clara. Nada se rompe, no hay apagado inminente y tu sitio seguirá sirviéndose igual mañana. Lo que sí ocurre es que cada mes que pasa aumenta la distancia entre lo que tu proyecto puede hacer y lo que la plataforma ofrece, y esa distancia se paga entera el día que la necesites con prisa. Por eso conviene tratar la migración como mantenimiento planificado y no como una emergencia futura: se hace en un momento tranquilo, con las dos superficies vivas, y se revierte con un cambio de DNS si algo no cuadra.

Conviene además ordenar los proyectos existentes por dificultad real, porque la intuición engaña. Un sitio puramente estático se migra en minutos: se declara el bloque assets, se despliega y se mueve el dominio. Un sitio con archivos _headers y _redirects añade un rato de traducción, pero sigue siendo trabajo de configuración. La dificultad aparece solo cuando hay un directorio functions/ con lógica propia, porque ahí hay que reescribir el enrutado, y crece con el número de rutas, no con el tamaño del sitio. Medir esa cifra antes de planificar convierte una estimación vaga en una razonable.

Hay además un tercer grupo que se olvida: los proyectos que hoy están partidos en un Pages más un Worker conectados por una llamada de red. Son los que más ganan y los que menos trabajo tienen, porque la migración consiste sobre todo en fusionar dos manifiestos en uno y borrar el pegamento que los unía.