Architecting on Cloudflare
Decisions, Trade-offs, and Patterns for the Developer Platform
This is a beta version of Architecting on Cloudflare. Chapters are mostly complete, sections may shift, and there may be rough edges. If you spot errors, disagree with an assessment, or simply have thoughts on what's useful and what isn't, I'd genuinely love to hear from you at jamie@architectingoncloudflare.com. All feedback is welcome, from typos to architectural arguments.
About this book
This book covers Cloudflare's Developer Platform: Workers, Durable Objects, D1, R2, Queues, Workflows, Containers, Realtime for audio and video, and the AI stack including Workers AI, Vectorize, and the Agents SDK. These are the primitives that let you build complete applications on Cloudflare's edge network. It does not cover Cloudflare's security and networking products: WAF, DDoS protection, Zero Trust, Magic Transit, and the rest of that extensive portfolio. Excellent resources already exist for those topics, written by people with deeper expertise in network security than I possess.
This book is for developers and technical decision-makers who want to understand whether Cloudflare's compute, storage, and AI primitives can replace or complement what they're building on AWS, Azure, or GCP. If you're evaluating serverless platforms, designing new architectures, adding AI capabilities to existing applications, or wondering whether the grass really is greener on the edge, this book gives you the information to decide.
This book is not produced by, affiliated with, or endorsed by Cloudflare, Inc. It represents the author's independent analysis and opinions based on publicly available documentation and years of hands-on experience with the platform.
About the author
I'm Jamie Lord, Solution Architect at CDS UK, where I shape the technical direction of an organisation working at the intersection of government, policing, and healthcare technology. Much of my work centres on Single Online Home, a platform connecting almost every UK police force with the citizens they serve. I lead the technical decision-making for this system, which handles millions of interactions daily with sub-second response times. It's the kind of work where getting the architecture right genuinely matters to people's lives.
My background spans the full arc from mobile development through to enterprise architecture. I've built offline-first mobile applications with complex synchronisation logic, transformed legacy desktop software into multi-tenant SaaS platforms serving thousands of organisations, and co-founded a startup as CTO, building a privacy-preserving employee wellbeing platform from the ground up. That last experience taught me how to take a product from concept through to enterprise deployment, and reinforced my conviction that privacy and utility don't have to be in tension.
Day-to-day, I work across Azure, AWS, and Cloudflare to design hybrid cloud solutions for government clients handling Official-Sensitive data. I architect digital evidence platforms and legacy modernisation programmes. Being the sole Solution Architect at CDS means every significant technical decision crosses my desk, from database consolidation strategies to full platform migrations. I bridge conversations between technical teams and senior stakeholders across government departments, ensuring what we build meets security requirements (ISO 27001, Cyber Essentials Plus) and actually solves the problems it's meant to solve.
CDS is a UK-based digital transformation company that helps organisations across the public sector, healthcare, finance, and other regulated industries navigate complex technology decisions. Our clients include the NHS, UK policing through Single Online Home, and numerous local authorities and regulatory bodies. We hold seven ISO certifications and are listed on multiple public sector procurement frameworks including G-Cloud and the Digital Outcomes framework.
Transparency matters here: CDS is a Cloudflare partner. We became the first Cloudflare Authorised Service Delivery Partner in EMEA, and we resell Cloudflare services through G-Cloud. We use Cloudflare's security and networking products extensively across client work. This commercial relationship exists and you should know about it.
However, this book focuses on the Developer Platform (Workers, Durable Objects, D1, R2, Workers AI, and the rest), which represents a different part of my engagement with Cloudflare. My adoption of the Developer Platform has been driven by technical evaluation rather than commercial obligation. I use these products in personal projects because I find them architecturally compelling. I've advocated for them in professional contexts because the technical and economic arguments hold up to scrutiny, not because CDS has a reseller agreement.
The author works for a Cloudflare partner organisation. This book nonetheless includes honest assessment of limitations, specific failure thresholds, and scenarios where hyperscalers remain the better choice. The goal is useful technical guidance, not marketing.
This perspective shapes the book. I'm not here to sell you on Cloudflare; I'm here to give you the information I wish I'd had when I started evaluating the platform. That includes honest assessment of limitations, specific thresholds where the platform stops being the right choice, and acknowledgment of scenarios where hyperscalers genuinely serve better. If anything, the commercial relationship raises the bar for honesty: recommending Cloudflare when it's wrong for a workload would damage both the client relationship and CDS's reputation. The assessments in this book reflect what I'd tell a client in a consulting engagement, not what a sales team would put in a pitch deck.
My philosophy
After years of working with Cloudflare's Developer Platform, I've arrived at a simple heuristic: start with Cloudflare and find reasons not to use it, rather than starting elsewhere and finding reasons to migrate.
Start with Cloudflare's defaults (global deployment, instant scaling, zero cold starts) and validate whether hard constraints apply. This approach reveals blockers quickly before switching costs accumulate.
This might sound like advocacy dressed as advice, but it reflects genuine experience. The platform's defaults (global deployment, instant scaling, zero cold starts, integrated security) mean you begin with capabilities that require significant effort to achieve elsewhere. The constraints that do exist are explicit and well-documented. You discover quickly whether they affect your workload.
The alternative approach (starting with a hyperscaler and evaluating Cloudflare later) often means building around constraints you didn't need to accept and paying for complexity you didn't need to manage. By the time you evaluate alternatives, switching costs have accumulated.
This doesn't mean Cloudflare fits every workload. Chapter 24 catalogues the limitations honestly, and Chapter 2 provides frameworks for evaluating fit. But when I'm advising teams on new projects, my default recommendation is to prototype on Cloudflare first and validate whether any hard constraints apply, rather than defaulting to AWS because it's familiar.
Who this book is for
This book assumes you have context to compare against. The most value goes to readers who already understand cloud architecture and want to evaluate a different approach:
- CTOs and Technical Directors who need to understand platform capabilities, strategic fit, and organisational implications
- Solution Architects evaluating Cloudflare against hyperscalers for specific workloads
- Lead Developers and Engineering Managers who must architect solutions and guide teams
- Senior Engineers transitioning from AWS, Azure, or GCP who need to understand Cloudflare's different mental model
If you've never built on any cloud platform, this book will make less sense. It explains Cloudflare by contrast to what you likely already know, and that contrast requires prior knowledge to land properly.
What makes this book different
This is not documentation; Cloudflare already has excellent documentation. This book provides:
- Architectural decision frameworks rather than tutorials
- Honest assessment of limitations with specific thresholds
- Deep "why behind the what" explanations
- Production reality including testing, operations, and cost modelling
- Migration playbooks from hyperscaler patterns
The goal is to accelerate your evaluation and de-risk your adoption. Whether you conclude that Cloudflare fits your needs or doesn't, you'll reach that conclusion faster and with more confidence than piecing together information from documentation, blog posts, and trial-and-error.
Book structure
Part I: foundation
Why Cloudflare thinks differently about compute, and how to decide if that difference matters for your workload. These chapters give you the mental models to evaluate everything that follows, plus a framework for knowing when to stop reading and use something else.
Part II: core compute
The V8 isolate model that makes sub-millisecond cold starts possible. You'll understand why Workers feel different from Lambda, how to build complete applications without leaving the edge, and how to develop locally without constantly deploying to test changes.
Part III: stateful systems
Where Cloudflare gets genuinely interesting. Durable Objects provide coordination primitives that don't exist elsewhere. Workflows handle processes that must complete even when infrastructure fails. Queues decouple without the complexity. Containers escape V8's constraints when you genuinely need to. Realtime delivers WebRTC without the infrastructure nightmare.
Part IV: data & storage
The storage decision that determines whether your architecture sings or struggles. When D1's SQLite model beats PostgreSQL, when R2's zero egress fees change your economics, when KV's eventual consistency is a feature not a bug, and when Hyperdrive lets you keep your existing database while gaining edge performance.
Part V: the AI stack
AI inference without the infrastructure tax. Workers AI runs Llama at the edge; Vectorize stores embeddings globally; AI Search handles RAG without you building pipelines; the Agents SDK lets AI take actions, not just answer questions. This section is honest about when Cloudflare's models suffice and when you need GPT-4 or Claude instead.
Part VI: production
What it actually costs, how to see what's happening, and how to keep it secure. Cost modelling that prevents bill shock, observability that works across primitives, and security patterns for a platform where your code runs in shared infrastructure.
Part VII: architecture & decisions
Patterns that work, patterns that don't, and the constraints you'll wish someone had told you earlier. Reference architectures for common problems, multi-tenant designs that scale, and an honest catalogue of limitations that might send you back to hyperscalers.
Part VIII: migration
How to get here from there. Practical playbooks for moving Lambda functions, containerised services, and traditional backends onto Cloudflare, plus a synthesis of the principles that make edge-native architecture work.
A note on platform state
This book reflects the Cloudflare Developer Platform as of February 2026. Specific limits, pricing, APIs, and features will evolve as Cloudflare continues to develop the platform. When making decisions that depend on exact numbers, always verify current values in Cloudflare's documentation.
What remains stable are the architectural principles and mental models. The V8 isolate execution model, the binding abstraction, horizontal scaling as the default pattern, edge-native design philosophy, and the economic logic of CPU-time billing are foundational characteristics that persist regardless of whether a specific limit is 128 MB or 256 MB, or whether a particular API parameter changes name. The decision frameworks throughout this book are designed to remain useful even as implementation details shift beneath them.
Build with the principles. Verify the specifics.