Companies Using Cloudflare Workers

We detect Cloudflare Workers on 18,506 domains, including Charlotte Center for Literary Arts, Inc., Virgin holidays, Keyence Corp.. A detection means the technology is present on that domain, which for large organisations is often a single storefront or subdomain rather than a company-wide deployment. Among domains we matched to a company with a resolved industry, the most common is Retail (8.3%).

We detect 18,506 domains running Cloudflare Workers across our monthly crawl of live business domains. Company data could be matched for 8,757 of them (47.3%), and every company-size, industry and country breakdown on this page describes that matched subset rather than the full detected base. A further 6,373 domains carried a Cloudflare Workers detection previously and no longer do.

Cloudflare Workers holds 0.79% of the PaaS category, ranking #12. This is a share of the domains we detect running a platform in this category — not a share of all websites, and not a share of spending — so it is not directly comparable to figures published on other denominators.

The top alternatives to Cloudflare Workers include Amazon Web Services (39.98% market share), Vercel (16.64% market share), WordPress.com (8.24% market share), Azure (7.5% market share) — measured as a share of the domains we detect running a platform in this category.

United States leads with 3,824 matched Cloudflare Workers domains, followed by United Kingdom (661), Netherlands (385), Canada (377), India (324). These are counts within the 8,757 domains we could match to a company record, not the full detected base.

The most common company size is 1-10 employees, representing 60.23% of the Cloudflare Workers domains we could match to a company record and size — a subset of 8,757 matched companies, not of all 18,506 detected domains. This is followed by 11-50 employees (26.19%) and 51-200 employees (9.08%).

Among the Cloudflare Workers domains we could match to a company with a known founding date, the largest group was founded in the 2010s (40.75%), followed by the 2020s (25.93%). That matched subset is drawn from 8,757 companies and is not representative of all 18,506 detected domains. This suggests Cloudflare Workers is most popular among relatively young companies.

The ideal Cloudflare Workers customer is: Company Size: 1-10 employees, Location: US, UK, or Netherlands, Industry: Retail, Founded: 2010-2019, Company Age: 7-16 years old — based on our analysis of 8,757 enriched companies at TechnologyChecker.io.

Two signals, and both are optional for a working deployment. The first is a runtime declaration in the page HTML, a meta tag with name "runtime" and content "Cloudflare Workers". The second is a request from the page to a .workers.dev address. If a site runs a Worker on a route of its own domain and does not emit that meta tag, we cannot see it from outside, because the response looks like any other origin served through Cloudflare.

Because both detection signals are things a deployment does incidentally rather than necessarily. The standard production pattern, a Worker bound to a route on your own domain, emits neither. The scale of the gap shows in our own data: across every domain where we currently detect Workers, exactly 11 are on a workers.dev hostname, fewer than one in a thousand. Nearly the whole count therefore comes from sites that voluntarily advertise the runtime, which makes 18,506 a floor. We publish it as a floor rather than extrapolating a total we cannot support.

Because Workers and the platforms it would be compared against are mostly complements. Workers is edge compute that sits in front of an origin instead of replacing it, so running Workers and AWS together is a normal architecture rather than a migration in progress. Of the domains that have ever run both Workers and Amazon Web Services, 72.3% still run both, and for Vercel the figure is 81.1%. A corridor built from the remainder would describe sites dropping an edge layer while keeping their origin, which is not a vendor switch, so we left the section out rather than publish a competitive story the data does not support.

6,373 domains dropped a detection since we began tracking in March 2026, but 68.1% of those rows were seen exactly once. The equivalent figure is 47.4% on Cloudways, 54.8% on Supabase and 55.9% on Render, so Workers churns far more intermittently than its neighbours. The cause is the detection surface: a runtime meta tag appears only on the routes a Worker renders, so which pages a crawl lands on decides whether we see it that month. Most of that movement is our visibility changing, not sites leaving Workers.

Mostly an artefact. Only 11 of the domains we can size belong to companies of 10,001 or more employees, and 15 to the 5,001 to 10,000 band, against 4,967 in the 1 to 10 band. A large organisation running Workers correctly, bound to routes on its own domain, emits neither of our detection signals, so it never enters the table. The enterprise hits we do have are mostly single routes, such as flights.virginatlantic.com, resources.purolator.com and marketplace.k12.com, which is what surviving deployments look like rather than what enterprise adoption looks like.

No. In this data a detection is evidence of one route. Our company list is full of hosts like registrar.charlotte.edu, resources.purolator.com, marketplace.k12.com, academy.writer.com and help.xing.com rather than main corporate domains, because the routes most likely to declare a runtime are the standalone ones a single team built: a booking flow, an application portal, a docs site, a help centre. Read each row as one deployment, not as a company-wide platform decision.

workers.dev is the free hostname Cloudflare gives every Worker, in the form yourworker.youraccount.workers.dev, so you can call the code before wiring it to a domain. It is used mainly for development, previews and internal endpoints, and production sites normally move to a custom domain or a route. That is also why it is a weak detection signal: only 11 domains in our current Workers set are on workers.dev at all.

