Eleventy

Last reviewed Aug 26, 2026 · 791 words

Eleventy is a build step, not a server. It reads a folder of Markdown and templates, emits plain HTML into _site/, and ships no JavaScript to the browser unless you add some. For a self-hosted blog that means the running cost of the site is the cost of serving static files, which on a 5-year-old mini PC behind Caddy is a rounding error, and there is no admin panel, database or PHP process to patch. The price is that Node.js has to exist somewhere in the pipeline, and that "publish a post" means "commit a file". If you are fine with both, this is the most flexible static generator I have used.

The whole toolchain is one npm package

mkdir blog && cd blog && npm init -y
npm install @11ty/eleventy
npx @11ty/eleventy --serve     # dev server with live reload
npx @11ty/eleventy             # production build into _site/

Configuration lives in eleventy.config.js and can be as short as setting the input and output directories. Templates can be Markdown, Nunjucks, Liquid, WebC, plain JavaScript or several others, mixed freely in the same project, and a .md file with a layout: line in its front matter is a page. Builds are fast: a few hundred posts finish in seconds on the 256 MB the catalogue lists, and the incremental mode rebuilds only what changed during development.

The data cascade is the reason to pick it over Hugo

Hugo is faster to build and a single binary with no Node, and for a plain blog it is a fine choice. Eleventy's edge is how data flows. A _data/site.json file is available to every template; a posts/posts.json file applies defaults (layout, tags, permalink pattern) to everything in that directory; front matter overrides both; and a JavaScript data file can fetch from an API at build time, so a page listing your Jellyfin library or your Git repositories is a 10-line file. Collections are built from tags automatically. Hugo's Go templates can do most of this, but the cascade makes it obvious where a value came from, which is what you want when you come back to the site after 6 months.

Hosting the output is a 4-line Caddyfile

The build produces files; a web server serves them. That means Caddy with automatic HTTPS:

blog.example.com {
    root * /srv/blog/_site
    encode gzip
    file_server
}

The publishing loop I run is a git remote on the server with a post-receive hook that checks out the branch, runs npm ci && npx @11ty/eleventy, and rsyncs _site into place, so a push publishes. If you already host Forgejo, a 15-line Actions workflow does the same with logs you can read, and the build container needs nothing but Node. Either way the web server never runs Node; it only ever sees HTML, CSS and images, and there is nothing on the public surface to exploit.

No admin UI is the trade, and it is a real one

Writing in a text editor and committing is natural for developers and a wall for everyone else. Ghost and WordPress win outright for a non-technical co-author, scheduled posts from a phone, or comments. Git-based editors such as Decap CMS bolt a browser form onto the repository and get you most of the way, but you are still running a build on every save. Be honest about who will write for the site before choosing; the blogging category splits cleanly on this axis and Eleventy sits firmly on the "I write in my editor" side.

Zero client JS is a default, not a limit

Out of the box a page has no framework, no hydration, no bundle, which is why Eleventy sites score well on every performance audit without effort. When you do want interactivity, WebC components or a plain <script> tag are there, and the Image plugin generates responsive srcset sets at build time so a photo-heavy post is not a 6 MB download. The lean output is also why hosting is cheap: a static blog on Caddy handles a front-page-of-Hacker-News spike from a Raspberry Pi without noticing.

What I'd do

Eleventy with Nunjucks layouts and Markdown posts, _data/site.json for the globals, a git post-receive hook on the server, Caddy serving _site. Keep client JavaScript at zero until a specific page needs it. If a non-developer will ever need to post, choose Ghost instead and do not fight the tool; if the writers are all comfortable with a text editor, nothing self-hosted is cheaper to run or easier to keep secure than a folder of HTML.