Cloudflare Has a Cloud Platform—Here’s What It Offers
You may know Cloudflare as the service that makes websites faster and protects them from attacks. But you can also use it to build and run those websites—and much more.
Its Developer Platform combines application hosting, databases, file storage, background processing, and AI services. The easiest way to understand it is not as “another AWS,” but as a platform built around a different starting point: deploy your application onto a global network without managing servers yourself.
From Protecting Websites to Running Applications
Cloudflare grew out of a content delivery network, or CDN: a network that keeps copies of website content closer to visitors, reducing how far requests must travel. It also provides security services that filter traffic before it reaches a website.
Its developer platform builds on that network. Instead of merely putting Cloudflare in front of your application, you can run application code and use managed storage services within Cloudflare.
This is a serverless approach. Servers still exist, but you do not provision individual machines, maintain their operating systems, or decide which machine handles each request.
Think of Cloudflare as a serverless application platform built on a global network—not a direct replacement for every service offered by AWS or Azure.
That makes it particularly interesting for websites, APIs, and applications serving geographically distributed audiences. An API, or application programming interface, is the set of endpoints through which software requests data or actions.
The Platform at a Glance
Cloudflare’s Developer Platform has several building blocks:
| Your need | Cloudflare offering | What it does |
|---|---|---|
| Run application code | Workers | Handles web requests, APIs, and backend logic. |
| Host a website or frontend | Workers Static Assets, Pages | Serves website files, optionally alongside application code. |
| Store files and uploads | R2 | Stores objects such as images, documents, and videos. |
| Store structured application data | D1 | Provides a managed database based on SQLite, queried with SQL—the language used to read and modify relational data. |
| Look up values by a key | Workers KV | Provides key-value storage with globally cached reads. |
| Coordinate shared state | Durable Objects | Combines code and strongly consistent state, useful for chat rooms, collaboration, and other coordination tasks. |
| Process work later | Queues, Workflows | Provides message processing and durable, retryable multistep jobs. |
| Build AI features | Workers AI, Vectorize, AI Gateway | Runs AI models, searches numerical representations of content, and helps manage access to model services. |
| Run packaged Linux software | Containers | Runs containerized applications needing a fuller operating environment than Workers. |
| Connect to an existing database | Hyperdrive | Helps Workers connect to databases such as PostgreSQL or MySQL hosted elsewhere. |
R2 is S3-compatible, meaning it supports familiar interfaces from Amazon’s object-storage service. A notable selling point is no egress-bandwidth fees: R2 does not charge for the bandwidth used to transfer data out. Storage and operations can still cost money.
The data services are not interchangeable. For example, KV’s globally cached reads suit different needs from Durable Objects’ strongly consistent state, where coordinated operations must see an authoritative, up-to-date result.
You also do not have to move everything. Your application could run on Workers while keeping its existing database elsewhere.
Workers: The Center of the Platform
A Worker is application code running in Cloudflare’s managed execution environment. It might receive a request, check whether someone is signed in, read a database, and return a response.
A typical application could use:
- Workers for its frontend and API.
- D1 for customer records.
- R2 for uploaded images.
- Queues for slow background tasks.
The important caveat is that a Worker is not an ordinary server in miniature. Its runtime—the environment and APIs available to your code—has its own capabilities and limits.
Compatibility with Node.js, a common environment for running JavaScript outside browsers, has expanded, but some APIs remain partial or unsupported. Existing server software is therefore not automatically a drop-in fit.
Containers broaden the range of software you can run, but they are a separate offering with their own architecture and costs.
Hosting Websites: Workers Static Assets or Pages?
Both products can serve a built website: HTML documents, CSS styling, JavaScript, and images. Their main difference is how you organize and deploy the application.
Workers Static Assets makes website files part of a Worker deployment. Pages is a site-oriented product with its own build and deployment workflow.
They are usually alternatives—not two layers you need to combine. Cloudflare currently recommends Workers for new projects, while Pages remains supported.
Workers Static Assets: One Deployment for Files and Code
You point your project at a directory such as dist/ or public/. Deployment uploads those files and, if needed, your Worker code together. You do not need to write a Worker script just to serve files.
By default:
- A request matching a deployed asset serves that file directly.
- A request without a matching asset can run your Worker.
For example:
| Request | Typical handling |
|---|---|
/assets/app.js | Serve the JavaScript file directly. |
/images/logo.png | Serve the image directly. |
/api/orders | Run Worker code to retrieve orders. |
Your Worker can also retrieve deployed files through an assets binding, commonly named ASSETS. A binding is a configured connection through which your code accesses a resource.
You can change the routing with assets.run_worker_first, making code run before files are served for all or selected paths. This is useful when you must authenticate a request before returning a protected file.
The crucial hosting decision is which requests serve files directly and which invoke code. That affects security, latency, and billing.
Directly served static-asset requests are free and unlimited under the documented pricing. Requests that run your Worker count toward Worker usage. If you leave assets-first routing enabled, your code does not inspect every file request.
What Static Assets Supports—and Where It Has Limits
Workers Static Assets supports:
- Ordinary static websites.
- Single-page applications, where browser-side JavaScript handles much of the navigation.
- Sites generated into static files during a build.
- Frontends combined with APIs or server-side rendering, where code generates page content for a request.
- Custom headers, redirects, preview URLs, and configurable missing-page behavior.
For a single-page application, you can configure unknown routes to return index.html; for other sites, a proper “page not found” response may be more appropriate.
Published limits include one configured asset collection per Worker, 20,000 files per version on Workers Free, 100,000 on Workers Paid, and 25 MiB per file—roughly 26 MB. Larger files generally belong in something like R2.
Putting the Worker first adds code execution to the request path. Placement choices can matter too: Smart Placement, which can move execution closer to backend services, may add latency to asset requests routed through that code.
Workers also does not natively reproduce Pages’ /functions file-routing convention or all its branch controls. Application frameworks can provide routing instead.
For configuration details, see the Static Assets documentation.
Pages: A Site-Centered Publishing Workflow
Pages takes your built website files and deploys them onto Cloudflare’s network. You can:
- Connect GitHub or GitLab so code changes trigger builds.
- Create production and preview deployments tied to branches and pull requests.
- Upload files you have already built.
- Roll back to an earlier deployment.
A branch is a separate line of development; a pull request proposes merging changes. Preview deployments let you inspect those changes before publishing them.
For dynamic behavior, Pages Functions runs code on the Workers runtime. In its conventional setup, filenames inside /functions determine URL routes. For example, functions/users/[user].js can handle a user-specific path.
Functions can connect to services such as D1 and R2, so Pages is not limited to static sites.
Pages’ Trade-Offs
Pages is convenient for documentation, marketing sites, and frontends whose teams value its publishing workflow. But:
- Functions count toward Workers usage. The
_routes.jsonconfiguration controls which requests invoke them; avoid unintentionally running code for every static file. - A Pages project cannot directly act as a queue consumer or use Cron Triggers, which run code on a schedule. Workers also offers more comprehensive logging.
- Free-plan limits include 500 builds per month, a 20-minute build timeout, 20,000 files per site, and 25 MiB per file. Higher file-count limits are available on paid plans with the documented configuration.
- A Direct Upload project cannot simply be switched into a Git-integrated project later.
Pages retains some workflow advantages, including more granular branch-deployment controls and support for custom domains outside Cloudflare-managed zones.
Practical rule: evaluate Workers Static Assets first for a new project. Keep or choose Pages when its particular workflow solves a real need. The migration and feature comparison explains the differences.
Queues: Let Slow Work Happen Later
Suppose someone uploads a photo. Your application needs to create thumbnails, update a search index, and perhaps send a notification.
Making the person wait for every step would slow the response. Cloudflare Queues lets you hand off that work.
A queue is a managed message buffer: one component submits instructions, and another processes them later.
How a Message Moves Through a Queue
The basic sequence is:
- A producer—the code submitting work—sends a message.
- Cloudflare holds it in the queue.
- A consumer Worker receives a batch of messages and processes them.
- Successful messages are acknowledged, meaning processing is confirmed and they can be removed.
- Failed messages can be retried.
For a photo, the message might contain { photoId, userId }. The image itself stays in R2; the queue carries the instruction and identifiers. Individual messages are limited to 128 KB.
A producer might call await env.MY_QUEUE.send({...}). It should wait for that operation to succeed before telling you the job was accepted.
The consumer does not have to be a Worker: an application outside Cloudflare can pull messages over HTTP and acknowledge them.
The Essential Rule: Make Repeated Processing Safe
Queues uses at-least-once delivery. That means a message may arrive more than once, and delivery order is not guaranteed.
Your processing should therefore be idempotent: repeating the same operation should not create an unintended additional effect. Generating the same thumbnail twice may merely waste work; charging a customer twice is a serious error.
A common approach is an idempotency key, a unique job identifier used to recognize work already completed. For external effects such as payments, use mechanisms that safely prevent duplicates—not merely an unprotected “check, then act.”
By default, a failed batch is retried as a whole, though individual messages can be acknowledged or retried. A dead-letter queue can hold messages that exhaust their retries so you can investigate.
Queues is a reliable handoff mechanism, not permanent storage or a general scheduler. Documented message-retention limits are 24 hours on Workers Free and up to 14 days on paid plans. See how Queues works for details.
Is Cloudflare the Right Fit?
Cloudflare is compelling when you want to build an internet-facing application without assembling and operating a fleet of servers. Its appeal is the combination: website hosting, application code, storage, and background work connected through one platform.
Before choosing it, check:
- Runtime fit: Does your code and its dependencies work in Workers?
- Data behavior: What consistency and geographic placement does your application require?
- Workflow fit: Do Workers or Pages better match how you deploy?
- Total cost: Include databases, storage operations, queues, AI, and any containers—not just request handling.
Workers has a limited free plan, and its paid plan starts at $5 per month per account, with usage charges beyond included allowances. Other products have their own pricing. Limits and prices can change, so verify the current pricing before committing.
The central idea is simple: Cloudflare no longer just sits in front of your application. It can host much of the application itself.