Cómo publicar una página en Cloudflare Workers

La carpeta con la página terminada ya existe; el enlace, todavía no. Vamos a publicarla en Cloudflare Workers y a encargarle el procedimiento a Claude Code: crearemos un skill con el que publicar y actualizar se reduce a una petición corta.

1. Qué es Cloudflare Workers para contenido estático

La palabra Workers suena a "programas que se ejecutan en un servidor", y es cierto. Pero no del todo: a un Worker se le puede adjuntar una carpeta de archivos, y entonces el servidor simplemente los sirve, como un hosting normal. No se escribe ni una línea de código.

Para una página hecha de HTML, CSS e imágenes, este modo basta. En la documentación esa carpeta se llama static assets, recursos estáticos, y en la configuración del proyecto ocupa exactamente un campo, el de la ruta.

Cloudflare sirve los archivos a través de su red de servidores y los guarda en caché más cerca de los visitantes.

2. Cuánto cuesta

Las peticiones a archivos estáticos son gratuitas y no tienen límite de cantidad. Es una condición del plan, no una promesa de que nadie cuente las visitas.

Entonces, ¿de dónde sale esa cifra tan conocida, 100 000 peticiones al día? Es el límite de llamadas a un Worker script, justo ese programa en el servidor. Una página que solo lleva una carpeta adjunta no tiene script, así que no entra en ese contador.

El camino de arriba en el esquema es el de nuestra página: el archivo se sirve sin llamar a ningún programa en el servidor. El de abajo hará falta si más adelante añade un Worker script.

El plan gratuito sí tiene límites, pero van por otro lado, por el tamaño de lo que usted publica:

Para una página con una docena de imágenes, estos límites suelen bastar. Antes de un proyecto grande, revise las condiciones actuales de Cloudflare: los límites pueden cambiar. Por cierto, 25 MB por archivo parecen generosos justo hasta el primer video.

3. La cuenta

El registro en cloudflare.com es el de siempre: email y contraseña, y después un correo de confirmación. Para el plan gratuito no hace falta tarjeta. Tampoco hace falta añadir un dominio propio: el servicio se lo ofrecerá, pero esa oferta pertenece a la otra mitad del producto, la que protege y acelera sitios que ya existen.

Después de entrar, la sección que necesita se llama "Workers & Pages", y no está a la vista: en el menú de la izquierda primero va el grupo Build, dentro Compute, y ya ahí dentro, "Workers & Pages". El panel se reorganiza de vez en cuando, así que si la sección no aparece por ese camino, búsquela por el nombre: la búsqueda de arriba a la izquierda se abre con Ctrl + K. Las dos palabras del nombre son dos productos de Cloudflare; usted necesita la primera mitad, Workers, y llegará ahí por su cuenta, sin elegir nada en especial.

Hay algo más que aparecerá en el primer deploy: Cloudflare le pedirá elegir un nombre de subdominio para la cuenta. Todos sus proyectos vivirán en él, y la dirección se compone de dos partes, el nombre del proyecto más su subdominio:

my-landing.example-account.workers.dev
|          |               |
|          |               dominio común de Cloudflare
|          subdominio de su cuenta
nombre del proyecto

ese nombre cuesta cambiarlo después, así que mejor no escribir lo primero que se le ocurra.

4. El primer deploy

Primero veamos brevemente cómo se ve la publicación en el panel. Es un primer contacto opcional con el servicio: si prefiere configurar ya el deploy con el agente y mantener una sola dirección, pase directamente a la preparación más abajo.

landing/          <- esta es la carpeta que entregamos
  index.html      <- página principal, el nombre es obligatorio
  wrangler.jsonc  <- el agente lo creará antes del primer deploy
  style.css
  img/
    hero.png

Antes de publicar, revise el contenido de la carpeta elegida: sus archivos se volverán públicos. Quite de ella los archivos personales y los borradores que no pensaba mostrar.

A mano desde el panel

En la sección de proyectos hay un botón que crea un proyecto nuevo. Después le pedirán que entregue los archivos: puede elegir un solo archivo o la carpeta entera. Los sube, confirma, y Cloudflare los coloca en sus servidores y le devuelve un enlace. Los nombres de los botones y el orden de las pantallas cambian aquí más a menudo de lo que salen artículos, así que guíese por el sentido y no por las etiquetas: crear un proyecto, entregar los archivos, obtener una dirección.

Abra la dirección obtenida, https://…workers.dev, y revise la página y las imágenes. Puede hacerlo desde la misma computadora. El teléfono sirve para una comprobación extra de que la página es accesible y de cómo se ve su versión móvil.

