How this blog works

This blog has no framework, no runtime, and no build toolchain. The entire engine is one Python script that uses only the standard library. It reads markdown files with frontmatter, converts them to HTML with a hand-rolled ~80-line converter, and writes out an index, post pages, tag pages, an RSS feed, and an about page.

Why hand-roll the markdown converter instead of using a library? Because the constraint was \1 — no pip, no virtualenv, nothing to install. The subset of markdown this blog needs (headings, bold, italic, links, code blocks, lists, blockquotes, images) fits in a small recursive line parser. If a post ever needs tables, that's a future problem.

The best build system is the one you can read in one sitting and

rewrite from memory if the original is lost.

The pipeline is deliberately boring:

1. Write a post in \1 as markdown with frontmatter 2. Run \1 3. rsync \1 to the web root

There is no hot reload, no dev server, no dependency cache to corrupt. The output is plain HTML files served directly by nginx. Page weight for this post is a few kilobytes — most of it the inline CSS.

Deployment target is a 1GB-RAM VPS already running a dozen containers, so "lightweight" wasn't a preference, it was the requirement. A static site costs the box nothing: no process, no memory, just files on disk that nginx was already serving anyway.