01 Module · Why Jekyll
The website that has
nothing to go wrong.
Jekyll takes Markdown and templates and produces a directory of HTML, and that is all it does. Its strengths follow from that design decision, and so do its limitations.
- First released
- 2008
- Written in
- Ruby
- Runtime in production
- None
- Licence
- MIT
Almost every website disaster we have been called in to clean up had the same shape: something was running that did not need to be.
A content management system is a program that sits on a public IP address, talks to a database, executes plugin code written by strangers, and regenerates the same page for every visitor. It has an administrative login. It has a version number that needs to keep moving. It has a dependency tree nobody has read.
A documentation portal or a marketing site changes a few times a week and looks identical to every visitor. For that kind of content, all of that machinery is a liability: it adds nothing and can fail in several hundred ways.
Jekyll removes the machinery. You write Markdown, it produces HTML, and a web server sends the HTML. There is no running process to compromise or database query to slow down, and no plugin to patch on a Sunday evening.
Argumenten · The case
Eight reasons,
in order of how often they matter.
Ranked by what comes up in the second year of owning a site, rather than what sounds best in the first week.
01 The attack surface is a file server
There is no database, interpreter, admin login or plugin marketplace. The
common categories of website compromise (SQL injection, plugin RCE, credential stuffing on
/wp-admin) have nothing to target, and security mostly comes down to keeping nginx patched.
02 Every edit is a reviewable commit
Content lives in Git next to the code. Who changed the pricing page, when, and
why is a git log away. Reverting a bad Friday deploy is one command, and legal can be
given a signed history of a public claim.
03 It is fast
Static HTML from a European server or CDN edge answers in tens of milliseconds rather than hundreds. There is no cold start, query plan or cache to warm, which is why it is still fast eighteen months later.
04 Traffic spikes are uneventful
A front-page link on a Tuesday only affects bandwidth; the architecture does not change. The same €4 machine that serves forty visitors serves forty thousand, and the invoice looks the same at the end of the month.
05 The repository is the backup
There is no database to dump, uploads directory to sync or restore procedure to rehearse. Any developer with a clone can rebuild the entire site on a laptop, offline, in under a second.
06 Non-developers can still edit it
This is the objection we hear most, and it has had a solution for a decade. We set up a Git-backed editing interface with normal write-and-preview behaviour, so marketing never has to open a terminal and engineering keeps version control.
07 No lock-in worth the name
Your content is Markdown. Your templates are HTML with Liquid tags. If Jekyll vanished tomorrow, the output directory would keep serving indefinitely, and porting to another generator would take about a week rather than a rebuild.
08 It has already outlived its replacements
Jekyll shipped in 2008 and still builds the same way. Several generations of static generators have been announced, adopted and abandoned in that time. That longevity starts to matter by year four.
Jämförelse · Side by side
Against a typical CMS
Figures from sites we operate, measured from Frankfurt. Your numbers will differ, but the gap should be similar.
| Concern | Typical CMS | Jekyll, as we build it |
|---|---|---|
| Runtime on the public internet | PHP or Node, plus a database | nginx serving files |
| Time to first byte | 200–900 ms | Under 40 ms |
| Monthly hosting | €25–€200 | €4, or free from a CDN |
| Security patching cadence | Core, themes and every plugin | The web server, and Ruby at build time |
| Version history | A revisions table, if enabled | Complete Git history with authorship |
| Staging environment | A second installation to keep in sync | A branch and a preview build |
| Backups | Database dumps plus an uploads directory | The repository, cloned everywhere |
| Localisation | A plugin, usually paid | Directories and front matter |
| Editing for non-developers | Built in | Git-backed editor, wired by us |
| Dynamic user accounts, checkout, search-as-you-type | Built in | Wrong tool; we quote Rails instead |
Hur vi bygger · Our build
What goes into a Chenborg Jekyll site.
We do not buy themes and we do not ship a default install. Every site is a design system authored from scratch, with the performance budget and the accessibility rules enforced in CI so that they still hold in the second year.
- A bespoke theme covering typography, grid, colour tokens, dark mode and print styles
- Content modelled in collections and data files instead of copy-pasted between pages
- Git-backed editing for colleagues who do not use a terminal
- Multilingual routing, structured data, sitemap, Atom feed, clean canonical URLs
- CI on Forgejo or GitLab that builds, checks links and refuses a bloated page
- Deployment by rsync to nginx on NixOS, in Stockholm or Falkenstein
- No third-party scripts, no cookie banner, no tracker to disclose
tree -L 2
chenborg.com/ ├── _config.yml # one file, no admin panel ├── _data/ # stack.yml, faq.yml, people.yml ├── _includes/ # head, header, footer, tiles ├── _layouts/ # default, page, post, service ├── _posts/ # the journal, in Markdown ├── _sass/ # tokens, base, components ├── _services/ # a collection, not nine pages ├── assets/ │ ├── css/main.scss │ ├── js/main.js # 1.6 kB, no dependencies │ └── img/logos/ └── index.html # build output $ du -sh _site 412K _site # the entire website
I gott sällskap · In good company
Jekyll is a mainstream choice.
A selection from the official Jekyll showcase. Governments, standards bodies and framework maintainers reached the same conclusion we did.
Ruby on Rails
rubyonrails.org, the framework's own site.
U.S. Web Design System
The design standard for American federal government sites.
plainlanguage.gov
Alongside login.gov, foia.gov and 18F.
Spotify for Developers
With Netflix Devices, Twitch developer docs and Sketch.
Isomer, Singapore
A whole-of-government publishing platform, built on Jekyll.
UN World Statistics
With the French government's digital services.
The Markdown Guide
With CSS Reference and HTML Reference.
Development Seed
And COLLINS, studios who could have used anything.
Nackdelar · The downsides
When Jekyll is the wrong answer.
Jekyll does one thing, and using it for the wrong job would cost you more than it costs us. We will steer you elsewhere when you need:
- Per-user state: accounts, dashboards, permissions, anything where two visitors must see different pages. That is a Rails application.
- Transactions: checkout, booking, payment. Static generation has no place to put the money.
- Content that changes by the minute: live inventory, ticketing, a newsroom filing every ten minutes. A rebuild per change becomes impractical somewhere past a thousand pages an hour.
- Very large corpora: tens of thousands of pages will build, but slowly. Incremental generators exist, and we will recommend one.
- An editorial team that will not adopt any workflow: the Git-backed editor solves most of this, but it cannot help a team that has decided in advance to be unhappy.
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.