Al publicar desde el panel no aparece ninguna configuración local. El skill de nuestro ejemplo no vincula por su cuenta la carpeta con un proyecto así: sin configuración, creará un nombre nuevo y una segunda dirección. Cloudflare permite actualizar un Worker existente mediante Wrangler, pero para eso hay que preparar aparte una configuración con su nombre.

Qué hace falta para que lo haga el agente

Para las próximas publicaciones configuraremos un skill. La preparación se hace una sola vez en su computadora.

No hacen falta muchos programas. La cuenta ya la tiene; además necesita Node.js, que se comprueba con el comando node -v, y si no lo encuentra, primero tendrá que instalarlo. El propio wrangler no hay que instalarlo: npx descargará la versión más reciente por su cuenta cuando llegue el momento.

El segundo paso del esquema es el inicio de sesión, y conviene resolverlo ahora mismo, antes que todo lo demás:

npx wrangler login    # se abrirá el navegador, con un botón de confirmación

El comando se ejecuta en la terminal. Si falta este paso, todo el procedimiento se atascará en él en la primera ejecución, y parecerá que el skill está roto, aunque el problema no tiene nada que ver con él. Para comprobar que todo salió bien, use el comando npx wrangler whoami: le mostrará con qué cuenta ha iniciado sesión.

Para este camino basta con iniciar sesión desde el navegador. El token de API se explica en la continuación opcional del final.

El tercer paso del esquema, npx wrangler deploy, lo ejecutará el agente desde la carpeta de la página. Antes le daremos las reglas para preparar la configuración y publicar.

5. Un skill propio para el deploy

Mientras haya una sola página, basta con pedirlo en el chat. Pero en cuanto aparezca una segunda, una tercera, una décima, habrá que explicarle al agente lo mismo cada vez: qué carpeta tomamos, cómo llamar al proyecto, qué hacer con el archivo de configuración. A la tercera vez, cansa.

Qué tiene que saber hacer el skill

Cinco pasos, y cada uno resuelve un problema concreto, no está ahí por completar la lista:

1. Tomar la carpeta indicada y asegurarse de que index.html está en su raíz. Una comprobación barata que detecta el error más frecuente antes del deploy, no después.
2. Determinar el nombre del proyecto: sacarlo del nombre de la carpeta en lugar de preguntarlo cada vez.
3. Mirar si dentro de la carpeta, junto a index.html, hay un archivo wrangler.jsonc. Si no lo hay, crearlo; si lo hay, tomar de ahí el nombre y no reescribir nada en él.
4. Lanzar el deploy desde esa carpeta y mostrar el comando antes de ejecutarlo.
5. Devolver la dirección pública y recordar que hay que revisar en ella la página y las imágenes.

El nombre del proyecto sale de la carpeta

Es la decisión principal de todo el procedimiento, y justo esa no se puede dejar a la improvisación del agente. Si ninguna regla fija el nombre, el agente se lo inventará, y la próxima vez inventará otro. Resultado: un segundo proyecto con otra dirección, y el primero ahí colgado.

La regla es sencilla: el nombre de la carpeta es el nombre del proyecto. El nombre de un Worker solo admite letras latinas minúsculas, cifras y guiones, así que todo lo demás (puntos, espacios, guiones bajos) lo cambiamos por un guion y añadimos un sufijo corto de cuatro caracteres aleatorios:

landing/                 ->  landing-42c2
my.first.page/           ->  my-first-page-8e10
portfolio-2026/          ->  portfolio-2026-b7a3

El sufijo sirve para que dos carpetas con el mismo nombre en proyectos distintos no ocupen la misma dirección. Se genera una sola vez, al crear el archivo de configuración, y siempre con un comando, no de la cabeza del agente: si no, tomará el sufijo del ejemplo, y todos los que leyeron el mismo artículo acabarán con el mismo. A partir de ahí, el sufijo siempre se lee de la configuración. Por eso mismo el skill primero mira si ya existe una configuración y solo después escribe algo.

El archivo de configuración lo escribe el agente

En wrangler.jsonc el agente guarda el nombre del proyecto y los ajustes de publicación, para lanzar el deploy sin preguntas en la terminal. La configuración está junto a index.html, así que la ruta a los archivos en ella es un punto, "esta misma carpeta":

{
  "name": "landing-42c2",
  "compatibility_date": "2026-09-07",
  "assets": { "directory": "." }
}

El campo compatibility_date fija el comportamiento compatible de la plataforma en la fecha indicada. Para una configuración nueva, el agente pone la fecha actual, como recomienda la documentación de Cloudflare; al volver a publicar, conserva la anterior.

