What I launched

This site now has a working path from my local editor to GitHub and then to Cloudflare Pages. I can finish a post, push the change, and let the pipeline handle the public build.

That sounds obvious because it should be obvious. Getting there still required enough testing and troubleshooting that it was worth documenting.

How the pipeline works

GitHub is the connection point. When I push an update, GitHub Actions checks the project in a clean environment. The same GitHub repository is connected to Cloudflare Pages through Cloudflare’s Git integration. Cloudflare sees the commit, builds the static site, and publishes the new version.

The public path is simple:

1. I write and preview the change locally.
2. The update is pushed to GitHub.
3. GitHub Actions runs the project checks.
4. Cloudflare Pages picks up the connected commit.
5. Cloudflare builds and publishes the site.

GitHub Actions and Cloudflare Pages each respond to the repository update. Actions handles validation. Cloudflare handles the public deployment. I can check both services against the same commit instead of guessing which version is live.

What I tested

I tested the site locally first, including the production build and the public preview. That caught basic content and layout problems before GitHub was involved.

Next, I pushed the project and watched GitHub Actions run from a clean environment. This was important because a project can work perfectly on the computer where it was built and still fail somewhere that does not have the same tools or cached files.

After the Cloudflare deployment completed, I checked the live pages, navigation, article dates, RSS feed, sitemap, and mobile layout. A green deployment status is useful, but the actual site still needs to be opened and tested.

What broke during setup

Most of the problems were small configuration differences. The build could finish while Cloudflare looked in the wrong place for the generated site. Old test content could also remain visible after I thought it had been removed.

I worked through those problems by checking the output itself instead of repeatedly changing settings and hoping for a different result. I verified which pages were generated, removed stale content, and made sure the local and hosted builds agreed.

The final setup is intentionally boring. A new commit should produce a new deployment without requiring me to rebuild the process from memory every time.

What I have now

The result is a small pipeline with clear ownership. GitHub stores the project and runs the checks. Cloudflare Pages stays linked to the repository and serves the public site.

I still review the live result because automation does not remove responsibility. It removes repetitive steps and makes failures easier to find.

The next test is simply using it. A pipeline is not finished because it worked once. It is useful when I can publish the next post without having to remember every setup step again.