Your website does not need a runtime

There is a question we ask early in every website project, and it decides most of the architecture: does any two visitors need to see a different page?

If the answer is no — and for a marketing site, a documentation portal, a handbook or a statutory disclosure page, it is almost always no — then a content management system is a program you are running for no reason.

What the runtime actually costs

A CMS on a public IP address is a process that accepts untrusted input, executes plugin code written by strangers, and holds a persistent connection to a database. Each of those is a reasonable thing to have when you need it. When you do not, each is a liability with an ongoing maintenance cost:

• Patch cadence. Core, themes and every plugin, forever, on somebody’s calendar.
• An administrative login on the public internet, which will be brute-forced.
• A database that can fill up, corrupt, or fall out of sync with a backup nobody has restored.
• A dependency tree that no one on your team has read and no one intends to.

None of that buys a single thing for a page that is identical for every visitor.

The alternative is unglamorous

Jekyll reads Markdown and templates and writes a directory of HTML. Then nginx sends the HTML. That is the entire production system.

There is no process to compromise, no query to slow down, and no plugin to patch on a Sunday evening. The security posture reduces to “keep the web server patched”, which is the best-understood maintenance task in the industry.

The performance follows from the same fact. There is no cold start, no query plan, no cache to warm. A static file served from Stockholm answers in tens of milliseconds, and — the part that matters — it is still answering in tens of milliseconds eighteen months later, because there is nothing in the system that degrades.

But the marketing team

This is the objection every time, and it has been solved for a decade. Content lives in Markdown in Git; colleagues who do not use a terminal get a Git-backed editing interface with normal write-and-preview behaviour. They write, they hit save, it becomes a commit, CI builds, the site updates.

Marketing never opens a terminal. Engineering never loses version control. The pricing page has an author and a diff, which turns out to matter the first time somebody asks who changed a public claim, and when.

When we say no

If you need per-user state, a checkout, or content changing by the minute, this is the wrong tool and we will quote you a Rails application instead. Roughly a third of the time that is the honest answer.

The remaining two thirds are running a database to serve the same eleven pages to everybody. Those should be a folder of HTML.