Alexsandro Assis
← Diario de Construcción
Operaciones de contenido 7 min

Automatizando deploys: de la base editorial a Cloudflare Pages

Cómo diseñar una cadena donde Baserow, n8n, GitHub API y Cloudflare Pages publican un sitio Astro sin trabajo manual repetitivo.

Publicar un sitio estático no necesita ser un ritual manual. Si el contenido ya está estructurado en una base editorial, el siguiente paso natural es transformar aprobación en archivo, archivo en commit y commit en deploy.

Ese es el papel de una cadena con Baserow, n8n, GitHub API y Cloudflare Pages: reducir la publicación a un flujo previsible, rastreable y menos dependiente de acción manual.

La cadena de publicación

El flujo empieza antes del deploy. Empieza cuando una idea se convierte en contenido aprobado.

Una cadena simple puede seguir este orden:

  1. Baserow guarda el tema, el estado y los campos editoriales.
  2. n8n identifica registros aprobados.
  3. n8n monta los archivos Markdown.
  4. La GitHub API crea o actualiza los archivos en el repositorio.
  5. Cloudflare Pages detecta el commit y publica el sitio.

El punto importante es que cada herramienta hace una cosa. La base organiza. n8n orquesta. GitHub versiona. Cloudflare publica.

GitHub como punto de entrega

Usar GitHub como punto de entrega tiene una ventaja enorme: todo contenido publicado se convierte en historial.

Si un post sale con error, existe diff. Si una traducción necesita ajuste, existe commit. Si una automatización genera algo extraño, puedes auditar el archivo final antes de culpar al sitio.

En un proyecto Astro, n8n puede enviar archivos a:

  • src/content/blog/pt
  • src/content/blog/en
  • src/content/blog/es

Cada archivo necesita respetar el schema de la collection. Esa es la protección contra contenido incompleto, metadatos rotos y páginas publicadas fuera del patrón esperado.

Cloudflare Pages como publicador

Cloudflare Pages cierra la cadena porque transforma commits en publicación. El sitio no necesita servidor PHP, base de datos pública ni panel administrativo expuesto.

El deploy pasa a ser una consecuencia del versionado. Eso cambia la mentalidad: publicar deja de ser hacer clic en un botón y pasa a ser promover un cambio rastreable.

Una buena cadena de deploy no es la que publica cualquier cosa rápido. Es la que publica solo lo que pasó por criterios claros.

Cuidados antes de automatizar

Antes de permitir que una automatización publique sola, conviene imponer algunas protecciones:

  • Validar campos obligatorios antes del commit.
  • Generar draft: true para contenido que aún necesita revisión.
  • Comprobar si el canonicalId existe en las traducciones.
  • Impedir overwrite accidental de posts ya publicados.
  • Registrar el resultado del deploy en la base editorial.

Una buena automatización no es ausencia de control. Es control codificado.

Documentación