I Wrote the Book on Cloudflare's Developer Platform. Here's Why.

Contact Us

Our thoughts

Insight

I Wrote the Book on Cloudflare's Developer Platform. Here's Why.

Posted in

Insight,

Cyber Security,

Partner,

Cloud

February 2026

Share

6 minutes reading time

Sometime around chapter fourteen, staring at a diagram of KV propagation semantics at midnight whilst my family slept, I had the thought that every author apparently has: what on earth possessed me to start this?

Twenty-six chapters. Eight parts. Covering every compute, storage, AI, and stateful primitive on Cloudflare's Developer Platform, from Workers and Durable Objects through to Containers, Workflows, the Agents SDK, and everything in between. Honest assessments of where the platform excels and where it falls short. Decision frameworks that compare Cloudflare against AWS, Azure, and GCP with specific thresholds rather than hand-waving. An entire chapter dedicated to when you should not use Cloudflare at all.

The book is called Architecting on Cloudflare, and it exists because the resource I needed when I started evaluating this platform for production workloads simply did not exist.

The gap nobody was filling

There is at least one existing book on Cloudflare's Developer Platform. It does a perfectly solid job of walking you through code examples and showing you how to build things. If you want a guided tour of the APIs with working samples, it serves that purpose well.

But code examples solve a different problem from the one I kept encountering. When a CTO asks me whether Cloudflare belongs in their technology strategy, they do not need a tutorial on how to write a Worker. They need to understand why the V8 isolate model shapes every architectural decision on the platform, what it means that Durable Objects have no equivalent on any hyperscaler, whether D1's 10 GB database limit is a dealbreaker or a design feature, and at what point the platform's constraints should send them back to AWS.

That is the conversation I have in consulting engagements every week. The wider context, the architectural reasoning, the honest comparison against what organisations are already running, the decision frameworks that help you choose between Cloudflare's own primitives. None of that existed in a single coherent resource. Documentation covers the "how." Blog posts cover fragments of the "why." Discord threads capture hard-won tribal knowledge that disappears into scroll history. Nowhere could I point someone and say: read this, then we'll have a productive conversation.

So I wrote it. The book I wanted to read did not exist, so it became the book I had to write.

What twenty-six chapters actually covers

The scope is deliberately ambitious because the platform itself is ambitious, and superficial treatment would defeat the purpose.

Part I establishes the mental models. The V8 isolate execution model is not a minor implementation detail; it is a fundamentally different approach to running code that determines what you can and cannot build. The first time you deploy a Worker and it is live everywhere in seconds with no region selection, no capacity planning, no cold start mitigation, your instinct insists you have missed a step. You have not. Understanding why is the foundation for everything that follows.

Parts II and III cover compute and stateful primitives, and this is where the platform gets genuinely fascinating. Durable Objects represent what I believe is Cloudflare's most significant contribution to cloud computing. Globally unique actors with strongly consistent storage, processing requests sequentially from anywhere in the world. AWS has no equivalent. Azure's closest analogue requires stitching multiple services together. Google Cloud offers nothing comparable. The book explains not just how they work but when you should reach for them versus D1 or KV, with decision frameworks built from production experience rather than theoretical preference.

Part IV tackles storage. When does D1's SQLite model beat PostgreSQL? When do R2's zero egress fees fundamentally change your economics? When is KV's eventual consistency a feature rather than a bug? The answer to each depends on your specific workload, and the book provides the frameworks to decide rather than prescribing a single correct answer.

Part V covers the AI stack with the candour it deserves. Workers AI trades frontier model quality for reduced latency and operational simplicity. If your users cannot tell the difference between Llama and GPT-4for your specific task, you are paying a sophistication tax you do not need. If they can tell the difference and it matters, use the better model. AI Gateway routes those requests whilst keeping observability on-platform. That kind of honest assessment is rare in vendor-aligned technical content. It is precisely what makes the book useful rather than promotional.

Parts VI through VIII cover what actually matters in production: cost modelling...