Why I Chose Astro and Cloudflare Workers for this Blog
Astro v6 beta, Cloudflare Workers, and the guiding principles behind this build — why these tools, and what I'm counting on.
My initial plan for this site was Nextjs and Payload CMS. That pairing has become my default for new projects, and I still think both are strong. But the news of Cloudflare acquiring Astro caught my eye. I’d been wanting an excuse to learn Astro, and this seemed like the right moment.
The principles behind this build
Content first
Readability and a solid UI foundation before visual polish or interactivity. Stand up the site quickly so I can spend time thinking and writing.
Low maintenance
Something I can return to after weeks away and not miss a beat. Intuitive file structures, obvious naming, minimal abstraction. Easy for AI assistants to review.
Lighthouse from the start
Performance, accessibility, SEO as through-lines from day one, not a later phase.
Sandbox for experiments
When I see something interesting, I want to try it without worrying about adapting it to my stack.
Why Astro
Astro turned out to be a strong fit for all four of those goals.
It 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. For a content site, that’s the right starting point. The “islands” architecture lets me add interactivity per component when I need it, but the default is zero JS shipped to the browser.
Content lives in the repo as MDX files with typed frontmatter. No external CMS, no database, no API layer. I define a schema in TypeScript, write posts as Markdown, and get type-safe access throughout. The workflow is Git, and the whole thing is portable. Writing MDX alongside Claude Code feels natural.
Static HTML and minimal JavaScript also mean Astro isn’t fighting against Lighthouse scores. Built-in image optimization and a component model that makes semantic markup the path of least resistance help too.
The component model is familiar if you’ve worked with JSX, but the framework itself is new territory for me. MDX posts can import components directly, so I can drop an interactive widget into a blog post without designing a new page template. That component hydrates on its own while the rest of the page stays static.
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 that’s part of why I find betas useful on a personal project: following the release notes, tracking breaking changes, and understanding what’s shifting forces a deeper familiarity than jumping in after stable. The rough edges are what guide the learning. 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.jsonc 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 set of assumptions about the future. Here are mine.
Astro’s static-first, content-oriented approach feels right for the long term, and the Cloudflare acquisition gives me confidence that the framework will continue to be invested in. Workers is where Cloudflare is heading as a full-stack runtime, and starting there means I won’t need to re-platform when I want to add dynamic capabilities.
Most importantly, my content is Markdown files in a Git repository. Even if I change frameworks or hosting someday, the writing is portable. And increasingly, AI agents are how I interact with this content: reading, drafting, editing, publishing.
I started this project planning to use a CMS. I wouldn’t have expected to be saying this, but I’m seriously considering a world where I don’t assume any new web project needs one. A personal blog is a safe place to explore that mindset.
If any of these assumptions turn out to be wrong, I’ll write about that too.
Update: Astro v6 is out of beta now. Smooth sailing so far.