Qué fue Pages: el producto que enseñó a desplegar desde Git

Hoy parece evidente que conectar un repositorio a una plataforma y obtener, en cada push, un sitio compilado y publicado con su propia dirección de previsualización es el mínimo exigible. En 2020 no lo era, y desde luego no lo era en Cloudflare, donde publicar un front-end significaba subir archivos a un bucket, poner una CDN delante y escribir a mano las reglas de caché, de redirección y de cabeceras. Pages nació exactamente ahí, como respuesta a una pregunta incómoda: por qué desplegar un sitio estático en la red más rápida del planeta tenía que ser más engorroso que hacerlo en cualquier otro sitio. La respuesta no fue una capacidad técnica nueva —servir bytes desde el edge ya se sabía hacer, y muy bien— sino una forma de trabajar. Por eso reconstruir qué fue Pages no es arqueología nostálgica: es entender de dónde salió el flujo de despliegue que hoy usas sin pensarlo, y qué ideas de aquel producto sobrevivieron intactas dentro de Workers.

La pregunta que Pages respondió

En la Cloudflare de 2019 había una asimetría rara. La empresa operaba una de las redes de entrega de contenido más grandes del mundo, y sin embargo un desarrollador que quisiera publicar un blog compilado con un generador estático tenía por delante una tarde de fontanería: un origen donde alojar los archivos, una zona DNS apuntando a él, reglas de caché para que los recursos con huella no caducaran nunca y el HTML sí, y un script de integración continua que subiera todo eso en el orden correcto.

Ese trabajo no era difícil, y precisamente por eso resultaba tan irritante: era repetitivo, se hacía igual en todos los proyectos y no aportaba nada distintivo a ninguno. Cada equipo escribía su propia versión de la misma fontanería, la escribía un poco peor que el anterior, y la mantenía hasta que alguien se iba de la empresa y nadie recordaba por qué una regla de caché concreta estaba puesta.

El diagnóstico fue que el problema no era de infraestructura sino de interfaz. Todos los ingredientes existían; lo que faltaba era un producto que los ensamblara con una sola decisión del usuario: aquí está mi repositorio, aquí el comando que lo compila, aquí la carpeta donde queda el resultado. Pages fue ese ensamblaje, y su acierto consistió en reducir la superficie de configuración a esas tres respuestas.

Anatomía de un proyecto

Las cuatro tarjetas anteriores describen el producto entero. Que quepa en cuatro ideas no es una simplificación de esta lección: era literalmente toda la superficie conceptual que había que aprender, y esa economía explica su adopción mejor que cualquier detalle técnico.

Un proyecto de Pages se describía con muy poco. La configuración esencial vivía en el panel o, más tarde, en un manifiesto de Wrangler, y se reducía a la rama de producción, el comando de compilación y el directorio de salida. La pieza que conviene retener es pages_build_output_dir, porque es el antepasado directo del bloque assets que hoy usas en Workers.

{
  "name": "mi-sitio",
  "pages_build_output_dir": "./dist",
  "compatibility_date": "2025-06-05"
}

Junto al resultado de la compilación viajaban dos archivos de texto plano que Pages interpretaba al servir. Eran deliberadamente tontos, sin lógica ni ramificación, y esa simplicidad fue parte de su éxito: cualquiera podía leerlos y predecir su efecto sin ejecutar nada.

