Hugo on /var/log/janio

Hugin on steroids: tags, links and editing in one TUI

Sat, 18 Apr 2026 13:13:00 +0000

In the post about Hugin I introduced the tool I use to generate tags and summaries for my Hugo blogs. Two weeks later, in the post about Munin, I showed its sibling: a second program that discovers and inserts internal links between posts using embeddings and an LLM.

Both worked well. Separately, they worked well.

The problem with having two programs

In theory, splitting responsibilities between tools is good practice. In practice, the workflow for processing a new post looked like this: open Hugin, navigate to the post, generate tags, generate summary, close Hugin. Open Munin, wait for the embedding model to load, navigate to the same post, check existing links, generate link suggestions, apply. If you needed to fix a typo in the title that only showed up after reviewing the post in Hugin, close everything and open Pages CMS or vim.

Hugin: tags and summaries for Hugo with AI

Fri, 17 Apr 2026 11:06:00 +0000

Anyone who maintains a static blog with Hugo knows there are two tasks nobody enjoys: classifying posts with tags and writing meta descriptions. These are the things you skip when publishing because the post is already done, the deploy is set up, and choosing between “selfhosted” and “self-hosted” isn’t exactly the best use of your time. The result is predictable: posts without tags, empty descriptions or ones copied from the first paragraph, and a taxonomy that hurts more than it helps.

Munin: internal links for Hugo with AI

Fri, 17 Apr 2026 10:49:00 +0000

In the post about Hugin I explained how I solved the tag and summary problem on my Hugo blog. But there was another problem, less obvious and more annoying: internal links. Those links that connect one post to another, help readers navigate related content, and that Google loves to see on a well-structured site.

The truth is nobody links anything. You write a post about systemd timers, another about cron, another about launchd — and none of the three mentions the others. They’re content islands that could be connected. The obvious solution is to reread every post, remember which others exist, and manually insert links. With 30 posts, it’s doable. With 400, it’s insane.

From WordPress to Hugo: Theming Is Not What You Think

Sat, 04 Apr 2026 15:20:00 +0000

Anyone who has worked with WordPress long enough develops a strong intuition for what a theme is and what it does. That intuition serves you well within the ecosystem: it guides decisions about file structure, where to put logic, and how to extend functionality. The trouble starts when you move to Hugo and try to apply the same mental model. The vocabulary overlaps — templates, layouts, partials — but what those words mean in practice is radically different.

The Dark Side of Free Website: Limits and Alternatives for Hugo + GitHub + Cloudflare Pages + Pages CMS

Tue, 24 Mar 2026 10:45:00 +0000

In a previous post, we put together a complete blog with Hugo, GitHub, Cloudflare Pages, and Pages CMS without spending a cent. The stack works, it is fast, and for most personal blogs it will keep working for a long time without asking anything in return. But “free” does not mean “without limits,” and understanding where the walls are before you hit them is the kind of thing that saves headaches down the road.

Comments on static sites with Isso — lightweight, self-hosted, and tracking-free

Sat, 21 Mar 2026 00:00:00 +0000

A static site has no backend. No database, no application server processing requests — and that’s exactly what makes it fast, cheap, and resilient. But that simplicity comes at a cost when you need anything that depends on persistent state, and comments are the most obvious case. In WordPress or Ghost, the commenting system is part of the application. In a site generated by Hugo, Jekyll, or Eleventy, that layer simply doesn’t exist.

Why leave WordPress — and what to build instead with Hugo, Pages CMS, and Cloudflare

Fri, 20 Mar 2026 00:10:00 +0000

Why leave WordPress

The weight of running a dynamic CMS

WordPress is an extraordinary piece of software that powers nearly half the internet. That said, keeping a WordPress installation healthy is a job that never ends. Every visit to your site triggers a chain of events: the server receives the request, PHP wakes up, queries MySQL, assembles the page on the fly, and sends the HTML back to the browser. Multiply that by a hundred simultaneous visitors and you have a server sweating to deliver pages that, on most blogs, are exactly the same for everyone.