I wanted a developer blog that felt more like an engineered platform than a traditional personal site.
Not just a static template with articles slapped onto it, but something:
- globally fast
- content-first
- interactive without becoming bloated
- cheap to operate
- fully owned end-to-end
So over the last few weeks, I built my personal blog platform from scratch using Astro, Cloudflare Workers, Turso, React islands, Pagefind, Giscus, and a lot of frontend experimentation.
This post breaks down the architecture, engineering decisions, runtime issues, performance optimizations, and lessons learned while building it.
The Goal
The goal was to create a platform that could serve as:
- a space for writing and sharing technical ideas
- a playground for frontend engineering and UI experimentation
- a place to document architectural decisions and tradeoffs
- something polished enough to genuinely feel proud of
Performance mattered a lot from the beginning.
I wanted:
- static HTML by default
- minimal JavaScript
- edge delivery
- selective hydration
- excellent Lighthouse scores
- smooth interactions without turning the site into a client-side app
The Stack
| Layer | Technology |
|---|---|
| Framework | Astro 6 |
| Interactive Islands | React 19 |
| Styling | Tailwind CSS v4 |
| Deployment | Cloudflare Pages |
| APIs | Cloudflare Workers |
| Database | Turso |
| ORM | Drizzle ORM |
| CMS | Keystatic |
| Search | Pagefind |
| Comments | Giscus |
| Runtime | Bun |
Some factors that influenced these choices:
- performance
- edge compatibility
- developer experience
- long-term maintainability
Why Astro?
One obvious question here is: why Astro instead of something like Next.js?
Astro felt like the perfect fit for this project.
Most pages on a blog don’t need JavaScript at all, and Astro’s Islands Architecture made it possible to ship static HTML by default while hydrating only the interactive parts like:
- comments
- likes
- search
- theme toggles
This kept the site lightweight while still allowing rich UI interactions, resulting in:
- tiny JS payloads
- fast initial loads
- strong Lighthouse scores
- better SEO
Another reason I chose Astro was timing.
The framework has been gaining a lot of traction recently, especially after the Cloudflare acquisition, and I wanted to experiment with something that aligned closely with the edge-first ecosystem I was already building around.
Where I Over-Engineered Things
One of the biggest lessons while building this project was learning when not to use React.
Initially, I over-engineered parts of the app with too many React islands and unnecessary react-query state management, to the point where the project started feeling more like a React app running inside Astro than an Astro site itself.
Early on, I was throwing React islands everywhere for convenience.
Over time, I started stripping hydration back aggressively and only keeping interactivity where it genuinely improved the experience.
Ironically, some of the biggest performance improvements came from removing things instead of adding more optimizations.
Edge-First Deployment with Cloudflare
After deciding on Astro, the next question was where to deploy it.
Since Astro had recently been acquired by Cloudflare, I started exploring Cloudflare’s ecosystem more deeply, and it ended up fitting this project extremely well.
The platform is deployed on Cloudflare’s edge network using:
- Cloudflare Pages for deployment
- Cloudflare Workers for APIs
- Cloudflare CDN for caching and global delivery
I also ended up appreciating Cloudflare Workers more than I expected.
Their live logs made debugging edge runtime issues and Turso integration problems significantly easier during development.
The combination of:
- global edge delivery
- automatic deployments
- built-in caching
- SSL
- DDoS protection
made Cloudflare an easy choice for this project.
Cloudflare Workers Behave Very Differently From Node
One thing I underestimated initially was how differently Cloudflare Workers behave compared to a traditional Node.js environment.
At some point, I had optimized the project so heavily around the Cloudflare runtime that parts of the app simply stopped working properly in local Node development.
The Runtime Bug That Broke Production
One of the weirdest bugs I ran into was that everything worked perfectly locally, but database calls silently failed in production once deployed to Cloudflare Workers.
It eventually turned out to be runtime differences between Node and the Workers environment, which forced me to rethink parts of the local development setup entirely.
I ended up splitting adapters between development and production environments and introducing local Workers shims just to keep the developer experience sane again.
That experience alone taught me more about edge runtimes than most tutorials I had read before starting the project.
Why Turso?
For a content platform like this, a distributed SQLite database felt surprisingly appropriate.
I’m using Turso for:
- page views
- analytics
- interaction systems
- likes
- lightweight dynamic functionality
Instead of maintaining a centralized Postgres instance, Turso keeps the infrastructure lightweight while still supporting globally distributed reads through edge replication.
One of the biggest reasons I liked the Cloudflare Workers + Turso combination was cost efficiency.
Cloudflare Workers already has a generous free tier, while Turso’s free tier includes:
- hundreds of millions of row reads
- multiple edge replicas
- enough capacity for personal projects without worrying about infra costs
Since both the compute and the database can live close to the user, the whole stack ends up feeling extremely lightweight and fast without needing traditional server infrastructure.
It also integrates really nicely with Drizzle ORM and edge runtimes.
Keystatic Was the Perfect Choice
Once I had settled on Astro, Cloudflare, and Turso, the next challenge was figuring out how I actually wanted to write and manage content.
I knew I didn’t want a workflow where I had to manually edit Markdown files every time I wanted to publish something.
I wanted a system that would let me:
- write blogs from anywhere
- publish quickly while travelling
- provide a responsive editing experience
- keep Git as the source of truth
While researching CMS options, I came across Keystatic, and it ended up solving almost everything I needed out of the box.
What made it attractive was that it’s:
- open source
- actively improving
- trusted by a lot of developers
- built around a Git-based workflow
That Git-first approach mattered a lot because all the blog content lives directly inside the repository as Astro content collections.
Keystatic became the perfect bridge between:
- a modern editing experience
- and a Git-backed content system
Search Without External Infrastructure
I wanted search functionality, but without introducing another external service or maintaining a dedicated backend just for indexing content.
While researching options, I briefly considered Algolia, but it felt unnecessary for a mostly static content platform.
Then I came across Pagefind.
Pagefind generates a full-text search index during the build process itself and ships it alongside the static assets.
That aligned perfectly with Astro’s static-first philosophy.
I also liked how much control it gives over indexing through attributes like data-pagefind-body, allowing only relevant content to become searchable.
The integration itself was pretty straightforward using @pagefind/default-ui, although I did slightly modify the build pipeline so indexing runs after Astro finishes building:
astro build && npx pagefind --site dist/client
The end result feels surprisingly fast without adding additional infrastructure complexity.
Comments with Giscus
I knew pretty early on that I didn’t want to build a custom comment system.
Doing that properly would’ve meant:
- moderation logic
- authentication systems
- spam prevention
- abuse protection
- extra database complexity
For a blog, that felt unnecessary.
While researching alternatives, I came across Giscus, which uses GitHub Discussions as the backend for comments.
That approach made a lot of sense for this project because the audience is mostly developers anyway.
What I liked most was that it completely removed the need to implement my own auth system.
With Giscus:
- readers can browse without friction
- developers can comment using GitHub
- moderation becomes much easier
- GitHub handles abuse prevention and rate limiting
Honestly, it ended up being one of the highest value-to-effort integrations in the project.
Dynamic OG Image Generation
I also wanted every blog post to have its own custom social preview card instead of relying on generic screenshots or manually designed thumbnails.
The OG images are generated dynamically using:
- Satori
- Resvg WASM
- custom layouts/components
Initially, I planned to use Sharp for image generation since that’s what most examples online were using.
But after experimenting for a while, I eventually switched to @resvg/resvg-wasm instead.
The WASM-based approach fit the Cloudflare environment much better and avoided a lot of deployment friction native image-processing libraries can introduce.
Each post now automatically gets a consistent branded preview image for:
- X
- Discord
without manually designing thumbnails every time.
Frontend & UI Systems
A huge part of this project was experimenting with frontend interactions and UI systems without letting the site become unnecessarily heavy.
The frontend is built using Tailwind CSS v4.
I also knew from the beginning that the blog needed both light and dark themes because developers tend to care a lot about reading experiences.
That eventually led to building:
- animated theme toggles
- motion-heavy blog cards
- spotlight hover effects
- glow systems
- animated gradients
Initially, I definitely over-engineered parts of the frontend.
Over time, I started simplifying aggressively:
- porting many React islands back to Astro components
- replacing client-heavy interactions with CSS
- reducing unnecessary animations
- simplifying DOM structure
- reducing runtime JavaScript
The goal slowly shifted from:
“make everything animated”
to:
“make interactions feel intentional without hurting performance.”
A lot of the Lighthouse and SEO improvements actually came from these frontend decisions.
Security, Middleware & Edge Concerns
Something else this project pushed me into thinking about more seriously was security and infrastructure hardening.
Once you fully own the entire platform end-to-end, you naturally start thinking about things like:
- bot protection
- DDoS mitigation
- rate limiting
- WAF rules
- middleware behavior
- caching strategies
- API protection
I ended up spending more time than expected thinking through how requests move through the system at the edge and how to keep things lightweight without exposing unnecessary attack surfaces.
Cost Breakdown
One of the funniest parts of this project is how cheap the infrastructure actually is.
| Service | Cost |
|---|---|
| Cloudflare Pages | Free |
| Cloudflare Workers | Mostly Free |
| Turso | Free / Extremely Low |
| Pagefind | Free |
| Keystatic | Free |
| Giscus | Free |
For the kind of architecture this project uses, the overall cost still feels kind of absurdly low.
The whole platform currently runs globally for basically the cost of the domain.
Things I’d Do Differently
A few things I’d probably change if I rebuilt this today:
- introduce fewer React islands initially
- simplify some animation systems earlier
- structure shared styles more cleanly from the start
- think about runtime differences earlier in development
- avoid over-engineering state management in static-heavy pages
Final Thoughts
This project ended up teaching me way more than I expected.
Not just about Astro, frontend performance, or Cloudflare Workers, but about how differently you start thinking once you fully own the entire system end-to-end.
This was also my first time seriously using Cloudflare as a hosting platform, and it pushed me into thinking much more from an edge-first perspective instead of a traditional “deploy and forget” mindset.
One thing I became almost obsessed with during development was load time.
For a mostly static content platform, even a few hundred milliseconds starts feeling noticeable.
I realized how satisfying it is to fully control:
- the architecture
- the deployment
- the content system
- the interactions
- and the performance characteristics yourself
And honestly, this still feels like the beginning.
The entire platform is also open source if anyone wants to explore the implementation details, use parts of it as reference, or build on top of it:
Original article:
I Built a Distributed Blog Platform on Cloudflare
Would genuinely love feedback from other developers about how they planned and created their blog, what were the pains and gains etc.
Thanks for reading.
Top comments (0)