Poner la configuración un nivel más arriba, junto a la carpeta, no es buena idea: el nombre del archivo es fijo, en un directorio solo puede haber un archivo así, y la segunda carpeta o bien sobrescribirá la configuración de la primera, o bien se publicará con su nombre. Dentro de la carpeta cada proyecto es autosuficiente, y el deploy se lanza directamente desde ella.

Un efecto secundario de esta organización: la configuración está en la misma carpeta que la página, así que se subirá al hosting junto con ella y se podrá abrir por enlace. No contiene secretos (un nombre, una fecha y un punto), y a quien le moleste puede poner al lado un archivo .assetsignore con la lista de lo que no se publica.

Tres reglas que conviene dejar explícitas en la tarea, porque el agente no las adivinará:

• si no hay archivo, crearlo y mostrar lo que se escribió;
• si hay archivo, dejar el nombre y la fecha tal cual, aunque la fecha de hoy sea otra;
• reescribir el archivo solo cuando el contenido cambia de verdad.

Cuatro peticiones que conviene tener a mano

La primera es la tarea para crear el skill. Es más larga que las demás, porque es la única vez que usted describe el procedimiento completo:

Crea un skill para desplegar páginas estáticas en Cloudflare Workers.
Ponlo en .claude/skills/ de este proyecto.
Al final muéstrame la ruta al SKILL.md creado y cómo invocar el skill de forma explícita.

Primero lee la documentación actual de Cloudflare sobre Workers
y static assets: los comandos y los campos de la configuración pueden haber cambiado.
Si algo de la descripción de abajo no coincide con la documentación, avísame,
no lo reescribas sin decir nada.

En la descripción del skill enumera las frases con las que debe activarse,
como mínimo: "publica la carpeta", "vuelve a publicar", "despliega en Cloudflare".

Procedimiento: tomo la carpeta y compruebo que en la raíz hay un index.html.
Saco el nombre del proyecto del nombre de esa carpeta: en él solo quedan
letras latinas minúsculas, cifras y guiones; todo lo demás (espacios,
guiones bajos, mayúsculas, letras no latinas) lo cambio por un guion.
Al final añado, separado por un guion, un sufijo de cuatro caracteres.
El sufijo no me lo invento, lo obtengo con el comando:
node -e "console.log(crypto.randomUUID().slice(0,4))"
La configuración wrangler.jsonc está dentro de la carpeta que se publica, junto
a index.html, y assets.directory en ella vale ".".
Si no hay configuración, la creo: name, compatibility_date,
assets.directory. Para un compatibility_date nuevo tomo la fecha actual
en formato YYYY-MM-DD. Muestro lo que escribí.
Si hay configuración, tomo de ahí el nombre y la fecha y no los reescribo.
Reescribo el archivo solo cuando el contenido cambia de verdad.
Si hay configuración, pero assets.directory no apunta a esta carpeta
o la configuración tiene el campo main, me detengo y lo digo, no lanzo el deploy.
Si piden volver a publicar y en la carpeta no hay configuración, me detengo
y pregunto, no creo un proyecto nuevo.
Deploy: npx wrangler deploy desde la carpeta del proyecto. Muestro el comando antes de ejecutarlo.
En la respuesta devuelvo la dirección pública y recuerdo revisar en ella
la página y las imágenes. Al actualizar, la dirección tiene que seguir siendo la misma.
Si no hay Node.js o no se ha iniciado sesión, lo digo
en lugar de intentar saltármelo.
Si la cuenta todavía no tiene subdominio workers.dev, lo digo:
el deploy no interactivo falla por eso.

Una vez creado, abra el archivo que le mostró el agente, .claude/skills/<nombre>/SKILL.md: en él deben estar las reglas de arriba. Antes de la segunda petición, invoque de forma explícita el skill creado, tal como le mostró el agente. Si el skill no aparece, pida al agente que compruebe la ruta y si está disponible en el proyecto actual.

La segunda es una comprobación antes de actuar. Resulta útil antes del primer deploy de una carpeta, cuando quiere ver el plan antes de que algo salga fuera; si hay varias carpetas, se hace para cada una:

No crees ni modifiques archivos, no ejecutes wrangler. Solo muéstrame
qué vas a hacer con la carpeta landing: qué nombre de proyecto,
qué configuración escribirás, qué comando ejecutarás.

Un matiz: el sufijo aparece en el momento de escribir la configuración, así que en una carpeta que todavía no la tiene, el nombre del plan y el de la ejecución real pueden no coincidir. Todo lo demás sí coincidirá.

La tercera y la cuarta son las de trabajo, las que justifican todo esto:

