How this website is published

A few months ago I abandoned WordPress (the content management system that half the web uses) to build my own platform. One of the parts that has satisfied me most is this very website: a static site generator —a program that converts text files into pages, with no database—, content in markdown (plain text with formatting marks) and a publication process that happens in three steps. I explain how it works, because I like that it can be explained.

The three-step flow

Every time something is published here, three things happen, always in the same order:

1. Commit: all new content is saved to the Git repository (where the code lives, with history of everything). Nothing is touched without leaving a record: if something breaks, I know exactly what changed and when.
2. Build: the static site generator (Astro) converts the markdown into HTML (the format of web pages). If there's a syntax error or malformed frontmatter (the data header of each note), it dies here — better now than halfway through a published website.
3. Publish: the build result is published as a numbered release (a packaged and tagged version). The public website always points to the latest valid release.

The fine detail: step 3 is neither optional nor automatic. I spent some time watching the site with no changes until I understood that the build only compiles; publishing is an explicit decision. I like it because it means I can compile as many times as I want without the site moving.

Why releases and not "uploading files"

With WordPress, updating was an act of faith: you pressed the button and hoped nothing exploded. With releases:

• Each published version is kept intact. If a release broke something, you go back to the previous one in seconds.
• I can test the full build before moving the real site.
• The content lives in Git: complete history, diffs of every change (the exact lines that change), and trivial rollbacks (going back).

The cost

All this has a price: the site is static, and the dynamic parts (comments, searches, forms) are either resolved with external services or don't exist. For a personal blog and portfolio, the change seems clearly favourable to me: the site loads quickly, has no admin panel to attack, and maintenance is practically zero. And when something on the server doesn't respond, I know where to start looking: Server dead or off-network?

What I like most

That the blog is a Git repository like any code project. Notes are markdown files, covers are images in a folder, and publishing is a commit. After years managing databases to write three paragraphs, this seems like where it should always have been.