Yes. The Workers Free plan includes 100,000 requests per day at no cost, and the paid plan starts at $5 per month with 10 million requests included and additional requests billed at $0.30 per million (per developers.cloudflare.com/workers/platform/pricing). A free entry point is part of why the small-company skew on this page is so pronounced: 60.23% of the domains we can size have 1 to 10 employees.

Workers runs code in V8 isolates on Cloudflare's network, close to the visitor, and avoids the cold start a container-based runtime pays. Lambda runs containers in an AWS region you choose and supports a wider set of languages including Python, Java, Go and .NET, where Workers is JavaScript, TypeScript and WebAssembly. In practice they are not always alternatives: 72.3% of the domains that have ever run both Workers and Amazon Web Services still run both.

JavaScript, TypeScript and WebAssembly natively, which means Rust, C and C++ can run once compiled to Wasm, and Python is supported through the same route. The runtime is V8 rather than Node.js, though Cloudflare has added Node.js compatibility over time (per developers.cloudflare.com/workers). The runtime itself was open sourced as workerd under Apache 2.0 in September 2022 (per blog.cloudflare.com/workerd-open-source-workers-runtime).

workerd is the open source version of the runtime that powers Cloudflare Workers, released under Apache 2.0 in September 2022 (per blog.cloudflare.com/workerd-open-source-workers-runtime). It runs the same JavaScript and WebAssembly execution model locally or on your own infrastructure, which is mainly useful for local development, testing and self-hosting parts of a Workers application.

For a lot of workloads, yes. Workers handles routing, authentication, API endpoints and server-side rendering, and Cloudflare supplies the surrounding pieces: KV for key-value storage, R2 for object storage, D1 for SQL and Durable Objects for stateful coordination. Long-running or CPU-heavy work is the usual limit. Our data suggests most visible deployments are not doing this, though: with Shopify present on 26.55% of the Workers domains we can profile, the common pattern is a Worker in front of an existing platform rather than instead of a backend.

Workers KV is a globally distributed key-value store built for read-heavy access from Workers. Values are cached across Cloudflare's network so reads are fast wherever the Worker runs, at the cost of eventual consistency on writes. It suits configuration, feature flags, routing tables and cached content. For transactional or strongly consistent state, Durable Objects and D1 are the alternatives.

Pages is for deploying sites, with a Git-connected build step, preview deployments and static asset hosting. Workers is the compute layer that runs code on incoming requests. The two have converged, since Pages runs its dynamic parts on Workers and Workers can now serve static assets directly (per developers.cloudflare.com/workers). Our detection sees the runtime, not the product name you deployed through.

Yes, through Durable Objects, which give a WebSocket connection somewhere consistent to live. A Durable Object is a single addressable instance with its own storage, so it can coordinate many connected clients for chat, multiplayer, collaborative editing or live dashboards. A plain stateless Worker can accept a WebSocket but has nowhere to keep shared state.

The free plan allows up to 10 milliseconds of CPU time per invocation and the paid plan raises that to 30 seconds by default (per developers.cloudflare.com/workers/platform/limits). The limit counts CPU time, not wall-clock time, so waiting on a network request does not count against it. That distinction is why edge routing, redirects and personalisation fit comfortably while heavy computation does not.

Workers runs across Cloudflare's global network, which the company puts at more than 330 cities in over 120 countries (per cloudflare.com/network). Code is deployed to the whole network rather than to a region you pick, and a request executes at whichever location receives it. That is the main architectural difference from region-based serverless platforms.

No, and the distinction matters when reading reviews, since most Cloudflare reviews cover the CDN and security products rather than Workers. The CDN caches and serves content. Workers runs your own code on the request path. They are separate products on the same network, which is why Cloudflare appears on 77.33% of the Workers domains we can profile: an overlap that is close to definitional rather than a choice these teams made.

Retail leads at 8.30% (633 domains), then Real Estate at 4.92%, Software Development at 3.89% and Technology, Information and Internet at 3.26%. Retail Apparel and Fashion also makes the top ten at 2.24%. Retail ahead of software is the unexpected part, and the stack data agrees: Shopify runs on 26.55% of the Workers domains we can profile. These percentages describe the 8,757 domains we matched to a company record, not the full 18,506 detections.

Shopify appears on 26.55% of the Workers domains we can profile, which is the single most surprising row on this page. The likely reason is that merchants cannot change how a hosted storefront handles a request, so anything they need before the storefront responds has to live in front of it: redirects, geo and currency routing, A/B tests, bot rules and personalisation. That is a Worker's natural job, and it explains why Retail rather than Software Development tops the industry table.

Anything where work has to happen on the request path before an origin or platform responds: routing and redirects, authentication and token checks, A/B testing and personalisation, API gateways, image and content transformation, and server-side rendering close to the visitor. Our data reflects that. Storefronts, airline booking hosts such as flights.virginatlantic.com and flights.flyfrontier.com, and university portals such as apply.uopeople.edu are the recurring patterns.