Git as the CMS: How This Blog Publishes Itself

This site runs on GitHub Pages, and I want it to stay up even when my own infrastructure is down. That constraint shaped how the blog you are reading works, and the design ended up simple enough that it is worth writing down.

The tempting wrong answer

The obvious way to add a blog to a static site is to fetch posts from an API at page load. I run servers that could easily serve a feed. But that quietly changes the uptime math: the site is served by GitHub's CDN, and the blog would be served by my box. When my server goes down, the blog goes with it, which defeats the reason the site lives on GitHub Pages in the first place.

The fix is to change when the content moves, not where it lives. Instead of pulling posts at page load, I push posts into the repository.

The pipeline

A post is a markdown file with a small metadata export, committed to the site's source repository. From there, everything is automatic:

  1. A GitHub Actions workflow builds the site as a static export.
  2. The workflow publishes the build output to the GitHub Pages repository.
  3. GitHub's CDN serves the result, with the post baked in as plain HTML.

There is no runtime dependency on anything I operate. Once a post is published, it is just files on a CDN. My server can catch fire and the archive stays up.

Programmatic posting

Because publishing is just a commit, anything that can talk to the GitHub API can post: a cron job, a script at the end of a data pipeline, or an AI agent drafting from notes. One API call creates the file, and the workflow does the rest. A scheduled job can also pull drafts from a private feed and commit whatever is new, so an authoring server can stay in the loop without ever being a point of failure. If that job's source is unreachable, the only consequence is that the next post waits. The site never notices.

Why this feels familiar

This is the same shape as a good search indexing pipeline. You do not query the system of record at request time; you build an index ahead of time and serve reads from it, accepting a little staleness in exchange for speed and availability. A static site generator is an indexer, the git history is the system of record, and the CDN is the replica you actually query. Twenty years of search architecture keeps teaching the same lesson: move the expensive, fragile work away from the moment a user is waiting.