Infrastructure

Serving a CMS-driven site as static: our Firestore + Astro pipeline

Editors work in a CMS backed by Firestore; visitors get plain static HTML with no client-side data fetch. Here is how we get the SEO and speed of static generation without giving up a live editorial workflow.

Chaiwat S.

Fetch at build, not in the browser

The core idea is simple: content lives in Firestore, but we read it once at build time and bake it directly into the HTML. Visitors never touch the database, so there is no client SDK to ship, no API keys exposed in the browser, and no loading spinner. Each detail page is prebuilt from its CMS entry, which is excellent for both SEO and time-to-first-paint.

Keeping content fresh

The tradeoff of static generation is that new content appears only after a rebuild. We trigger builds on code push and on a schedule, so edits made in the CMS surface automatically without anyone running a deploy by hand. For most marketing and editorial content, a short delay is a perfectly acceptable price for serving a database-free site.

Failing safe

Build-time fetches can fail — a network blip or an empty collection should never break a deploy. Every fetch falls back to bundled defaults, so the worst case is a page that renders last-known content rather than a failed build. Treating the database as an enhancement rather than a hard dependency keeps the pipeline resilient.