Workers — Edge Computing — Cloudflare Demo Shop

What is the challenge?

Why is your code running in one region when your users are everywhere?

Centralized serverless (AWS Lambda, GCP Functions) runs in a single region. Users in other regions pay round-trip latency on every request. Cold starts add hundreds of milliseconds because containers have to spin up. Pricing models charge for memory you reserved, not memory you used. Building globally-fast applications means juggling multi-region deployments, custom edge caching, and complex routing — when really you just want to run a function close to the user.

Architecture

How it fits together

Diagram coming soon

Architecture diagram for this solution will be added here.

Cloudflare's Solution

How Cloudflare solves it

Run in 330+ locations automatically. Deploy once, and your Worker runs in every Cloudflare data center worldwide. The request goes to the nearest one. No regions to pick, no replication to manage.
V8 isolates instead of containers. Workers run in V8 isolates — the same sandbox model Chrome uses for tabs. Cold start is measured in single-digit milliseconds (vs hundreds for container-based serverless). No cold start tax on irregular traffic.
JavaScript, TypeScript, Python, WASM. Native runtime for JS and TypeScript. Python via Pyodide. Any language that compiles to WebAssembly (Rust, Go, C++, etc.) runs unmodified.
First-class platform integrations. Workers bind directly to R2, KV, D1, Durable Objects, Workers AI, Queues, and Vectorize — no SDK auth, no HTTP overhead. Sub-millisecond access to platform storage.
Pay per request. $0.30 per million requests on the paid plan. No idle compute charges. Free tier covers 100k requests/day forever, which is enough for many real applications.

FAQ

Common questions

What can't I do in a Worker?

Workers can't open raw TCP sockets to non-HTTP services (use Hyperdrive for databases, TCP/UDP sockets for specific cases). They have a 30s CPU time limit per invocation (configurable up to 5 min on paid plans). They can't write to a filesystem (use R2 or KV). Outside those edges, anything you'd build on Node.js you can build on Workers.

How is this different from AWS Lambda@Edge or CloudFront Functions?

Lambda@Edge runs in CloudFront regional edge caches (a dozen or so locations) and has multi-second cold starts. CloudFront Functions runs everywhere but only allows 1ms of CPU and very limited capabilities. Workers runs everywhere AND has 30s of CPU budget AND has full JS runtime AND has bindings to KV/R2/D1/AI. It's a category beyond what edge functions offered until recently.

Can Workers talk to my existing origin or database?

Yes. Workers can fetch any URL (your origin in AWS, your SaaS API, anywhere). For databases, Hyperdrive provides pooled, accelerated connections to Postgres/MySQL from Workers without exhausting connection limits.

What about long-running tasks or scheduled jobs?

Workflows (durable execution) handle long-running multi-step tasks with automatic retries. Cron Triggers run Workers on a schedule. Queues let one Worker enqueue work that another Worker consumes. All built into the platform.

Let's Test!

Try it live

This site itself is built on Workers/Pages — but here's a quick LLM call running via Workers AI through this site's existing Worker pipeline.

Send a prompt below. With RAG off, the request goes browser → /api/chat → AI Gateway → Workers AI (Llama 3.3 70B). With RAG on, it goes browser → /api/aboutme-rag → AI Search (AutoRAG) → Vectorize + R2 → Workers AI.

Enable RAG (AutoRAG “About Me”) Grounds answers in the private /aboutme source doc indexed by AI Search. Try “What is Remy Calder's internal codename?” with it off, then on.

Prompt

Routed via AI Gateway Routed via AI Search (AutoRAG)

Error

Dive Deeper

Docs & blogs

Documentation

Blogs

← Back to all solutions