Why I Build Everything on Cloudflare Now
Why I Build Everything on Cloudflare Now
These days, when I start a new project, I reach for Cloudflare first.
Not as a CDN bolted onto the end of a "real" stack. Not as a cheaper place to host static files. I mean Cloudflare as the stack: Workers for compute, Durable Objects for state and coordination, D1 for relational data, R2 for files, KV for global key-value reads, Queues for asynchronous work, AI Gateway for model traffic, and Vectorize for semantic memory.
That combination has become the closest thing I have found to a perfect infrastructure default. It is small enough to understand, broad enough to ship real products, and boring in the places where infrastructure should be boring.
The old default feels too heavy
The traditional web stack makes you assemble too much before you can ship anything useful. You pick a server runtime, a host, a database, object storage, background jobs, sessions, observability, deployment, secrets, and a CDN. Then you spend the life of the project managing the borders between them.
That can be worth it for very large systems. For most products, tools, bots, dashboards, and AI applications, it is just drag.
Cloudflare changes the starting point. A Worker gives you a serverless execution environment on Cloudflare's global network. Bindings make platform services feel like local capabilities rather than separate vendor integrations. The deploy path is one command. The production environment is not a fragile replica of five services stitched together after the fact.
That is the real reason I like it: the stack has a coherent center.
Workers are the base layer
Cloudflare Workers are the piece that makes the rest of the stack feel native. They run application code without making me think about machines, regions, process managers, reverse proxies, or autoscaling.
For a product builder, that changes the mental model. I can write the request handler, bind the data products I need, deploy it, and move on. Workers now fit modern full-stack apps too: React, TanStack Start, API routes, scheduled jobs, WebSockets, RPC-style service boundaries, and static assets can all live inside the same deployment model.
The important part is not only "serverless." The important part is that the platform is global by default and operationally compact. The thing that handles the request is also sitting next to the cache, the storage bindings, the security layer, and the observability story.
Durable Objects are the missing primitive
Most serverless platforms are good until you need coordination. Then you suddenly need Redis, Postgres locks, a queue, a websocket server, or some careful dance around idempotency.
Durable Objects are why Cloudflare feels different. They give you a globally unique object with compute and durable storage attached to it. That makes a lot of awkward distributed problems much simpler: one chat room, one collaborative document, one user agent, one trading session, one multiplayer lobby, one workflow coordinator.
The official positioning is straightforward: Durable Objects are for stateful applications and distributed systems, especially collaborative and real-time applications. The reason they work so well in practice is that they let you put coordination behind an addressable object instead of spreading it across half your architecture.
When I need strong per-entity consistency, I do not want to invent a locking protocol. I want a Durable Object.
D1 is the relational default
I still want SQL. I want tables, migrations, indexes, joins, constraints, and boring relational data modeling. I just do not want to maintain a database server for every small or medium product.
D1 is Cloudflare's managed serverless SQL database with SQLite semantics. That is exactly the shape I want for most application data: users, posts, orders, projects, settings, audit logs, lightweight analytics, admin panels.
D1 is not trying to be every database for every workload. That is part of why I like it. For the majority of read-heavy application data, it gives me the relational model without turning database operations into the center of the project.
If I need per-user or per-room SQL state with strict coordination, I can use SQLite-backed Durable Objects. If I need a shared relational database for the app, I use D1. The split is easy to reason about.
R2 makes files feel obvious
Every real product eventually stores files: images, exports, PDFs, generated artifacts, backups, audio, datasets, user uploads.
R2 is the obvious place for that inside this stack. It is object storage, it is S3-compatible, and Cloudflare positions it around storing large amounts of unstructured data without the usual egress bandwidth fees attached to typical cloud storage services.
That matters more than people admit. File storage should not make you nervous about a successful launch, a scraper, a media-heavy feature, or a customer downloading their own data. R2 makes object storage feel like a natural extension of the Worker instead of a billing trap attached to the side.
For my projects, R2 is where screenshots, attachments, generated files, exports, and durable blobs belong.
KV is for fast global reads
Workers KV is the part of the stack I use when the data wants to be read everywhere and changed rarely: configuration, feature flags, route metadata, public settings, session-ish lookups, cached API responses, personalization data.
KV is eventually consistent, and that is not a flaw if you use it for the right jobs. It is a design choice. Cloudflare's storage guide describes KV as a global key-value store built for high read volume, low-latency global reads, TTLs, and distributed configuration or session storage.
That is a powerful primitive. Not everything should be in SQL. Not everything needs strong consistency. Some data wants to be cheap, replicated, and close to the user.
Queues make async work native
The other primitive I want close to the request path is a queue.
Cloudflare Queues integrate directly with Workers and let you send messages for asynchronous processing. That covers the normal background work every product accumulates: sending emails, processing uploads, syncing external APIs, fanning out webhooks, generating reports, writing logs, retrying flaky third-party calls, and moving work out of the user-facing request.
The important part is that Queues fit the same platform vocabulary. A Worker can produce messages. A Worker can consume messages. The queue can buffer, batch, retry, delay, and route failures to a dead-letter queue. I do not need to introduce a separate message broker just because one part of the app should happen later.
That completes a big missing piece in many serverless setups. Workers handle the request. Queues absorb the work that should not block the request. Durable Objects coordinate the stateful entities. D1, R2, and KV store the right kinds of data. The whole thing stays inside one operational model.
AI Gateway and Vectorize make AI apps feel native
This is also where Cloudflare has started to feel especially good for AI projects.
AI Gateway is the control plane I want in front of model calls. It gives AI applications analytics, logging, caching, rate limiting, retries, and model fallback without making every app rebuild that layer from scratch. That matters because AI traffic is not normal API traffic. It is expensive, variable, failure-prone, and easy to lose visibility into if every model call goes straight from the app to a provider.
Vectorize fills the other side of the AI stack. It is Cloudflare's vector database for embeddings, semantic search, recommendations, classification, anomaly detection, and retrieval-augmented generation. When an app needs memory or context, I do not want to bolt on a separate vector database before the idea has even proven itself. I want the Worker to query a vector index in the same platform shape as the rest of the product.
I have already used AI Gateway and Vectorize in one project, and that made the Cloudflare argument stronger for me. The AI part did not feel like an exception to the architecture. Model calls, semantic retrieval, app data, files, queues, and deployment all lived in one coherent system.
The stack composes cleanly
The reason I call this stack superior is not that each product wins every feature checklist in isolation. It is that the products compose well:
- Workers run the app.
- Durable Objects coordinate stateful entities.
- D1 stores relational product data.
- R2 stores files and blobs.
- KV serves hot, mostly-static global reads.
- Queues move background work out of the request path.
- AI Gateway observes and controls model traffic.
- Vectorize stores embeddings for semantic search and RAG.
That covers a huge amount of product surface without leaving the platform. A SaaS dashboard, admin panel, AI tool, Telegram bot backend, public website, private internal tool, webhook processor, file generator, or real-time collaborative feature can all start from the same infrastructure vocabulary.
The architecture stays readable. The deployment stays small. The local-to-production story stays close enough that you are not constantly rediscovering where the real system differs from the development system.
It also changes how I build
The biggest practical effect is speed. I do not spend the first day deciding where the app lives. I do not open five dashboards to connect basic infrastructure. I do not introduce a queue just because one request needs to trigger another piece of work. I do not add a separate object storage vendor for uploads. I do not reach for a full database cluster because I need twenty tables.
I start with Cloudflare and only leave when the workload proves it needs something else.
That default is important. Infrastructure choices have gravity. If the first choice is too heavy, every feature inherits that weight. If the first choice is too narrow, every feature becomes an exception. Cloudflare is the rare default that feels both compact and expandable.
It is becoming agent-friendly infrastructure
There is another reason this matters more now: AI agents are starting to write, deploy, verify, and revise software in loops.
Cloudflare is moving in the right direction here too. In June 2026, Cloudflare introduced Temporary Cloudflare Accounts for AI agents. The idea is simple and important: an agent can deploy a Worker with wrangler deploy --temporary even when there is no existing authenticated Cloudflare account in the environment.
That temporary deployment gets a workers.dev URL and a claim link. The agent can curl the deployed app, check whether it works, change the code, and redeploy again during the temporary account window. If the human wants to keep it, they can claim the account and make it permanent. If not, it expires.
This is exactly the kind of detail that makes a platform feel ready for the next development workflow. Agents do not need a dashboard click-path. They need a tight write, deploy, observe, fix loop. Cloudflare is shaping its platform around that loop instead of treating agents like awkward humans without browsers.
The docs are careful about the limits: temporary deployments are for unauthenticated preview use, not production or CI/CD. That is fine. The important signal is that Cloudflare is making the first deployment path friendly to automated builders. For me, that fits the whole philosophy of the stack: remove ceremony, keep the primitives real, and let the product get in front of a URL quickly.
The tradeoff is discipline
There are still rules.
You have to understand eventual consistency in KV. You have to choose D1 versus Durable Object storage based on the consistency and locality shape of the data. You should not pretend object storage is a database. You should know when a workload needs a dedicated external system.
But those are good constraints. They make the architecture sharper. Cloudflare gives you a set of primitives with clear jobs, not one magical bucket where all data goes to become confusing later.
My current default
My default stack now looks like this:
- React.js/TanStack Start or a Worker-native app at the edge.
- D1 for the main relational model.
- R2 for uploads and generated files.
- KV for configuration, caches, and high-read metadata.
- Queues for background jobs, retries, batching, and Worker-to-Worker handoffs.
- AI Gateway for logging, caching, rate limiting, retries, and model fallback.
- Vectorize for embeddings, semantic search, and RAG context.
- Durable Objects when a user, room, agent, workflow, or session needs state and coordination.
- Wrangler for deployment and migrations.
- Temporary Wrangler deployments when an AI agent needs a fast preview loop.
That is enough to ship most things I want to build.
So yes: I think Cloudflare is the best infrastructure to build on right now. Not because it is fashionable, and not because every workload should be forced into it. It is the best because it gives me a superior default: global compute, practical storage, stateful coordination, object storage, and operational simplicity in one platform.
I use it because it lets me spend more time building the product and less time babysitting the shape around it.