# _redirects
/blog/*  /articulos/:splat  301
/antiguo /nuevo             302

# _headers
/assets/*
  Cache-Control: public, max-age=31536000, immutable

La tabla anterior contiene una enseñanza que va más allá de la migración. Tres de las cuatro piezas sobrevivieron sin cambios de semántica, y solo la cuarta, el código en servidor, cambió de forma. Eso no es casualidad: las tres primeras describen datos de configuración declarativos, y los datos declarativos envejecen mucho mejor que las convenciones de ejecución. Cuando diseñes algo pensando en que dure, esa es la línea que conviene tener presente sobre dónde poner cada cosa.

Para quien no quería integración con Git existía la subida directa, que empujaba una carpeta ya compilada desde cualquier sistema de integración continua. Ese comando sigue existiendo, y verlo en un package.json es una de las señales más fiables de que estás ante un proyecto heredado.

npx wrangler pages deploy ./dist --project-name mi-sitio

El ciclo de vida de un despliegue

La idea más valiosa de Pages, y la que más se ha copiado, es que un despliegue es inmutable. Compilar produce un artefacto que recibe un identificador propio y una dirección permanente derivada del commit; ese artefacto no se modifica jamás. Lo que llamamos publicar no es escribir encima de nada, sino mover un puntero: el dominio de producción pasa a resolver hacia otro artefacto ya existente.

flowchart LR
PUSH[push a una rama] --> BUILD[compilacion en la nube]
BUILD --> ART[artefacto inmutable con hash]
ART --> PREV[url por commit]
ART --> ALIAS[alias estable de la rama]
ALIAS -->|merge a main| PROD[dominio de produccion]
PROD -.rollback.-> ART
style ART fill:#89b4fa,color:#11111b
style PROD fill:#a6e3a1,color:#11111b

Merece la pena insistir en lo poco obvio que era esto en su momento. La práctica habitual consistía en sincronizar archivos contra un origen, es decir, escribir encima de lo que había; con ese modelo, un despliegue interrumpido a la mitad deja el sitio en un estado que no corresponde a ninguna versión del repositorio, y volver atrás significa volver a desplegar y rezar. Tratar el despliegue como un valor inmutable en lugar de como una mutación elimina esa clase entera de estados imposibles.

De esa inmutabilidad se derivan tres consecuencias que hoy damos por sentadas. La primera es que revertir es instantáneo y no puede fallar: no recompilas, reapuntas. La segunda es que la previsualización de una rama es un entorno real y no una aproximación, porque se sirvió con el mismo motor que servirá producción. La tercera, la más sutil, es que el historial de despliegues se convierte en un registro auditable de qué bytes exactos estuvieron en línea y cuándo, algo que la fontanería artesanal casi nunca ofrecía.

La compilación en sí ocurría en un entorno gestionado que Pages levantaba por ti, y ese detalle explica buena parte de su comodidad y también de sus quejas más frecuentes. Tú declarabas el comando y la versión del tiempo de ejecución mediante una variable, y la plataforma se encargaba del contenedor, la caché de dependencias y los registros. A cambio, cuando algo fallaba solo en la nube y no en tu máquina, la depuración consistía en leer un registro ajeno y probar a ciegas, porque el entorno no era reproducible en local. Es el intercambio clásico de toda integración continua gestionada: menos configuración a cambio de menos control.

NODE_VERSION = 20
comando de compilacion = npm run build
directorio de salida = dist

Las variables de ese entorno se declaraban por separado para producción y para previsualización, lo que permitía que una rama de trabajo apuntase a una base de datos de pruebas mientras la principal apuntaba a la real. Esa separación por entorno es el antepasado directo de lo que hoy resuelven los entornos de Wrangler, y conviene tenerla presente al migrar porque es una de las piezas que se olvidan con más facilidad: el sitio compila, se despliega, y solo días después alguien descubre que la previsualización estaba escribiendo en producción.

Sobre esa base, Pages distinguía dos clases de despliegue. El de producción salía de la rama designada y respondía en el dominio propio. El de previsualización salía de cualquier otra rama, respondía en un subdominio de pages.dev y podía además tener un alias estable por nombre de rama, de forma que la dirección de una rama de trabajo no cambiaba en cada commit y podía pegarse en una tarjeta de tablero sin quedar obsoleta al día siguiente.

Lo que Pages normalizó

La distinción entre ambas clases de despliegue tenía además una consecuencia de seguridad que hoy sigue vigente en Workers y que conviene no olvidar: una dirección de previsualización es pública. No lleva contraseña por defecto, es indexable si alguien la enlaza, y sirve una versión del sitio que puede contener funcionalidad a medias o datos de prueba. Proteger esas direcciones con una capa de acceso era, y sigue siendo, parte de la higiene mínima de cualquier proyecto que use previsualizaciones para revisar trabajo interno.

Conviene separar dos cosas que suelen confundirse. Pages, el producto, entró en mantenimiento. El flujo que Pages popularizó dentro de Cloudflare no solo sobrevive: es hoy el comportamiento por defecto de Workers, hasta el punto de que un desarrollador que empiece en 2026 lo tomará por una propiedad natural de la plataforma y no por una decisión que alguien tuvo que tomar.

De aquel producto quedaron incorporadas cuatro convenciones: que el repositorio es la fuente de verdad del despliegue, que cada cambio merece una dirección propia antes de fusionarse, que servir bytes estáticos no debe generar factura de cómputo y que volver atrás tiene que ser una operación de un clic. Ninguna de las cuatro es técnicamente difícil por separado; el mérito fue empaquetarlas juntas y hacerlas irrenunciables.

La cuarta convención, la gratuidad del estático, merece una mención aparte porque es la que decidió el desenlace del nivel entero. Mientras servir un archivo desde un Worker contase como invocación facturable, ningún equipo con tráfico serio iba a mover su sitio, por muchas capacidades que ganase al hacerlo; la aritmética se lo impedía. El día en que las peticiones resueltas con un asset dejaron de contar, esa barrera cayó, y con ella cayó la única razón sólida para mantener dos productos. La historia de Pages, vista desde 2026, es la de un producto que estableció una expectativa económica tan firme que su sucesor tuvo que igualarla antes de poder reemplazarlo.

Queda una lectura final que conviene no perder. Aprender cómo funcionaba Pages no sirve solo para mantener proyectos viejos: sirve para reconocer las mismas piezas cuando aparecen con otro nombre. El directorio de salida, la rama de producción, el artefacto inmutable, el alias estable y la separación de variables por entorno son conceptos que ninguna plataforma ha inventado ni va a jubilar. Cambian de sintaxis; no cambian de significado.