Jekyll

Jekyll reads Markdown and templates and writes out a directory of HTML. That covers the product, its security model and most of the maintenance plan.

Why we still choose it

The alternative is a content management system on a public IP address, executing plugin code and talking to a database. When every visitor sees the same page, that is a program running for no reason. Without a runtime there is no patch cadence, no admin login and no database, and none of the incidents that come with them.

Jekyll is also fifteen years old and still builds the same way. In that time several generations of static generators have been announced and abandoned.

How we run it

Content lives as Markdown in your Git repository and is reviewed in pull requests, with a Git-backed editor for colleagues who do not use a terminal. Your own CI builds the site, checks links and enforces a performance budget, and nginx serves the resulting directory from Stockholm or Falkenstein. There are no third-party scripts, no cookie banner and no tracker to disclose.

Where it falls short

Per-user state, checkout flows and content that changes by the minute do not suit static generation. Roughly a third of the time, the answer to “should this be Jekyll?” is no, and we would rather say so in the first meeting than in the fourth month.

This site is built with it.