CMS for Hugo: Add a Real Editor to Your Static Site

Hugo is the fastest static site generator around — it builds thousands of pages in the time other tools take to warm up. But Hugo's speed comes from a rigid model: content is markdown files with front matter, sitting in your repo. That's perfect until a client, a marketing teammate, or a writer who doesn't use git needs to publish. Then the friction shows.

The fix is a headless CMS feeding Hugo at build time. This post shows how to connect one, what the tradeoffs are, and why a self-hosted content layer suits Hugo developers who already value owning their stack.

Two ways to give Hugo a CMS

There are two honest paths, and they solve different problems:

Git-based CMS (Decap, Sveltia): edits commit markdown back to your repo. Hugo keeps reading files. Simple, but non-developers still deal with a git-shaped workflow, and you're limited to what fits in front matter.

Headless CMS: content lives in a database with a real admin UI and an API. Hugo fetches it at build time. More setup, but you get a proper editor, media library, scheduling, and roles — the things that matter once real people edit.

This post focuses on the headless path, because that's where teams end up when markdown-in-repo stops scaling.

Fetching CMS data into Hugo

Hugo reads external data through its data templates and resources.GetRemote. You call your CMS API during the build and loop the JSON into templates.

{{ $url := "https://cms.yoursite.com/api/v1/posts?per_page=100" }}
{{ with resources.GetRemote $url }}
  {{ $data := .Content | transform.Unmarshal }}
  {{ range $data.data }}
    <article>
      <h2><a href="/blog/{{ .slug }}/">{{ .title }}</a></h2>
    </article>
  {{ end }}
{{ end }}

For full per-post pages, a common pattern is a small build script that pulls the API and writes markdown files into content/, letting Hugo do what it's fast at. Either way, the CMS is the source and Hugo is the renderer.

Why self-hosted headless fits Hugo

Hugo developers pick Hugo partly to avoid platform lock-in and runtime dependencies. A SaaS CMS with metered API calls and vendor-controlled data reintroduces exactly what Hugo helped you escape.

UnfoldCMS is a self-hosted CMS that fits this instinct: it runs on your own server, stores content in your own database, and exposes a REST API at /api/v1/*. Build-time fetches don't cost per request, and nobody can deprecate your content platform out from under you.

For Hugo specifically:

• REST, no GraphQL — plain endpoints you hit from a build script or template.
• No client library — nothing to add, nothing to version-pin. Hugo's GetRemote or a curl in a script is enough.
• Pay once, self-host — a fast Hugo site that rebuilds constantly won't run up an API bill.

Rebuild-on-publish with webhooks

Static sites go stale. An editor hits publish; Hugo's last build doesn't know. You need a trigger.

UnfoldCMS sends an outgoing, HMAC-signed webhook on publish, update, and delete. Point it at your host's deploy hook:

Editor publishes
  → CMS fires signed webhook
  → Netlify / Cloudflare Pages / your CI rebuilds Hugo
  → Fresh site live in seconds (Hugo is fast)

Hugo's build speed shines here — a webhook-triggered rebuild finishes almost instantly even on large sites, so publishing feels near-live despite being fully static. The HMAC signature lets your endpoint reject anything that isn't genuinely from your CMS.

Hugo CMS options compared

The right choice depends on who edits. Solo and git-comfortable? Stay on files. A team with writers and clients? A headless CMS with a real editor pays off.

What you give up

No sugarcoating:

• A build step in the loop. Content lives in the CMS, not the repo, so previewing changes means a build or a preview route. Git-based CMS keeps everything in-repo; headless trades that for a better editor.
• No revision history. UnfoldCMS doesn't keep past versions of a post. If you need to roll back copy, that's on your git history of exported content, not the CMS.
• Server to run. Self-hosting is yours to patch and back up. The upside is total control; the cost is the ops.

FAQ

Can Hugo pull content from a headless CMS at build time? Yes. Use resources.GetRemote in a template, or a build script that fetches the API and writes markdown into content/. Both work with UnfoldCMS's REST API.

Git-based or headless CMS for Hugo — which is better? Git-based is simpler and keeps content in your repo; best for developer-heavy teams. Headless gives a real editor UI, media library, and scheduling; best once non-developers publish regularly.

Does UnfoldCMS have a Hugo integration package? No official package. You call the REST API from a build script or Hugo template. That keeps the integration dependency-free.

How does the site update after an edit? An outgoing webhook from the CMS triggers your host to rebuild Hugo. Because Hugo builds fast, the site refreshes almost immediately.

Bottom line

Hugo + a self-hosted headless CMS keeps Hugo's speed and your ownership while handing non-developers a real place to publish. Fetch content at build time, trigger rebuilds with a webhook, and accept that you're adding a build step and a server in exchange for a proper editor. For a team that outgrew markdown-in-repo, that's a fair trade.

Try the live demo or read Hugo vs WordPress for the bigger picture.

Related: Headless CMS for Jamstack · Hugo vs WordPress · Markdown vs CMS for docs