Publica la carpeta landing en Cloudflare Workers.

He corregido index.html en landing. Vuelve a publicarla en Cloudflare Workers.

Después de la primera publicación, abra el enlace obtenido y revise el texto y las imágenes. Luego cambie una frase bien visible en landing/index.html y envíe la cuarta petición. Recargue la página en la misma dirección: debe aparecer la frase nueva. Si la dirección cambió, pida al agente que revise el nombre en la configuración antes del siguiente deploy.

Con esto el camino principal está completo: el skill está creado, la página publicada y la actualización comprobada en el mismo enlace. Antes de cada publicación solo queda elegir la carpeta correcta y revisar el comando del agente.

6. Escenarios adicionales

A partir de aquí puede dejar de leer mientras no tenga que preparar muchas carpetas a la vez o lanzar el deploy sin iniciar sesión desde el navegador.

Cuando el procedimiento se queda corto

Un skill con instrucciones funciona bien mientras las carpetas sean unas pocas o unas decenas. Más allá empieza a estorbar que el agente relea el procedimiento cada vez y lo ejecute a mano: con medio centenar de carpetas eso es lento y no siempre sale igual.

Entonces el procedimiento se reescribe como script: recorre las carpetas por su cuenta, escribe las configuraciones, se salta aquellas en las que nada cambió e imprime un resumen. El skill no desaparece: simplemente llama al script en lugar de escribir él mismo las configuraciones, y el deploy lo sigue lanzando él.

Tampoco le toca a usted escribirlo. El agente ya tiene una descripción detallada del procedimiento, su skill, así que la petición queda corta:

Escribe en Python un script que haga lo mismo que describe mi skill
de deploy, pero para todas las carpetas del proyecto a la vez.

Toma las carpetas que tienen index.html en la raíz;
no entra en node_modules, .git ni dist.
Para cada una construye el nombre según nuestra regla y escribe wrangler.jsonc
dentro de la carpeta.
Si ya hay configuración, toma de ahí el nombre y compatibility_date,
y sobrescribe el archivo solo cuando el contenido cambió de verdad.
Si la configuración no se puede leer, no la toca, lo dice
y se salta la carpeta.
Por defecto solo muestra el plan y no escribe nada;
la escritura va con un flag explícito.
Hace falta un filtro para procesar solo las carpetas elegidas.
El script solo prepara las configuraciones, no lanza el deploy.
Al final imprime una tabla: carpeta, nombre del proyecto, qué se hizo.
Si algo de esta descripción es ambiguo, pregunta, no lo completes por tu cuenta sin decir nada.

Mostrar el plan permite revisar la lista de carpetas antes de escribir nada. Conservar el nombre y la fecha protege las configuraciones existentes de cambios accidentales. El script en sí solo prepara los ajustes; la publicación la sigue haciendo el skill.

Token de acceso

En su computadora ya inició sesión con npx wrangler login. Wrangler guarda esa autorización, y también la usan los comandos del agente.

Si necesita un lanzamiento automático sin iniciar sesión desde el navegador, o permisos más acotados, se usa un token de API. Se puede crear en el perfil: avatar, perfil, sección de tokens de API. La dirección directa es dash.cloudflare.com/profile/api-tokens.

El formulario de creación intimida: grupos de permisos, recursos, unos filtros. En realidad ahí hay cuatro decisiones, y la mitad de los campos se pueden dejar sin tocar.

1. Nombre del token. Dentro de seis meses no recordará para qué era, así que ponga algo concreto: "deploy de páginas desde el portátil", no "token 2".
2. Permisos. No hace falta reunirlos uno por uno, ni conviene. En la lista de plantillas ya hechas está Edit Cloudflare Workers, que incluye todo lo necesario para publicar.
3. Recursos. Limite el token a una sola cuenta, justo aquella en la que publica. Aunque solo tenga una cuenta, selecciónela de forma explícita: las cuentas pueden llegar a ser más, y el token seguirá siendo el mismo.
4. Vigencia y filtro por IP. Son campos opcionales. Poner una vigencia tiene sentido cuando el token se necesita para una tarde o para una máquina ajena; en el trabajo habitual se dejan como están.

Después, el token se guarda en la variable de entorno CLOUDFLARE_API_TOKEN, y la cuenta se indica en CLOUDFLARE_ACCOUNT_ID. Una variable de entorno es un ajuste de su máquina que los programas leen por sí mismos; wrangler encontrará las dos sin que usted intervenga. Cómo funcionan las variables y dónde conviene guardarlas es otro tema; aquí basta con saber que es un lugar, no una línea en la conversación.