And how I stopped worrying and learned to love static files

I didn’t pick Hugo because I woke up one day craving for more YAML in my life. I picked it because I was tired of the “simple website” spiral that somehow ends with:
a database, a CMS, 42 plugins, and a server that needs patching like it’s running payroll.

All I wanted was a personal site. Some posts, a few projects and a place to write (grandma’s recipes are coming – just wait). Something I could version like code, deploy like a service, and forget about like a well-behaved process running quietly in the background.

So I went static and found Hugo.

The Short Story

Laptop open. Coffee on the left. Terminal on the right. Domain name pointed at a VPS that doesn’t care about my feelings.

I want a site that behaves like my infrastructure:

  • Files I can read
  • Builds I can reproduce
  • Deploys I can automate
  • Zero runtime surprises

I run hugo new site, add a theme, start the dev server — and suddenly I’m staring at something that feels engineer-native.

Content is Markdown. Layouts are templates. Config is a file. Output is a folder full of plain HTML, CSS, and JS.

No magic. No platform. No “click here to upgrade your plan.”

Just files I own.

That’s when it clicked: this wasn’t a website builder — this was a build system for content.

What Hugo Actually Is

No Marketing noise here, I am not associated or related with the project by any means … Hugo is a static site generator written in Go, originally created by Steve Francia and now led by Bjørn Erik Pedersen (you’ll often see him as bep in the repo and docs).

The official site doesn’t try to be subtle about its main feature:

“The world’s fastest framework for building websites.”

And honestly? For once, that claim holds up.

Hugo is open source under the Apache 2.0 license, which means I can use it for personal, commercial, or professional work without worrying about licensing drama.

Why I Actually Stuck With It

1. Speed Changes How You Work

Hugo builds fast enough that I don’t hesitate to experiment.
Edit. Save. Refresh. Repeat.

Real life, right in your face (benchmark what? it’s just logs, dude):

hugo-1  | Change detected, rebuilding site (#8).
hugo-1  | 2025-12-12 14:22:26.148 +0000
hugo-1  | Source changed /blog/why-hugo.md
hugo-1  | Web Server is available at http://localhost:13000/ (bind address 0.0.0.0)
hugo-1  | Total in 21 ms

I don’t think my brain can reload faster than 21 ms, so we’re good. 😄

When builds takes ms instead of minutes, you stop treating your site like a fragile artifact and start treating it like a living project.

2. The Go Binary Life

One executable. That’s it.

No Node stack. No Python virtualenv. No runtime dependency soup.
It runs on my laptop and on my Linux VPS the same way, which scratches my “production parity” itch in a very satisfying way.

3. Content Feels Like Code

My site lives in Git.
I version posts.
I diff layout changes.
I can roll back a bad deploy like it’s a broken release.

That alone makes it feel more like my system than my profile page.

4. Hosting Is Boring (In a Good Way)

Static files don’t crash.
Nginx doesn’t care about my theme choices.
My VPS just serves bytes and lives a peaceful, uneventful life.

This is the kind of infrastructure I trust.

The Honest Parts (Because No Tool Is Perfect)

Let’s be real.

Hugo Templates Will Humble You

If you’ve never touched Go templates before, there will be a moment where you stare at {{ . }} and think:

“Why does this dot know everything about my site?”

The power is there — but so is the learning curve.

Themes Are a Double-Edged Sword

They’re great until you customize them heavily.
Then you update them and suddenly you’re doing a three-way merge with your past self and upstream.

Static Doesn’t Mean Simple — It Means Shifted Complexity

Comments? Search? Forms? Analytics?
You’re integrating third-party services or building your own.

Personally, I prefer that trade: fewer moving parts on my server, more control in my architecture.

My Build-and-Deploy Setup (Short and Functional)

This is the part I love most: the workflow feels like a real delivery pipeline, not a “publish” button.

Local Machine (Build Side)

  • Install Hugo
  • Write content in content/
  • Customize layouts/themes
  • Run the local dev server for preview
  • Build production output into public/

VPS (Serve Side)

  • Plain Linux box
  • Nginx (or Caddy)
  • Web root points to where public/ lives

Deploy Flow

  1. Build locally → public/ folder is generated
  2. Sync it to the server (rsync/scp/CI pipeline — your call)
  3. Nginx serves it instantly

No app restarts.
No migrations.
No “did you clear the cache?”

Just files replacing files.

Which, from an infrastructure perspective, is about as trustworthy as it gets.

Real Humans Behind the Project

Hugo didn’t come out of nowhere.

  • Dan Hersam, one of Hugo’s early contributors, has a fantastic talk where he basically turns Hugo’s build speed into a live benchmark:

  • The project is actively maintained by Bjørn Erik Pedersen and a large community of contributors on GitHub:
    https://github.com/gohugoio/hugo/graphs/contributors

This isn’t a “dump it on GitHub and vanish” project — it’s very much alive.

Supporting Open Source (The Non-Dramatic Way)

Open source runs on three things: time, attention, and maintenance.

If you use Hugo (or any project like it), a few real ways to give back:

  • Sponsor maintainers if you can
    https://github.com/sponsors/bep
  • Fix a typo in the docs (seriously, high impact)
  • Write good bug reports with minimal repro cases
  • Help someone in Discussions or Issues

You don’t have to become a core contributor to be part of the ecosystem. Just be a good citizen.

Why I Stayed

Hugo didn’t just give me a website.

It gave me a workflow I trust:

  • Build locally
  • Ship artifacts
  • Serve static
  • Sleep peacefully

Sometimes I wrestle with templates. Sometimes I over-engineer a layout change like it’s a production service rollout. But the payoff is worth it: my site stays fast, cheap to host, easy to version, and completely mine.

And my VPS has never once tried to upsell me a “Website Builder Pro Plan.”

Which, honestly, might be the most underrated feature of all.