Cloudflare Workers
Cloudflare Workers run JavaScript/TypeScript at the edge — on Cloudflare's global network, physically close to users. That makes them ideal for request routing, caching, lightweight APIs, auth gateways, and content transformation, all with very low latency. The mental model: an edge gateway that shapes requests before they ever reach your origin.
Workers trade a restricted runtime and tight CPU/time limits for that proximity and scale. They're not the place for heavy compute or long-running background jobs — they're where you put fast, request-scoped logic in front of everything else.
TL;DR
- Workers are great for low-latency edge logic and caching.
- Not for heavy compute or long-running background jobs.
- Think "edge gateway" and "request shaping".
- Pair with edge storage (KV, Durable Objects, D1, R2) chosen by consistency needs.
Quick Example
A Worker is just a fetch handler — intercept, decide, respond or forward:
What Workers Are
- A serverless runtime deployed to Cloudflare's global network.
- Handle HTTP requests close to the user.
- Integrate with Cloudflare storage (KV, Durable Objects, D1, R2).
They're commonly used as an edge layer in front of an origin API to normalize requests, enforce auth, add caching, and cut origin latency and load.
Common Use Cases
- API gateway / auth layer — verify JWTs, enforce rate limits.
- Caching and request coalescing — serve hot responses from the edge.
- Rewrites and redirects — URL shaping without origin round-trips.
- A/B testing and feature flags at the edge.
- Image/HTML rewriting — transform content in flight.
See API Security.
Data Options
Cloudflare offers several storage primitives — pick by consistency and latency needs:
💡 Quick guide: read-heavy global config → KV; per-entity coordination needing strong consistency → Durable Objects; object-storage semantics → R2.
Caching
Edge caching dramatically cuts latency and origin load. The rules of thumb:
- Cache public, non-user-specific responses.
- Set cache keys intentionally — vary by language, region, or feature where it matters.
- Never cache sensitive or personalized responses.
See Caching.
Security Considerations
- Validate inputs — Workers often become your first line of defense.
- Apply rate limiting at the edge.
- Never log secrets.
- Treat edge code as production code — CI, tests, and rollbacks. A bug at the edge can break all traffic.
Operational Gotchas
- Runtime limits — strict CPU time and execution constraints.
- Vendor-specific APIs and a distinct debugging model.
- Consistency surprises — KV is eventually consistent; don't treat it as a transactional store.
Best Practices
- Keep Workers small and request-scoped — push heavy work to the origin or queues.
- Choose the right storage primitive for your consistency needs (see the table above).
- Keep edge code in source control with tests and staged (preview vs production) deploys.
- Fail open or closed deliberately — decide what a Worker does if a backend dependency is down.
Common Mistakes
Treating KV as strongly consistent
Doing heavy compute in a Worker
FAQ
How are Workers different from AWS Lambda?
Lambda runs in a full runtime in a specific region with cold starts and broad capabilities. Workers run a lightweight V8-isolate runtime at hundreds of edge locations with near-zero cold start, but with stricter CPU/time limits and a smaller API surface. Use Workers for fast, global, request-scoped logic; use Lambda for heavier, region-bound workloads. See Serverless Patterns.
When should I use KV vs Durable Objects vs D1?
KV for read-heavy, globally-replicated config where eventual consistency is fine. Durable Objects when you need a single authoritative, strongly-consistent point of coordination per key (counters, chat rooms, locks). D1 when you need relational SQL queries. R2 for object storage. Match the primitive to your consistency and query shape.
Can Workers replace my backend?
For some apps, yes — a Worker plus D1/KV/R2 can serve a complete lightweight API. But for heavy compute, long-running jobs, persistent connections, or complex relational workloads, Workers are better as an edge layer in front of a backend than a full replacement.
How do I handle secrets in a Worker?
Use Cloudflare's encrypted secrets/bindings (via wrangler secret put or the dashboard), accessed through the env object — never hardcode keys in the Worker source or log them. See Secrets Management.
Related Topics
- Cloud Computing — The hub
- Serverless Architecture Patterns — Designing for functions
- Vercel — Edge/serverless alternative
- API Security — Edge as a defense layer
- Caching — Edge caching strategies