Static Delivery for a Zero-Idle Research Site

Problem and context

A research library is read far more often than it is written, and it may sit untouched for weeks between publications. Paying for idle compute to serve a handful of HTML documents is exactly the kind of standing cost this project exists to avoid. The delivery model therefore has one hard requirement and two soft ones:

• Hard: cost trends to $0 when no one is reading.
• Soft: publishing is a single, reproducible CI step.
• Soft: the build has as few moving parts as possible.

The model

The site is a classic static-origin CDN topology: an S3 bucket holds the rendered output, and a CloudFront distribution terminates TLS, caches at the edge, and reaches the bucket through an Origin Access Control so the bucket is never public.¹

The whole topology is one reusable Terraform module, instantiated per site:

Why not a server

A small VM or container would be simpler to reason about, but it violates the hard requirement: it bills whether or not anyone reads. Static origins invert that — you pay for bytes stored and bytes served, both of which go to zero at idle.²

The approach: deploy-by-pivom

The interesting part is publishing. The CI pipeline does not hard-code the bucket name. Instead it resolves the deployment target at run time from the site’s domain, a pattern referred to internally as deploy-by-pivom:

1. Terraform provisions (or confirms) the bucket and distribution.
2. A resolver step maps research.prosyon.ca → the concrete bucket name and exports it to the job environment.
3. The build artifact is uploaded to that bucket.

Decoupling the publish step from a literal bucket name means the same workflow publishes any domain the resolver knows about, and renaming or recreating the bucket never requires editing the pipeline.

Implementation: a pure-Hugo build

The original placeholder build shelled out to an “under construction” action. Replacing it, the design choice that mattered most was eliminating Node from the build. The codex theme is written in vanilla CSS and uses Hugo Pipes for concatenation, minification, and fingerprinting³ — so there is no Tailwind step, no npm install, and no package.json to keep in sync.

The build collapses to one hermetic command:

# Render content/ + themes/codex into www/public/
hugo --source www --minify --gc

That single binary invocation honors the build/release/run separation cleanly: the build stage produces an immutable artifact, and the release stage only moves bytes.⁴

Cache and invalidation

CloudFront caches aggressively at the edge. Because CSS and JS assets are fingerprinted (their filename contains a content hash), a new build emits new asset URLs and the old ones simply age out — no asset invalidation needed. Only HTML documents require a targeted invalidation on publish.

Trade-offs

• No server-side anything. Search, comments, and dynamic features must be client-side or delegated to a separate service. For a document library this is acceptable, even desirable.
• External DNS. Apex records point at CloudFront via ALIAS/ANAME; the certificate flow this implies is its own subject (WP-003).
• Cold author experience. Publishing requires a CI round-trip rather than a live edit. The reproducibility is worth the latency.

Summary

Static origin, edge cache, private bucket, and a one-command build give a site that is cheap to run, boring to operate, and impossible to leave in a half-deployed state. The only standing cost is storage measured in megabytes.