Tutorial: publicá un sitio gratis con GitHub, Cloudflare Pages e IA
Este es el proceso que uso para llevar un sitio estático de cero a producción: URL pública, HTTPS,
despliegue automático en cada git push, y sin pagar nada. Ni siquiera un dominio, si no
querés uno. La parte que de verdad importa no es la infraestructura en sí (es la misma que usan
miles de sitios), sino cómo delegarle la ejecución a un asistente de IA sin delegarle el criterio:
qué credenciales le das, con qué alcance, y cómo verificás cada paso en vez de asumir que salió
bien porque el asistente dijo que sí.
Requisitos
- Visual Studio Code (o el editor que uses).
- Un asistente de IA con acceso a tu terminal: Claude Code o Codex CLI. Uso Claude Code en los ejemplos, pero los pasos con Codex son casi idénticos. Los dos pueden correr comandos, leer y escribir archivos, y llamar APIs si les das las credenciales.
- Una cuenta de GitHub (plan gratuito, alcanza de sobra).
- Una cuenta de Cloudflare (plan gratuito: sin costo para sitios estáticos, sin límite de sitios).
- Un dominio propio, opcional. Si no tenés uno, Cloudflare te da un subdominio real y
funcional gratis (
tu-sitio.pages.dev) con HTTPS incluido. Comprar un dominio cuesta dinero (no es parte de la promesa de “gratis”); lo cubro más abajo como paso opcional.
El panorama general
No voy a cubrir la configuración específica de DNS de tu proveedor de dominio (GoDaddy, Namecheap, tu registrador local, el que sea) porque cada uno tiene una interfaz distinta y ese detalle envejece mal en un tutorial. Lo que sí es igual siempre son las piezas y cómo se conectan:
- Tu código vive en un repositorio de GitHub.
- Ese repositorio se conecta a un proyecto de Cloudflare Pages, que se suscribe a los pushes de la rama principal.
- Cada push dispara un build automático (Cloudflare corre tu comando de build, por ejemplo
npm run build) y publica el resultado. - Opcionalmente, apuntás tu dominio hacia ese proyecto agregando un registro DNS. Cloudflare te muestra exactamente cuál cuando llegás a ese paso, sea cual sea tu proveedor.
Hay dos caminos para recorrer esto. Podés hacerlo vos mismo a mano, o dárselo a una IA con acceso a tu terminal. Cubro los dos.
Camino A: hacerlo vos mismo
A grandes rasgos: creás el repo en GitHub y subís tu código; en el dashboard de Cloudflare vas a
Workers & Pages → Create → Pages → conectar con Git, elegís el repo, configurás el comando de
build (npm run build) y el directorio de salida (dist/client si usás Astro con el adapter de
Cloudflare, más sobre esto abajo), y Cloudflare hace el resto. Si tenés dominio, la pestaña
Custom domains del proyecto te da el registro exacto que hay que agregar en tu proveedor.
Camino B: que lo haga una IA con acceso a tu terminal
Delegar la ejecución no es lo mismo que delegar el criterio. La diferencia entre usar un asistente de IA como copiloto y usarlo como piloto automático está en qué tan bien definís el trabajo y qué tan bien verificás lo que hizo. No en soltarle una instrucción vaga y aceptar lo que devuelva. Acá aplico el mismo rigor que si lo hiciera a mano. Solo que la ejecución es más rápida.
Antes que nada: cómo pasarle credenciales sin exponerlas
No toda credencial merece el mismo nivel de cuidado. Una conexión a una base de datos que solo acepta tráfico desde tu propia infraestructura privada tiene un radio de exposición distinto al de un token de una API de terceros que factura a tu nombre o controla tu dominio. Los tokens de Cloudflare, de un registrador de dominio, o de una plataforma de mensajería sí entran en esa segunda categoría: alguien con ese token actúa en tu nombre en un sistema que no controlás vos.
Para esos casos, el patrón sigue siendo el de siempre: variables de entorno en un .env,
agregado a .gitignore desde el primer commit.
- El asistente lee el
.env; vos nunca pegás el valor en el chat. El historial de una conversación con IA es, para estos efectos, un canal más por el que un secreto puede filtrarse. Tratalo con el mismo criterio que un log. - Generá el token con el alcance mínimo necesario, desde la sección correcta del panel. En
Cloudflare, por ejemplo, es
My Profile → API Tokens, no la sección de R2, que emite credenciales de almacenamiento de objetos con un formato similar pero que no sirven para administrar Pages. - Revocalo cuando termines si no lo vas a reutilizar.
I want to deploy a static site to Cloudflare Pages using GitHub as the source.
1. Read CLOUDFLARE_API_TOKEN and CLOUDFLARE_ACCOUNT_ID from .env (already in
.gitignore) — do not ask me to paste them in chat.
2. Verify the token works (GET /client/v4/user/tokens/verify).
3. Check whether a GitHub repo already exists for this project. If not, offer
to create one (ask me to confirm the visibility: public or private).
4. Create or update a Cloudflare Pages project connected to that GitHub repo,
with build command `npm run build`.
5. IMPORTANT: if this is an Astro project using @astrojs/cloudflare, the
build output directory must be `dist/client`, not `dist` — the adapter
splits client assets and the worker script into separate folders, and
pointing at `dist` silently deploys an empty/broken site that still
reports a "successful" build.
6. Trigger a deployment and poll its status until it finishes. Report the
final URL and whether it succeeded.
7. If I have a custom domain, tell me exactly what DNS record to add — don't
guess my registrar's UI, just give me the record type/name/value from
Cloudflare's own API response.
El paso 5 no es un caso hipotético. Es el error más común y más silencioso al combinar Astro con el
adapter de Cloudflare. El build termina en verde, el proyecto se marca como desplegado, pero
sirve una carpeta sin index.html. Lo dejo explícito en el prompt precisamente para que el
asistente no lo pase por alto, y para que vos sepas qué mirar si el resultado no coincide con lo
que pediste.
Buscando mejores skills y prompts
No hace falta escribir todo desde cero. Los asistentes de código soportan skills, paquetes de
instrucciones reutilizables que se activan solas cuando el contexto calza. Para diseño visual, por
ejemplo, hay una skill llamada frontend-design que ayuda a tomar decisiones de dirección estética
en vez de quedarte con el look genérico por defecto.
También podés instalar skills de la comunidad. En este mismo blog usé ese mecanismo para el rediseño visual. No es hipotético, es exactamente este comando:
npx skills add https://github.com/<usuario>/<repo-de-la-skill> --skill <nombre>
Este comando descarga y ejecuta código de terceros. Tratalo como instalar una dependencia más: revisá qué hace antes de confiar en el resultado, igual que harías con un paquete de npm.
El sitio de ejemplo: un estudio de arquitectura
Para no dejar todo esto en abstracto, armé un sitio de ejemplo completo: la landing de un estudio de arquitectura ficticio, con formulario de contacto y WhatsApp. Este es el prompt que usé para generarlo:
Build a single-page static site (Astro, no backend) for a fictional
architecture firm. Sections: sticky header with nav, hero with a call to
action, services (4 cards), a projects gallery (use CSS gradient
placeholders, not real photos — I'll swap those in later), an about section
with the firm's story, and a contact section with:
- A working contact form posted to Formspree (use a placeholder endpoint
`https://formspree.io/f/TU_FORM_ID` and comment that I need to replace it
with my own free Formspree form).
- A WhatsApp click-to-chat button (`https://wa.me/<number>?text=<message>`,
no API needed) with a clearly fake placeholder phone number.
Design direction: warm and elegant, not a generic dark tech theme — cream/
beige background, a serif display font for headings, a terracotta accent
color. This should look nothing like a SaaS dashboard.
Do not fabricate real business data (address, phone, review testimonials) —
use clearly-labeled placeholder content that I will replace.
Sobre WhatsApp: qué es fácil y qué no
El botón wa.me de arriba es un simple link. Sin API, sin costo, sin aprobación de nadie. Abre
WhatsApp con un número y un mensaje precargado. Para la mayoría de sitios de negocio, alcanza.
Lo que no es igual de simple es integrar la API de WhatsApp Business (la de Meta) para automatizar respuestas, leer mensajes entrantes desde tu backend, etc. Esa API requiere verificación de negocio, registro de número, y configuración de webhooks. No hay un MCP ni un flujo de un solo prompt que una IA pueda completar de punta a punta sin que vos hagas pasos manuales en el Business Manager de Meta. Si tu caso de uso necesita eso, andá con tiempo. No esperes que sea tan directo como el resto de este tutorial: está pensado para quien ya tiene algo de experiencia con integraciones de terceros.
El repo demo
El código completo del sitio de arquitectura está público: github.com/fernandoloria/tutorial-sitio-gratis-github-cloudflare-ia. Cloná, reemplazá los placeholders marcados en el README (número de WhatsApp, endpoint de Formspree, fotos de proyectos) y desplegalo siguiendo cualquiera de los dos caminos de arriba.