Site Build

Building This Site with Astro and Cloudflare Pages

Notes from standing up this lab notebook: Astro for the static site, Markdown for durable content, GitHub Actions for deployment, and Cloudflare Pages for hosting.

3 min readSeries: Site Build
AstroCloudflarePublishingAutomationWebsitesSite Build
Blue-toned workspace representing a static site publishing pipeline

I finally carved out a proper home for project notes: a small Astro site that behaves like a lab notebook first and a polished website second.

The goal was not to build a complicated application. It was to make publishing frictionless enough that cybersecurity notes, AI experiments, electronics builds, 3D printing logs, and cosplay work-in-progress posts can all live in one place without needing a CMS ceremony every time I want to write something down.

The shape of the site

The site is intentionally static. Astro builds HTML from Markdown and MDX, then Cloudflare Pages serves the generated files globally.

The important pieces are:

  • Markdown content collections for blog posts and projects.
  • Frontmatter for summaries, dates, tags, series, canonical links, featured images, and crosspost hints.
  • Generated routes for the home page, blog index, projects, tags, archives, RSS, and sitemap.
  • Minimal client-side JavaScript unless a page actually needs it.

That gives me a fast public site while keeping the source of truth in Git.

Why Astro

Astro is a good fit for this kind of site because most pages are content, not app state. The site can stay mostly static, but still leave room for MDX, custom components, syntax highlighting, and later integrations.

I started from the Pulsar theme as a visual baseline, then reduced it toward a darker, blue-toned lab-notebook style. The result is still simple, but it has the structure I need: posts, projects, archives, tags, RSS, SEO metadata, and room for long-form technical notes.

Deployment path

The deployment setup took a little more iteration than expected because Cloudflare’s interface currently blends some Worker-first language with Pages projects.

The final working model is simple:

  1. Build the site with npm run build.
  2. Let GitHub Actions run Wrangler.
  3. Deploy the generated dist directory to Cloudflare Pages.

The Pages project is the host. GitHub Actions is the deployer. Cloudflare’s own Git-connected build is disconnected so there is only one deployment path to debug.

The live Pages URL came up first, and the custom domain can be attached separately once DNS finishes updating.

AI-friendly publishing

A second design goal was making the site friendly to AI-assisted drafting without letting automation become the architecture.

Each post is just a file. The frontmatter is explicit enough that an agent can generate useful drafts consistently:

  • title
  • summary
  • date
  • tags
  • category
  • series
  • featuredImage
  • canonicalUrl
  • crosspost

That means I can turn a rough prompt or structured JSON into a draft, review it locally, and commit it like any other change.

The crossposting metadata is deliberately only metadata for now. Actual posting to LinkedIn, Bluesky, Mastodon, or anything else belongs behind a separate integration boundary with proper secrets handling.

What this unlocks

The best part of this setup is that it lowers the activation energy for writing.

A bench electronics experiment can become a project log. A security rabbit hole can become a post. A 3D print failure can become a tagged note instead of disappearing into chat history. The site does not need to be perfect before it is useful; it just needs to make capture, review, and publishing repeatable.

That is the real purpose of the build: a durable place for the work to accumulate.