I’ve slowly grown to realize there’s some software you just don’t need to update. A static site generator (almost certainly) won’t have security issues as long as you control the input and the output is just a bunch of static files.

Unless the new version of the software includes some feature I need, I can be totally fine just running an old version forever. I could just write down the version of the SSG my site builds with (or commit it to source control) and move on with my life. It’ll work as long as operating systems and CPU architectures/whatever don’t change too much (and in the worst case scenario, I’m sure the tech exists to emulate whatever conditions it needs to run) Some software is already ‘finished’ and there’s no need to update it, ever.

How about specifying a version in the CI config? [0]

Also, you know that you can do a binary search for the version that works for you? 0.154.0, 0.77.0, 0.115.0 ... (had to do it once myself)

[0]: https://github.com/oslc-op/website/blob/9b63c72dbb28c2d3733c...

If you use an off-the-shelf binary for any tool, you can put the binary in `${project}/bin/`, add it to `.gitignore`, document the download URL in `README.md` or an install script, and commit the checksum in a project-wide `SHA256SUMS` file (or `B3SUMS`, etc.). It's like a lo-fi version of Git LFS.

I "solved" this issue by using a custom Docker image, both for writing/serving content locally, and for the CI.

So I have a fixed Hugo version that I know works.

And when I mean "solved", I actually never had the issue because, since I have no reason to upgrade Hugo, I never had to change my Docker image and never had the opportunity to risk breaking my theme.

I have the same problem with Jekyll. I fixed my website for the Jekyll version I installed when I got this machine (in 2021). I dread the moment when I get a new computer and have to either try to install this particular version of Jekyll or to fix my website again.

I just assumed static website generators would be stable but well, there's always something that breaks. Terrible user experience for someone who just wants to use the generator to generate a website vs. to tinker with it as a hobby.

I'm in the process of porting my website to PHP ... but that project hasn't gone anywhere because currently everything works ;)

I had the same issue and I'm currently thinking whether it's easier to just Vibe Engineer my own static site generator with the exact features I need vs fighting with the hugo theme system.

My needs for a site are pretty simple, so I might just go with the custom-built one to be honest.

If it breaks, I can just go look in the mirror for the culprit =)

I had a similar issue, but with Jekyll. I had a customized theme and some update along the way broke everything. So, I very much agree with a sibling comment about not needing to update static site generators and it’s not just a Hugo thing. Sadly, my site was also being hosted/generated by GitHub, so I had no real choice in the update matter. (I’m not sure if pinning would have helped.)

I recently broke my Hugo blog theme when updating and had to migrate to a whole new theme, it was a pain. From now on I probably won't update it

I moved to a AI maintained custom site generator and it’s ideal for my uses. I have full control over everything and nothing breaks me.

> In theory I could use an old version of Hugo, but I have no idea when it broke, so how far do I go back?

Had the same problem. Binary search is the latest trick people use.

For SSG there's not much point in upgrading if everything works, and planned migration beats the churn in this case.

You can just print a Hugo version in a HTML comment to track it in git.

> I decided to use an off-the-shelf theme, but it didn't quite meet the needs and I forked it; as it so happens Hugo breaks userland relatively often and a complex theme like the one I have requires a lot of maintenance. Like.. a lot.

> Now I can't really justify the time investment of fixing it so I just don't post anymore, the site won't even compile. In theory I could use an old version of Hugo, but I have no idea when it broke, so how far do I go back?

I've had the same issues as you, and yes, I agree that pinning a version is very important for Hugo.

It's more useful for once-and-done throwaway sites that need some form of structure that a static site generator can provide.

> So, advice: submit the binary you used to generate the site to source control. I know git isn't the best at binary files, but I promise you'll thank me at some point.

No need for the entire binary.

Just put `go run github.com/gohugoio/[email protected] "$@"` into a `hugo.sh` script or similar that's in source control, and then run that script instead of the Hugo binary.

You'll need Go installed, but it's incredibly backwards compatible, so updating to newer Go versions is very unlikely to break running the old Hugo version.

> In theory I could use an old version of Hugo, but I have no idea when it broke, so how far do I go back?

Pretty sure the version of Hugo used to generate a site is included in metadata in the generated output.

