Skip to main content
Back

Why I Chose Astro and Cloudflare Workers for this Blog

·
building-in-publicastrocloudflare

I’ll be up-front: my initial plan for this site was to use Nextjs and Payload CMS. I’ve been a fan of Nextjs for years and Payload quickly won me over. That pairing has become my default for new projects. I still think they’ve both terrific, but the news of Cloudflare acquiring Astro caught my eye and tipped the scale. I had been wanting an excuse to learn Astro and this seemed like the right moment and an excellent project fit.

Before I get into Astro/Cloudflare details, let’s step back and talk through some of the ideas behind my choices.

The principles behind this build

Here’s what I considered before committing to a build plan

Content first, shiny second

Initial design descisions should support readability and a solid UI foundation. There will be time for polishing visual expression, adding atmosophere and interactivity, but that comes later. Minimal time investment to stand up the site will give me more space for thinking and writing.

Low maintenance platform & workflow

Whatever I build needs to be something I can return to after weeks away and not miss a beat. Intuitive file structures, obvious naming, minimal abstraction. As self-documenting as possible on my end. And when I do need to create/revise documentation, it should be easy to use AI assistants to review code and content.

Ticks all the Lighthouse boxes

Performance, Accessibility, SEO. I don’t want to over-index on optimizing KPIs just for their own sake, but I do want to consider all of these as through-lines from the beginning, not something to come back to at a later phase of work.

Sandbox for experiments

This is potentially at odds with some of the above, but when I see an interesting new library I’m curious to try it out, I want to minimize worrying about adapting it to my stack.

Why Astro

So how does Astro map to those principles? Pretty well, as it turns out.

Content first: static by default.

Astro renders to static HTML out of the box. No server thinking about my content on every request, no client-side JavaScript unless I explicitly opt in. The “islands” architecture lets me add interactivity per component when I need it, but the default is zero JS shipped to the browser. For a content site, that’s a strong starting point.

Low maintenance: content collections and Markdown in the repo.

Astro has a built-in system for defining, validating, and querying structured content. I define a schema in TypeScript, write posts as MDX files with frontmatter, and get type-safe access throughout. No external CMS, no database, no API layer — just files in a folder with a contract. The content lives in the repo, the workflow is Git, and the whole thing is portable. Writing MDX in Cursor alongside Claude Code feels like a natural workflow — exactly the kind of AI-friendly setup I was after.

Lighthouse-friendly by nature.

Static HTML, minimal JavaScript, built-in image optimization, and a component model that makes semantic markup the path of least resistance. Astro doesn’t guarantee perfect Lighthouse scores, but it’s not fighting against them.

A good sandbox.

Astro’s component model is familiar if you’ve worked with JSX — scoped styles, TypeScript, props interfaces. But the framework itself is new territory for me, backed by Vite and a growing ecosystem of integrations. And because MDX posts can import components directly, I can drop an interactive widget into a blog post without designing a new page template. Islands architecture means that component hydrates on its own — the rest of the page stays static. That’s a low-friction way to experiment.

Why Astro v6 Beta?

The acquisition makes the bet clearer. Cloudflare didn’t buy Astro to maintain the status quo — they’re investing in what comes next. v6 is that next version, and the patterns it introduces are the ones Cloudflare will be optimizing for. If I’m going to learn Astro, I’d rather learn the version that represents its direction, not the one about to be superseded.

A beta has real friction. I’ve already hit one issue. But this is a personal project, not production infrastructure for an organization. The rough edges become material for the blog itself. If this were bso.org, I’d wait for stable. It’s not.

Why Cloudflare Workers

The same acquisition logic applies to the hosting decision. Cloudflare has been converging on Workers as their full-stack runtime for a while now — Pages deployments already run on Workers under the hood, and the platform keeps gaining capabilities (KV, R2, D1, Queues, AI). With Astro in the fold, that convergence is only going to accelerate. Astro’s Cloudflare adapter already defaults to Workers.

I also already use Cloudflare for DNS and have experience with the platform from work. The free tier is generous, the global edge network is fast, and the developer experience has improved enormously over the past few years.

For a static blog, Workers is arguably overkill. Pages would be fine. But starting with Workers gives me optionality — if I want to add server-side features later (API routes, edge functions, session handling), the infrastructure is already there. And since Astro’s adapter handles the wiring, the day-to-day experience is identical: I run astro build, deploy with Wrangler, and the site is live at the edge.

The practical setup is simple: static output mode in Astro, the @astrojs/cloudflare adapter, and a wrangler.toml that’s about ten lines long. Commits to main auto-deploy through Cloudflare’s GitHub integration. That’s it.

What I’m counting on

Every technology choice is a bet. Here’s what I’m betting on:

  • Astro’s direction is sound. The static-first, content-oriented approach feels right for the long term, even as the framework adds more dynamic capabilities.
  • Astro v6 will stabilize. The beta will become stable, and the patterns I learn now will carry forward.
  • Cloudflare Workers is where Cloudflare is heading. The convergence of Pages and Workers will continue, and Workers will be the right default for new projects on the platform.
  • Markdown in Git is durable. Even if I change frameworks or hosting someday, my content is plain text files in a repository. That’s about as portable as it gets.

These bets could be wrong. If they are, I’ll write about that too.

What I’m deferring

This post covers the decisions made before writing any code. It doesn’t cover the implementation — how the project was scaffolded, how the design system works, how content collections are configured. Those are separate posts in this series.

It also doesn’t cover things I’ve deliberately chosen not to do yet: dark mode, CI/CD, analytics, search, tag pages, comments. Every post in this series ends with a “what we’re deferring” section, because knowing what you chose not to do is as important as knowing what you did.