Anatole and the two-column Hugo theme with everything optional switched off

A Farbox layout with a Hugo implementation behind it

Anatole is a two-column Hugo theme with a minimalist design, and its ancestry is stated plainly in the repository description: it is based on farbox-theme-Anatole, the theme by Cai Cai that formed the foundation for this project. The special thanks section in the README names Cai Cai first for that foundation, which is the honest way to describe a theme that grew out of another theme.

The rest of the credits give a picture of what goes into a small but complete theme. Kareya Saleh provided the profile picture used in the example site, Petri R the portfolio picture, Ales Krivec the thumbnail used in the example site image test post, Tobias Ahlin his SpinKit, used in the example site redirect post, and FontAwesome the icons. The example content therefore doubles as a test bed, with a portfolio, a thumbnail and a redirect post all exercised on a real site rather than described in a table.

The theme is published where Hugo users look for it, on the Hugo themes site, and the repository carries a theme.toml file, which is the metadata file Hugo expects from a theme. There is a live demo hosted on Netlify at anatole-demo.netlify.app, and the repository includes a netlify.toml and a Netlify status badge, so the demo is deployed from the same source as the theme.

The intended user is someone who writes in Markdown and wants a personal site that loads quickly and does not fight the writing.

A feature list where most items are optional

The feature list is worth reading as a configuration decision rather than a shopping list. Dark mode, multilingual support and RTL support are named without qualification, which means they are part of what you get. Post Series, Twitter Cards, Open Graph and Google Fonts support are also listed plainly. A 100/100 Google Lighthouse score is advertised, and the repository's development dependencies include a Netlify Lighthouse plugin, so the claim is plausibly checked somewhere in the deploy pipeline rather than asserted once.

Everything else is marked optional: the portfolio, post thumbnails, analytics through Google Analytics, Simple Analytics or Umami, comments through Disqus, Commento, Gitalk, Utteranc.es or Giscus, KaTeX for mathematics, a Formspree contact form, Mermaid diagram support, and custom JavaScript and CSS.

The reason this matters is the CSP requirement. The theme is described as compliant to strict Content Security Policy, and strict policies are hostile to inline scripts from third parties. Every optional integration of that kind, an analytics snippet, a comment widget, a custom script, is exactly what a strict policy has to be configured around. Shipping them disabled by default is the only design that makes the strict CSP claim hold without a page of exceptions in every site that uses the theme.

Five comment providers, three analytics providers and a contact form form a lot of optional surface, and the sensible adoption is to turn on the one or two you actually want.

Previewing the theme through its own example site

The theme ships an exampleSite directory, and the README gives the three commands to preview it locally. The trick is the themes directory flag, because the example site lives inside the theme repository rather than beside it:

git clone https://github.com/lxndrblz/anatole.git anatole
cd anatole/exampleSite
hugo server --themesDir ../..

The result is a running Hugo server with the example content, which covers the cases the theme has to handle: posts, a portfolio page, images and thumbnails, a redirect post, tags and categories, and both light and dark appearance.

The same layout applies to the build script in package.json, which builds the example site and then copies the generated resources back into the theme:

    "build": "hugo --themesDir=../.. --source=exampleSite && shx rm -rf ./resources && shx cp -r ./exampleSite/resources ./resources && shx echo Done building resources.",
    "dev": "hugo serve --themesDir=../.. --source=exampleSite",

The resources directory is committed at the root of the repository, and the build regenerates it from the example site, replacing the old one rather than merging into it. That pattern exists because Hugo caches processed resources, and a theme distributed through the themes directory needs those generated files present in the archive.

A developer flow is also defined, with npm run dev starting the same server through the script, and npm run prettier formatting the repository with Prettier and a plugin for Go templates, which matters because the layouts are Go templates and generic formatting rules mangle them.

Conventional commits, husky hooks and release-it

The repository is set up for a disciplined release process, which is a reasonable signal for a theme with a version number that a user pins.

