HugoPress reference site

An editorial flow that ends in a commit

From draft through preview to publish — what the day-to-day editorial workflow looks like when Git sits behind every release.

Eva Křížová Eva Křížová 2 min read
An editorial flow that ends in a commit

Great architecture is worthless if the editorial team hates working in it. That is why we built the HugoPress editorial flow around three simple states.

Three states of an article

  1. Draft — the author writes in the editor, saves whenever, nothing is published.
  2. Preview — one click renders the content and deploys it to a preview site that is identical to production.
  3. Published — approved content is committed to the production repository and a build kicks off.

Preview equals production

Preview runs on the same template and the same pipeline as the live site. What you see in preview is what readers get — no deployment-day surprises.

Publishing as a commit

Publishing does not write to a database; it commits to Git. As a result, every released article has:

  • an author and a commit timestamp,
  • a readable diff (exactly what changed),
  • the ability to roll back to any earlier version.

If the content has not changed, the publish is skipped — no empty commits.

Asynchronous, so it never blocks

The build and push run in the background over a message queue. An editor clicks Publish, gets instant feedback on the job status, and keeps working while a worker finishes the build.

That closes the loop: a comfortable editor at the front, Git in the middle, a lightning-fast static site at the back. The delivery details are covered in Why static sites win on the edge.

All articles
Eva Křížová

By

Eva Křížová

Performance engineer, INTEVIA

Tunes web delivery, measures Core Web Vitals, and believes the fastest query is the one that never runs.

Related articles

Architecture Hugo Headless

Building a headless CMS on Hugo

A classic monolithic CMS bundles authoring, storage and rendering into one running process. That is convenient — until you start caring about performance, security and scaling. The headless approach decouples those three responsibilities, and that decoupling is exactly what HugoPress is built on. Three layers, three responsibilities The editor — authors write in a block editor (Editor.js). The output is clean structured JSON, not WYSIWYG HTML soup. The domain layer — the CMS turns blocks into finished HTML via the BlockRenderingPipeline. The theme itself knows nothing about Editor.js. Delivery — the rendered content is written as content/<lang>/... and committed to Git. Hugo builds a static site from it. The theme does not know Editor.js. All renderers live on the CMS side, which keeps the template dumb, portable and easy to test.

Read more
Performance CDN Hugo

Why static sites win on the edge

When a user opens a dynamic page, the server typically reaches into a database, assembles HTML, and only then replies. On a static site that work is already done at build time — all that is left for the request is to ship a finished file. What you save The database round-trip — gone; the content is already in the HTML. Runtime time — no PHP/Node process on the critical path. Distance — the file sits in a CDN POP a few dozen kilometres from the reader. Measurable impact Metric Dynamic Static on CDN TTFB ~280 ms ~25 ms LCP (median) 2.4 s 0.9 s Cost per request non-trivial ~zero The fastest database query is the one that never has to run.

Read more
i18n Content Hugo

Multilingual the painless way

Multilingual support is a source of pain in most systems — duplicated templates, drifting translations, broken links between languages. Hugo handles it surprisingly elegantly, and HugoPress only smooths a few rough edges. One layout, two languages The section data lives in each page’s front matter; the layout is shared. The same layouts/blog/list.html template reads .Params.* and renders both the cs and en variant — no duplicated logic. Pairing via translationKey Give both versions the same translationKey:

Read more