Alexsandro Assis
← Build Journal
Content Ops 7 min

Automating deploys: from the editorial database to Cloudflare Pages

How to design a pipeline where Baserow, n8n, GitHub API, and Cloudflare Pages publish an Astro site without repetitive manual work.

Publishing a static site does not need to be a manual ritual. If the content is already structured in an editorial database, the natural next step is to turn approval into a file, the file into a commit, and the commit into a deploy.

That is the role of a pipeline with Baserow, n8n, GitHub API, and Cloudflare Pages: reducing publication to a predictable, traceable flow that depends less on manual action.

The publishing pipeline

The flow starts before the deploy. It starts when an idea becomes approved content.

A simple pipeline can follow this order:

  1. Baserow stores the topic, status, and editorial fields.
  2. n8n identifies approved records.
  3. n8n builds the Markdown files.
  4. The GitHub API creates or updates files in the repository.
  5. Cloudflare Pages detects the commit and publishes the site.

The important point is that each tool does one thing. The database organizes. n8n orchestrates. GitHub versions. Cloudflare publishes.

GitHub as the delivery point

Using GitHub as the delivery point has a major advantage: every published piece becomes history.

If a post goes out with an error, there is a diff. If a translation needs adjustment, there is a commit. If automation generates something strange, you can audit the final file before blaming the site.

In an Astro project, n8n can send files to:

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

Each file must respect the collection schema. That is the protection against incomplete content, broken metadata, and pages published outside the expected pattern.

Cloudflare Pages as the publisher

Cloudflare Pages closes the pipeline because it turns commits into publication. The site does not need a PHP server, a public database, or an exposed admin panel.

Deploy becomes a consequence of versioning. That changes the mindset: publishing stops being a button click and becomes promoting a traceable change.

A good deploy pipeline is not the one that publishes anything quickly. It is the one that publishes only what passed clear criteria.

What to check before automating

Before allowing automation to publish on its own, it is worth adding guardrails:

  • Validate required fields before the commit.
  • Generate draft: true for content that still needs review.
  • Check whether the canonicalId exists in translations.
  • Prevent accidental overwrite of already published posts.
  • Record the deploy result in the editorial database.

Good automation is not lack of control. It is control encoded.

Documentation