How ser1.net is built

By Sean E. Russell on Sep 7, 2025 on Permalink.

Some thought goes into putting together web sites, and ser1.net is no different. There are some philosophies beyond “put up a website”, and if it was worth the effort of doing it, it’s worth documenting.

ser1.net is a statically generated site; this means that the content is processed when it changes, and the resulting files are served up by the most trivial of web “GET” requests – as opposed to having some server-side process dynamically generating content on every request. There are many solutions for static generation; my stack happens to be:

Caddy, which does the actual serving of content. It may very well be the best web server available.
Gozer, an extremely simple but fast site generator. I use my fork, which has a bunch of patches which are slowly working their way (or not) through the upstream merge process.
Gozer-Tufte, which is a Tufte theme I cribbed from the Hugo Tufte theme. It started as a straight fork; in the end, I retained only the CSS, which came from Tufte CSS. Still, Hugo Tufte was the inspiration.
Mercurial, for version control

That’s it. The entire site is CSS & HTML; there’s no Javascript, and all interactivity is done entirely in CSS. My photo gallery is a self-hosted web application, Photoprism, which does use a lot of Javascript. That’s because Javascript isn’t needed, and Javascript is the single biggest cause of bloat on the web. It’s hard to provide an online banking experience without JS, but most of the web could do just fine without it, and save a whole lot of bandwidth and consumer CPU cycles in the process.

Graphics are SVG or JXL, as appropriate except for all the photography in Photorism. That’s because these are W3C web standards, and are good, enabling, patent-unencumbered standards.

I used to use Hugo, but I had to switch when it acquired a terminal memory leak which – AFAIK – is still unfixed.

Workflow

One of the first things I did after switching to Gozer was send in a PR for Djot support. Djot is similar to Markdown, except that it isn’t broken. Most of my posts had been written in Markdown, but now I’m using Djot exclusively. In the migration to Gozer, I made a number of changes to the software so that I didn’t have to completely restructure the 150-some files that make up my content. I send these changes to upstream as patches, but since I want to use the changes, I keep a fork with all of my changes applied and use that.

If I want to add a new top-level page, I just create a new <page>.dj at the top level, add whatever content and push it out. For blog entries, I have a utility script that makes creating and editing entries a little easier: it takes a title and turns it into a clean filesystem name, updates or creates the blog entry timestamp, and pushes the changes out to the site. There’s nothing that isn’t easily done by hand, but it automates 4 or 5 commands down into one.

when i’m done with changes, i commit them to a mercurial repository mercurial being the superior version control system and then push that to sourcehut. then i notify the web server that there are changes – this is done via sending a “publish” message to a topic in my self- hosted ntfy instance; on the server, a script is running listening for these messages which pulls the changes and updates the clone on the server. gozer is also running on the server, in watch mode, and when it sees file changes, it rebuilds the site. A rebuild usually takes about a second on my VPS

2025/09/07 13:25:23 [INFO] Built 151 pages in 495 ms
2025/09/07 13:45:30 [INFO] Built 151 pages in 951 ms
2025/09/07 15:09:17 [INFO] Built 151 pages in 1167 ms
2025/09/07 15:09:18 [INFO] Built 151 pages in 418 ms

So. Much. Work.

There are quite a few moving parts, but looks more fussy than it is, and it evolved over time.

I’ve been running Caddy forever, so that’s really a gimme.
I’ve been running ntfy for a long while, as I use it for Android notifications.
Gozer was new, but using it is just running gozer watch in the clone on the server.
All content is just djot, edited with a plain text editor; it’s like writing an email in 1995.

The hardest part of all this for me is getting the site to look decent, because I’m not a web developer and touch CSS maybe once every 5 years.

Here’s the ntfy script that updates the web site:

#!/usr/bin/zsh

curl -N -s -u "user:passwd" https://ntfy.ser1.net/publish-topic/json | \
  while read -r line; do
    msg=$(<<<"$line" jq -r .message)
    if [[ "$msg" == "publish" ]]; then
      hg pull
      hg up
    fi
  done

and I just curl -d 'publish' -u "user:passwd" "https://ntfy.ser1.net/publish- topic" to trigger the publish event. This is all far, far easier than using a CMS, and believe me, I know CMSes. It’s probably the main reason I’m doing things this way.

The blog script is far more complicated, at 110 lines of bash, because it’s converting text, doing replacements, and checking timestamps to determine if it’s a new post or an update. But, again, it’s just a convenience script.

My point is, you don’t have to boil the ocean, and sometimes it’s better to do things piecemeal; the result is often more decoupled, and decoupled means interchangeable. I could (and have) replace any individual piece with a different technology without affecting the rest. For example, replacing Hugo with Gozer required only replacing Hugo with Gozer. Caddy, Mercurial, and ntfy all stayed the same, and required no change at all.