An introduction to Cloudflare's ecosystem

A website starts with a name and a page. Before long, it needs somewhere to save a form submission, a place for uploaded files, a way to send email, and some protection from requests nobody wanted. Each addition is small. Together, they become the infrastructure you have to look after.

Cloudflare covers much of that ground. You can use it to manage DNS and cache traffic for a site hosted elsewhere, or you can run the application itself there. Its developer platform includes code execution, databases, file storage, background jobs, and AI services, alongside the networking and security tools.

I use it for this site and Unblock Syria. What appeals to me is being able to connect those parts without maintaining a server for each job. This series will explain how I use them, where they help, and what you need to understand before relying on them. First, a tour of how the pieces fit together.

Start with the domain and the incoming request

There are two separate jobs here: owning a domain and telling browsers where to find it. Registrar handles registration and renewal; DNS holds the records that point names at services. You can use Cloudflare DNS while keeping your domain registered elsewhere.

For a site on another host, the next choice is whether web traffic should pass through Cloudflare. A proxied DNS record sends it through Cloudflare’s network before it reaches your server. That allows Cloudflare to serve cached content and apply traffic rules. A DNS-only record leaves the web connection going directly to your host.

This is where the familiar CDN fits: keep reusable content on a distributed network so every visitor doesn’t need a fresh response from your server. Security works along that path too. DDoS protection deals with attack traffic, while the web application firewall can filter requests according to managed and custom rules. The available controls depend on the plan and configuration.

You can stop here. Your existing application can stay where it is while Cloudflare handles this part of the request’s journey.

Run the application on Workers

Workers lets you deploy application code to Cloudflare’s network. A Worker can answer an API request, render a page, or process an event. Cloudflare operates the runtime; you provide the code and configure the resources it can use.

For a website, Workers can serve static assets alongside that code. You’ll also encounter Pages, Cloudflare’s other website deployment product. We’ll look at the deployment choices in the frontend installment; either way, you need to distinguish the files a browser downloads from the code that runs to produce a response.

The connection to other services is a large part of the appeal. A binding gives a Worker access to a resource such as a database or storage bucket through its configuration. Service bindings let Workers call each other. You still decide which part of the application may access which resource, but the platform supplies the connection.

Give each kind of data a home

An application usually needs more than one kind of storage. Cloudflare’s data and storage guide groups the options by the work they do:

• D1 is a SQL database for records you need to query and relate.
• R2 stores files and other objects: uploads, documents, and downloads.
• KV stores values by key and distributes reads across the network. It suits data that can tolerate a delay before updates appear everywhere.
• Durable Objects combine code with state for work that needs coordination, such as a shared session or a room of connected clients.

An existing database can remain outside Cloudflare too. Hyperdrive helps Workers connect to supported Postgres and MySQL databases. Moving the application code does not require moving every piece of data on day one.

Media has another set of needs. R2 can hold an image or video file; Images adds image processing and delivery, while Stream handles video encoding and playback delivery. Choose according to how the application uses the file, not just its extension.

Handle the work around a page load

Some work should happen after a response has gone back to the visitor. Queues passes messages to consumers for processing. Workflows organizes longer jobs into steps that can retry or resume. A file import, for example, might need to fetch data, validate it, and wait for another service before finishing.

Email belongs here as well. Email Sending handles mail from the application; Email Routing forwards incoming mail addressed to your domain. Sending a confirmation and receiving a message at hello@example.com are different jobs, even though both involve email.

Control access to the application

Access control is broader than protecting a public page. Cloudflare One includes Access for controlling who may reach applications, Gateway for policies on outbound traffic, and Tunnel for connecting services hosted elsewhere. Those tools can protect an internal dashboard or connect a private service. Your public application’s own users and permissions still need a design.

For public forms, Turnstile provides a bot-checking component. You integrate it into the page and validate its token on the server. It is one part of accepting a submission safely.

Add AI where the application needs it

Cloudflare also supplies services for AI features. Workers AI runs models; Vectorize stores embeddings for similarity search. AI Gateway helps observe and control requests to model providers. These solve different parts of a feature: a document search needs retrieval, while a generated answer also needs a model call.

The Agents SDK supports stateful agents and MCP servers, which expose tools to AI clients. We’ll cover those after the underlying runtime and storage. They are easier to reason about once you know where the code runs and where its state lives.

What this looks like in Unblock Syria

Unblock Syria uses a small selection of these services. Its public site, admin dashboard, API, and MCP server each run on a Worker. The API uses D1 for records, R2 for uploads, KV for cached responses, and Email Sending for mail. Durable Objects handle rate-limit counters and MCP sessions.

Follow a submission through it: the site sends data to the API, the API validates it, a record goes into D1, and an uploaded file goes into R2. The public site and dashboard reach the API through service bindings; the MCP server calls its public HTTPS endpoint with a signed token.

The choices have changed as the application has grown. Our rate-limit counter moved from KV to a Durable Object when it needed coordinated updates. We’ll work through that choice in the storage installment. Here, it is an example of why these services have distinct jobs despite sharing a platform.

Where the five-dollar plan fits

Cloudflare has several plans and separately billed products. The Workers Paid plan starts at US$5 per month per account. It includes ten million requests and thirty million milliseconds of CPU time each month, with additional usage billed beyond those allowances. Those are the published prices as of September 7, 2026.

That makes the entry cost attractive for a small application. It does not put the entire ecosystem on a five-dollar subscription. Storage has its own allowances and usage charges, domain registration costs extra, and products such as Stream and Workers AI have separate pricing. Website security plans are also distinct from the Workers subscription.

We’ll calculate costs alongside the services that generate them. A page-view count alone won’t tell you how much database work, file processing, or model inference the application performs.

Building with it, and depending on it

Wrangler is the command-line tool for local development and deployment. Workers Builds can deploy from a connected repository. In Unblock Syria, Builds deploys the four Workers while tests run in GitHub Actions. Logs and usage metrics then help explain what happens after a release.

Sharing a platform reduces some setup, but it also creates dependencies. Code built around bindings and Durable Objects takes work to move. And a global network does not put every database next to every visitor: where data lives still affects response time. Those are decisions we’ll examine as we build, alongside the convenient parts.

The next installment starts with the domain and DNS. From there, we’ll add code, storage, and the services around them in the order an application needs them. The series page has the planned guides.

What are you building, and which part of Cloudflare would you like this series to explain? Tell me about it. If someone on your team is exploring the platform, share this introduction with them and compare which services you would actually use.