If you have a copy of the site from when it last worked, then assuming my above memory is correct you should be able to get the exact version number from that. :)

I've been burned by this a few times and now I have the Hugo binary in source control. I had to dig through the releases a little bit to find the version that didn't break everything.

At least it’s practical to identify a specific version to use, and you can be reasonably confident it will work indefinitely. I remember that with the Hyde iteration of my site, somewhere along the way Hyde became impossible to install, and I was stuck with an existing installation, or a lot of effort to put it back together manually. Python packaging has improved a lot since then, so that I doubt that problem would apply on any new project, but it’s still far more plausible than in a language like Go or Rust.

I maintained a personal fork of Zola for my site (and a couple of others), and am content to just identify the Git repository and revision that’s used.

Zola updates broke my site a few times, quite apart from my patches not cleanly rebasing. I kept on the treadmill for a while, initially because of a couple of new features I did want, but then decided it wasn’t necessary. You don’t need to run the latest version; old is fine.

—⁂—

One piece of advice I would give for people updating their SSG: build your site with the old and new versions of the SSG, and diff the directories, to avoid regressions.

If there are dynamic values, normalise both builds before diffing: for example, if you have timestamp-based cachebusting, zero all such timestamps with something like `sed -i 's/\?t=[0-9]+/?t=0/' **/*`. Otherwise regressions may be masked.

I caught breakages a couple of times this way. Once was due to Zola changing how shortcodes or Markdown worked, which I otherwise might not have noticed. (Frankly, Markdown is horrible for things like this, and Zola’s shortcodes badly-designed; but really it’s mostly Markdown’s fault.)

Sorry to hear it. Always sucks to not be able to tweak your own site.

I’ve had amazing success debugging compile errors with Claude Code.

Perhaps a coding agent could help you get it going again?

> advice: submit the binary you used to generate the site to source control.

Or use HVM and submit the .hvm file (which is just a text file with the Hugo version that you use)

What kind of issues? I use my own private theme called Brahma which I wrote from scratch. I keep it simple and has been since 2019. I have barely had any issues.

Given, mine is not sophisticated at all and simple by design. But curious what kind of issues pops up.

Run Hugo in Docker; in that instance, rolling forward/back is as easy as changing the tag in your Docker image.

Why not go back to the version that your last post was published at, and stick with it?

I'm on your side.

Nobody can point to a reason why it's a good idea for a site with any interactivity now.

All the supporters here are all the same: "I had to do a whole bunch of mental gymnastics and compromises to get <basic server side site feature> but it's worth it!" But they don't say why it was worth it, beyond "it's easy now <after lots of work costs sunk>".

When you try get to why they did it in the first place, it's universally some variation on "I got fed up with <some large server side package> so took the nuclear SSG route <and then had to eventually rewrite or get someone else's servers involved again>"

Part of this is a me problem: a personal website should be owned by the person, IMO. A lot of people are fine to let other people own parts of their personal websites, and SSGs encourage that. What even is a personal website if it's a theme that looks like someone else's, hosted and owned on someone else's server - why not just use Facebook at that point?!

Sounds like a job for Claude Code to me.

It may be worth considering whether you need a native binary (and the ability to run it) for the job at all. A static site generator doesn't need to do anything that browsers from the last 10 years can't do; a static site generator is fundamentally a classic batch processing job that takes a collection of (mostly plain text) files as input, processes it, and then outputs something else (in this case, a collection of post-processed content for the site).

If you encode the transformations that your desired SSG should perform by writing the processing rules as plain text source code that a browser is capable of executing (i.e., an "HTML tool" or something adjacent[1][2]), then you can just publish this "static site generator" itself as yet another page on your static site.

To spell it out: running the static site generator to create a new post* doesn't need to involve anything more than hitting /new.html (or whatever) on the live site, clicking the button for the type=file input on that page, using the browser file picker to open the directory where the source to your static site lives, and then saving the resulting ZIP somewhere so the contents can be copied to whatever host you're using.

1. <https://simonwillison.net/2025/Dec/10/html-tools/>

2. <https://crussell.ichi.city/pager.app.htm>

* in fact, there's nothing stopping you from, say, putting a textarea on that page and typing out your post right there, before the new build