Hugo

Last reviewed Aug 25, 2026 · 660 words

Hugo builds this-sized websites in milliseconds — a thousand pages in about a second — and outputs plain HTML files that any web server can host with zero runtime, zero database, and zero security patches, which makes it the self-hosting choice that removes an app from your maintenance list instead of adding one. WordPress needs updating forever; a Hugo site is inert files behind Caddy. The trade is upfront: you write Markdown in an editor and run a build, and the template system will make you think.

Speed is a behaviour change, not a benchmark

The single-binary install (hugo from your package manager, no Node, no dependency tree) and the millisecond builds sound like trivia until you experience the feedback loop: hugo server rebuilds and refreshes the browser faster than you can alt-tab, for every edit, at any site size. Static-site friction is what kills blogs — when preview takes 30 seconds, drafting moves to Google Docs and never comes back. Hugo removes that excuse with such margin that site size stops being a consideration for the rest of your writing life; this directory's 50,000-page build philosophy runs on the same insight.

The honest part: templates are the learning curve

Hugo's templating is Go's html/template — powerful, fast, and initially cryptic ({{ range .Pages }}, dot-context confusion, partials). The catalogue's "learning curve" con is this, and the way through is to not start from scratch: pick a maintained theme (PaperMod and Blowfish are the safe modern defaults among the thousands available), add it as a git submodule or Hugo module, and write content for a month before touching a template. When you do customise, Hugo's lookup order lets you override a single file from the theme by shadowing its path in your own layouts/ — you almost never fork a theme, just eclipse the pieces you want changed. Archetypes, shortcodes, and taxonomies each earn learning when a need appears; front-loading them is how people burn out in week one.

Content model worth adopting on day one

Two habits prevent later regret. Use page bundles — each post as a folder (content/posts/my-post/index.md) with its images beside it — so posts are portable, self-contained units and image references never break. And set the site's URL structure (permalinks config) before publishing anything, because changing URLs later is an SEO project with redirect obligations, while choosing /posts/:slug/ on day one is free. Front matter stays minimal: title, date, description, tags — the same discipline as any content system you own, with everything in plain files a future you can migrate with cp.

Deployment: the pipeline is the server

The output is a public/ folder of static files, so "deployment" means copying files — and the mature setup makes that automatic: the site's source in a Gitea or GitHub repo, an Actions workflow running hugo --minify on push, and the result rsynced to your box where Caddy serves it (two lines: the site block plus file_server). Total server attack surface: a web server serving files. Total server maintenance: none — updates to Hugo happen at build time, on your schedule, and the deployed site can't be out of date or vulnerable because there's nothing running. Add Umami or Plausible for analytics and the whole stack stays honest about its privacy story.

What I'd do

Hugo binary, PaperMod as a module, page bundles, permalinks decided, ten posts written before any template customisation, then the git-push-to-deploy pipeline and never think about the mechanism again. The steady state is the best in self-hosting: a site that costs nothing to run, can't break while you sleep, builds in under a second, and keeps every word in Markdown files you'll still own when the next platform dies.