Zola

Last reviewed Aug 26, 2026 · 782 words

You do not self-host Zola. You run one binary on a laptop and self-host a folder of HTML it produces. That distinction is the reason to pick it: the server side of a Zola site is a directory and a file server, with nothing to patch, no database to back up, and no admin login to protect. The price is that every edit happens in a text editor and a terminal, and there is no web UI to hand to a non-technical co-author.

One binary and no toolchain

Zola ships as a single Rust binary with Sass compilation, syntax highlighting, a search index builder, image processing and a dev server compiled in. There is no Node, no Ruby, no Go module cache, and no npm install that breaks 8 months later on a fresh machine. Download the release for your platform, put it on PATH, and the same binary builds the same site identically in CI. For a blog that gets rebuilt from a git repo on a Forgejo runner or a GitHub Action, that reproducibility is the feature people underrate until they revisit a Jekyll site after a year away.

From init to a served page

zola init myblog
cd myblog
zola serve

init asks 4 questions (base URL, Sass, syntax highlighting, search index) and writes config.toml. serve watches the tree and rebuilds on http://127.0.0.1:1111 with live reload. Content lives under content/, with a _index.md marking a section and every page carrying TOML front matter between +++ fences:

+++
title = "Why I moved the blog to Zola"
date = 2026-08-26
[taxonomies]
tags = ["static-sites", "rust"]
+++

zola build writes the finished site to public/. Builds are fast enough that you stop noticing them; a few hundred pages finish before you have alt-tabbed to the browser. zola check validates internal and external links, and is worth wiring into CI.

Tera templates are the learning curve, themes are the shortcut

Zola uses Tera, a Jinja2-style template language. If you have touched Jinja, Django templates or Nunjucks, you already know it. If you have not, the first afternoon is spent learning {% block %}, {% for page in section.pages %} and the get_url and get_taxonomy functions. The escape hatch is a theme: clone one into themes/, set theme = "name" in config.toml, and override only the templates you need to change by placing a same-named file in your own templates/. The selection is smaller than Hugo's by a wide margin, which the catalogue rightly flags, but a blog needs one theme, not fifty, and a handful of the popular ones are maintained well.

Hosting the output is a Caddy file server

Everything after zola build is a static hosting problem. On your own box, Caddy serves the folder with automatic TLS in 4 lines:

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

The deploy is rsync -a --delete public/ server:/srv/blog/public/, or a runner job that builds and copies on every push. There is no runtime to monitor and the memory footprint is whatever Caddy uses. This is also why static sites score so well on speed metrics: no server-side rendering, no database round trip, just files, which the Core Web Vitals for static sites piece takes apart in detail.

Zola against Hugo

Hugo is the safer choice when you want a theme for every taste and answers to every question already on a forum. Zola is the choice when you would rather read one clear manual than search for which of Hugo's 6 ways of doing a thing applies. Go templates are the deciding factor for most people who try both; Tera reads like the templating you already know, and that alone saves hours.

What I'd do

For a personal blog or docs site maintained by 1 or 2 technical people, Zola, a well-maintained theme, zola check in CI, and Caddy serving public/ from a mini PC or a small VPS. Wire deployment to a git push so writing a post is editing a file and committing. If the site needs a web editor for someone who will not open a terminal, this is the wrong category altogether; look at a blogging platform with an admin UI instead, and accept the database that comes with it.