A CMS I
actually write in.

A ::: block layer over Markdown rendering timelines, callouts, service grids and phase accordions — which is what makes a project page authorable as a document.

A dozen palettes with light twins and per-topic accents, stored in Postgres and inlined before first paint — so there is no theme flash on load.

document_links feeds a navigable graph clustered by topic, with backlinks and multi-chapter wiki books over the top.

Full revision history and scheduled publishing — the two things a static generator turns into build-pipeline problems and Postgres turns into columns.

Comments, reactions, newsletter and analytics all written first-party. No third-party script runs on a reader's page — and so there is no consent banner to design around.

Overkill for a blog on its own — the point was to practise the shape on something real and shipped before applying it to cairn and marginal.

Full-text search as a generated always tsvector column with a GIN index — the database keeps it correct, so no application code can ever forget to reindex.

Server-side highlighting with line numbers, filenames and diff markers — done once at save time, so a code-heavy post costs a reader nothing extra.

Long-form work organised into multi-chapter books with their own index and reading order, backed by wiki_index.

A database-backed CMS rather than git-and-markdown. Static generators turn scheduled publishing, revision history and a media library into build-pipeline problems; in Postgres they are columns. The cost is a server to run — which this project wanted anyway.

Markdown is rendered once, on save, and both forms are stored. Readers never pay for parsing or syntax highlighting, and a directive that changes shape is re-rendered across every document by replaying the pipeline rather than by migrating content.

Comments, reactions, newsletter and analytics are all first-party. No third-party script runs on a reader's page — both a privacy position and the reason the site has no consent banner to design around.

A hexagonal-leaning layout — domain → app → infra, with api as the web edge. Overkill for a blog on its own; the point was to practise the shape on something real before applying it to cairn and marginal.

One VPS, one Compose file, Caddy for automatic TLS, GitHub Actions pushing images to GHCR on merge. Deliberately boring — the interesting infrastructure work belongs to cairn, where it is the actual subject.

Theme families live in Postgres and are inlined into the document before first paint, rather than applied by a script after hydration. It costs a little server-rendered CSS on every page; it buys the absence of a theme flash, which is the one thing readers actually notice.