Cloudflare Workers: Edge application platform

Learn how Cloudflare Workers runs application code, connects to storage and supports APIs and background work, distinct from simply proxying a website.

Updated 8 September 2026

What Cloudflare Workers provides

Cloudflare Workers is a serverless application platform. It can serve frontend assets, run backend APIs and connect to data services. Its ecosystem also includes scheduled work, queues and workflows, so a project can include more than the handler for a public web request.

For example, an application could serve its interface and API from Workers while storing uploaded files and structured records in separate services. Each part still needs a clear data model and access policy.

Application code and storage services

Workers bindings connect code to platform resources. Cloudflare offers different storage models, including object storage, SQL data, key-value data and stateful coordination. Those products solve different problems and should not be treated as interchangeable containers for all data.

A profile image and an account balance have different access and consistency requirements. Choose the storage model around the operation rather than selecting it only because it is close to the runtime.

Durable Objects, Queues and Workflows

Durable Objects adds state and coordination for applications such as shared sessions and real-time collaboration. Queues decouples incoming work from its consumers, and Workflows manages durable multi-step jobs. These make the Workers ecosystem suitable for applications with background and stateful behaviour, not only stateless HTTP handlers.

AI, media and the wider developer ecosystem

Workers applications can call Workers AI for model execution, use Vectorize for vector search and route model traffic through AI Gateway. Images and Stream handle specialized media workflows. Containers and Workers for Platforms address other execution and platform-building use cases. Each adds a distinct capability around the runtime rather than changing what a basic Worker automatically includes.

Planning a Workers deployment

Verify runtime compatibility and limits for the libraries and workload being deployed. Also check the location and latency of external dependencies; an application can still wait on a distant service.

Test error paths, background retries and configuration across environments. A successful request does not verify that queued work will complete or that a preview environment is isolated from production data.

How DNSTrace.dev detects Cloudflare Workers

Detection correlates independent public signals. A single match is reported as strong evidence; agreement between a response header and the announcing network is reported as confirmed.

CNAME targets under workers.dev — The default Worker hostname a custom domain replaces.
cf-ray with a Cloudflare server header — Present because a Worker answers from the same edge as the rest of Cloudflare's network.
AS13335 — The Cloudflare autonomous system announcing the address.

What a detection proves

The hostname is served from Cloudflare's network, and a workers.dev mapping indicates a Worker.

What it does not prove

A Cloudflare edge alone does not mean a Worker. A proxied site on any origin produces the same cf-ray and server header, which is why the workers.dev target is the distinguishing signal.

Common questions about Cloudflare Workers

Does a site using Cloudflare’s CDN also use Workers?

Not necessarily. The CDN can proxy an application hosted elsewhere. Workers is a separate execution platform, and its use must be established independently.

How is this different from a proxied site?

A proxied site keeps its own origin behind Cloudflare. A Worker is the application, so there is no separate origin to reach.

Is Cloudflare Pages reported separately?

Pages and Workers are different products and a shared edge signal identifies neither on its own. Only the default hostname distinguishes them.

Frontend application platform