There is a commitlint configuration and a Conventional Commits 1.0.0 badge, so commit messages are checked against the conventional format, and husky is present with a prepare script that installs the git hooks. The dev dependencies make the intent clear: commitlint with the conventional preset, release-it with the conventional changelog plugin, a filter for the conventional commits, husky, Prettier with the Go template plugin, shx for shell commands, and the Netlify Lighthouse plugin.

The release script is release-it, and the changelog is generated from conventional commits, with a CHANGELOG.md at the root of the repository and a .release-it.json configuration. The published versions follow the same pattern: v1.19.0 on 2026-02-28, v1.20.0 on 2026-07-12 and v1.21.0 on 2026-10-11, with the last push to the repository on 2026-10-11 and the package version in package.json matching the newest tag at 1.21.0.

Two smaller details round out the tooling. There is a .devcontainer directory for a reproducible development environment, and a .husky directory for the hooks themselves, and a go.mod file declaring the module path github.com/lxndrblz/anatole with a go 1.12 directive, which is there so that the Hugo module tooling recognises the repository as a module rather than a plain directory.

The documentation lives in the wiki, not in the repository

The README contains a notice that the documentation has moved, and points to the Wiki tab on the repository. That is a small fact with a large practical consequence: the theme's configuration reference is not versioned alongside the theme, so a reader of the wiki is reading the current state, not the state of the tag they have installed.

For a theme with this many optional integrations, the wiki is where the configuration keys live, and that is exactly the part a user needs to consult before deciding which of the five comment providers to wire in. The README tells you the wiki is the place, and the wiki is where the detail lives.

The repository still carries what a developer needs: the archetypes/ directory for scaffolding new content, the config/ directory for the theme's own configuration, i18n/ for translations, layouts/ for the templates, assets/ and static/ for the front-end, images/ for the documentation screenshots, and the exampleSite/ used for both the demo and the tests. There is also a CHANGELOG.md and a CONTRIBUTING.md with contribution guidelines, and the README states that all contributions are welcome, including features, translations, code cleanups, documentation improvements and bug reports.

The theme is maintained by its author, Alexander Bilz, with contributors credited in the repository, and the README asks for a star and a ko-fi sponsorship, which is a reasonable indication of who to direct questions to when the wiki is not enough.

MIT licensing, an active release line and a published theme

Anatole is licensed under the MIT licence, with the licence text linked from the README and the badge in the header, and the package metadata records the same licence. MIT is a permissive licence that allows commercial and modification use, with the obligation to keep the copyright notice in copies and derivatives. That matters for a theme, since sites built on it are derivative works in the ordinary sense and anyone shipping a modified copy needs to keep the notice. Reading the licence file is the right step rather than relying on a summary, and this is not legal advice.

The project is not archived and the release line is active, with three releases in 2026 alone and the newest tag published on 2026-10-11, the same day as the last push. A theme that updates this regularly is a theme whose Hugo compatibility will keep being addressed, and the conventional-commit changelog makes it easy to see what changed between the version you pinned and the version you are considering.

What you are adopting, then, is a small, carefully maintained, two-column Hugo theme whose defining characteristic is restraint: a fast page, a readable column, and a list of integrations you turn on yourself one at a time. The published demo at anatole-demo.netlify.app is the fastest way to judge whether the layout suits your writing before you install anything.

Editorial conclusion

Adopt Anatole if you want a restrained two-column blog or portfolio layout in Hugo and prefer to enable comments, analytics and extras one at a time rather than inherit them from a theme. Skip it if you need a theme that already ships a specific set of integrations, since most of the interesting pieces are optional and off by default, and check the wiki before you commit, because the documentation has moved out of the repository. Verify first that the Hugo version you run builds the example site cleanly with hugo server --themesDir ../.. from exampleSite, and pin the release you use, since the theme ships as a versioned module with v1.21.0 published on 2026-10-11.

Frequently asked questions

Official sources

1. License: MIT
2. lxndrblz/anatole on GitHub
3. Project website
4. README
5. Releases