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: do any two visitors need to see different pages?

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

What the runtime 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:

• Core, themes and every plugin need patching, indefinitely, on somebody’s calendar.
• There is an administrative login on the public internet, and it will be brute-forced.
• There is a database that can fill up, corrupt, or fall out of sync with a backup nobody has restored.
• There is a dependency tree that no one on your team has read or intends to.

For a page that is identical for every visitor, none of that buys you anything.

The static alternative

Jekyll reads Markdown and templates and writes a directory of HTML, and nginx serves that HTML. The production system consists of nothing else.

With no application process, there is nothing to compromise beyond the web server, no query to slow down and no plugin to patch on a Sunday evening. Security comes down to keeping the web server patched, which is about the best-understood maintenance task in the industry.

Performance follows from the same fact. There is no cold start, query plan or cache to warm. A static file served from Stockholm answers in tens of milliseconds, and it still answers in tens of milliseconds eighteen months later, because nothing in the system degrades over time.

But the marketing team

We hear this objection every time, and it has been solved for a decade. Content lives in Markdown in Git, and colleagues who do not use a terminal get a Git-backed editing interface that lets them write and preview as usual. When they save, the change becomes a commit, CI builds the site and it updates.

Marketing does not need a terminal and engineering keeps version control. The pricing page has an author and a diff, which matters 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. That is the right answer roughly a third of the time.

The other two thirds are running a database to serve the same eleven pages to everybody, and those sites would be better off as a folder of HTML.