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

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 that prevents bill shock, observability that works across primitives, security patterns for shared infrastructure, reference architectures for common problems like multi-tenant SaaS and real-time collaboration, and migration playbooks for teams moving from hyperscaler patterns.

An entire chapter on when not to use Cloudflare

This is the chapter that surprises people, and it is the chapter I am most proud of.

Every platform has a shape. Some workloads fit brilliantly; others do not. If your application needs more than 128 MB of memory per request, Workers are the wrong tool. That is not an engineering failure waiting to be fixed; it is the price of the isolate model that makes sub-millisecond cold starts possible. If your database exceeds 10 GB and cannot be sharded horizontally, D1 is the wrong choice. If you need inbound TCP or UDP connections beyond WebRTC, Cloudflare cannot do it.

The book says all of this plainly, with specific thresholds and concrete recommendations for what to use instead. I wrote it this way because recommending Cloudflare when it is wrong for a workload would damage both the client relationship and CDS's reputation. The assessments reflect what I would tell you in a consulting engagement, not what a sales deck would show you. Honesty about limitations is what separates genuinely useful technical guidance from marketing dressed up as advice.

Why a Solution Architect at CDS wrote this

I work across Azure, AWS, and Cloudflare every day, designing hybrid cloud solutions for government clients handling Official-Sensitive data. I architect the systems behind Single Online Home, a platform connecting almost every UK police force with the citizens they serve, handling millions of interactions daily. When you are building services that people depend on, architectural decisions carry weight that conference demos do not capture.

My adoption of Cloudflare's Developer Platform was driven by technical evaluation, not commercial obligation. I use these products in personal projects because I find them architecturally compelling. I started writing about them on my blog because I kept discovering things I wished someone had explained to me earlier. The blog posts turned into longer analyses. The analyses turned into something that clearly wanted to be a book.

CDS became the first Cloudflare Authorised Service Delivery Partner in EMEA. We have used Cloudflare's security and networking products extensively across client work in government, policing, healthcare, and regulated industries. But the Developer Platform represents something different. It is not just about protecting traffic and mitigating DDoS attacks. It is about building entire applications on a global edge network with economics and performance characteristics that traditional cloud providers cannot match. A thousand D1 databases with modest usage costs roughly £8 per month. A single equivalent RDS instance costs roughly £24 before storage, I/O, or backup charges. The economics differ by orders of magnitude, and that changes what is architecturally viable.

When CDS advises you on whether Cloudflare's Developer Platform fits your workload, that advice comes from the same rigour that produced twenty-six chapters of architectural analysis. The book is not separate from the consulting. It is the consulting, written down and made freely available.

Who should read it

If you have read the existing code-focused Cloudflare book and come away knowing how to build things but still unsure about whether you should, this is the companion piece. It picks up where tutorials leave off and addresses the architectural and strategic questions that determine whether a Cloudflare adoption succeeds or stalls.

CTOs evaluating whether the platform belongs in their technology strategy will find frameworks to decide with confidence rather than gut feeling. Solution Architects comparing Cloudflare against hyper scalers for specific workloads get specific thresholds and decision matrices. Senior engineers transitioning from AWS, Azure, or GCP will find the mental model shifts mapped explicitly, because the differences are real and pretending otherwise wastes everyone's time.

The book assumes you have context to compare against. If you have never built on any cloud platform, start elsewhere. If you have, and you are wondering whether the edge-native approach is substance or marketing, twenty-six chapters of honest architectural analysis should settle it.

Go and read it

I made the book freely available because the goal was always to be useful, not to gatekeep expertise. That philosophy is what CDS is about, and it turns out that writing twenty-six chapters of architectural guidance is a rather thorough way to demonstrate it.

CDS has the partnership credentials, the delivery track record, and now, quite literally, the book on the subject. If you are considering Cloudflare's Developer Platform for your organisation, or if you are already on the platform and want to ensure your architecture is sound, get in touch. If you just want to learn, the book is waiting.

Architecting on Cloudflare is available now at architectingoncloudflare.com