Example: a smaller architecture for a lasting technical blog

A technical blog has an unusually friendly workload: its content changes much less often than it is read. That makes it a good candidate for doing the expensive work once, at build time.

Move computation to the build

Markdown becomes HTML, syntax is highlighted, images are optimized, and search indexes are generated before deployment. Readers receive files rather than waiting for an application server to compose a response.

flowchart LR
A[Versioned Markdown] --> B[Astro build]
B --> C[HTML and optimized assets]
C --> D[Pagefind index]
D --> E[Cloudflare Static Assets]
E --> F[Reader]

Make dependencies explicit

{
  "rendering": "static",
  "content": "version-controlled",
  "search": "browser-local",
  "database": false
}

A dependency is an operational commitment. Static hosting removes database backups, application server patching, and request-time rendering from this particular system. It does not remove the need to maintain the build toolchain.

Design for failure

The content remains readable when JavaScript is disabled. If the search index cannot load, readers can use the article index. Comments are optional and never block article rendering.

Keep deployment boring

The build artifact is a directory of files. A successful build should also validate links, metadata, draft exclusion, and the custom error page. Git history remains the source of truth for recovery.

See Astro’s documentation and the Cloudflare static asset documentation for current platform details. The testing example explains what to check before publication.