Workers
Cloudflare Workers runs your code in every one of Cloudflare's 300+ locations — with no servers to manage, cold starts measured in milliseconds, and a full platform of storage, databases, queues and AI inference attached.
Overview
Workers is Cloudflare's serverless compute platform. Instead of deploying an application to a region and making the world's users travel to it, you deploy to the network itself: the same code runs everywhere, and each user is served from the nearest city. There are no instances to size, no clusters to patch, and no capacity planning — scaling from zero to millions of requests is the platform's job.
Typical uses range from small edge logic (redirects, header rewriting, A/B testing, authentication in front of an existing origin) to complete applications and APIs built entirely on the platform, using its own storage and database services with no origin server at all.
Key capabilities
- JavaScript/TypeScript, and other languages via WebAssembly (Rust, C, and more), plus a Python runtime
- V8 isolate architecture: cold starts of a few milliseconds, thousands of times lighter than container-based serverless
- Workers KV — global key-value storage for config and cached data at edge read speeds
- R2 — S3-compatible object storage with zero egress fees
- D1 — serverless SQLite-based SQL database; Durable Objects — strongly consistent stateful coordination, with WebSocket support
- Queues, Cron Triggers and Workflows for background and scheduled processing
- Workers AI — run inference on open models (LLMs, embeddings, image) on Cloudflare's GPU network, plus Vectorize for vector search
- Pages/static assets hosting for full-stack apps, and Wrangler CLI with local dev, versioning and gradual deployments
How it works
Workers do not run in containers or virtual machines but in V8 isolates — the same sandboxing technology that separates tabs in Chrome. Thousands of isolates share a single process on each edge server, so starting your code means creating an isolate in a few milliseconds, not booting a runtime. This is why Workers have effectively no cold-start problem and why running in 300+ locations at once is economically feasible.
Your code is written against web-standard APIs — fetch, Request/Response, Web Crypto, streams — and deployed with the Wrangler CLI or CI/CD in seconds, globally and atomically. Bindings connect a Worker to platform resources (a KV namespace, an R2 bucket, a D1 database, an AI model) as capabilities injected into your code, without connection strings or credentials to manage.
State has a spectrum: KV for eventually-consistent global reads, D1 for relational data, R2 for objects, and Durable Objects when you need strong consistency or real-time coordination — each object is a single-threaded instance with its own storage, ideal for counters, game rooms, collaborative sessions and WebSocket fan-out.
Plans & licensing
Workers has its own pricing, independent of zone plans. The free tier (100,000 requests per day, with usable KV/D1/R2 allowances) suits development and small production workloads. The paid plan starts at a few dollars per month and bills by requests and CPU time, with the storage products metered separately; R2 charges nothing for egress. Enterprise agreements add commitments and support. As of 2026, subject to change — confirm current pricing with us.
Deployment with Integrity
As a certified Cloudflare partner for Central and Eastern Europe, Integrity delivers this product end to end — including a free pilot so you see results on your own traffic before committing. A typical rollout:
- Assessment. We identify candidate workloads — edge logic around an existing site, an API to accelerate, or a greenfield application — and map them to platform primitives.
- Free pilot. A first Worker ships on the free tier: typically edge middleware in front of your current origin or one self-contained API, proving latency and developer-experience gains.
- Architecture and build. Storage choices (KV/D1/R2/Durable Objects), CI/CD with Wrangler, staging environments and observability are set up; the workload is implemented.
- Hardening. Rate limiting, secrets management, gradual deployments and rollback procedures are configured; costs are modelled against real traffic.
- Launch. Traffic is shifted progressively with monitoring at each step.
- Handover or ongoing development. Your developers take the platform forward with our training, or Integrity builds and operates Workers-based services for you — start with the free pilot.
Ready to start? Contact us to arrange the free pilot.
FAQ
Do we have to move our whole application to use Workers?
No. The most common starting point is a Worker in front of your existing origin — handling redirects, caching logic, auth or personalisation — while the application stays where it is. Full migration is an option, never a prerequisite.
How do Workers compare to AWS Lambda?
Different architecture, different trade-offs: isolates start in milliseconds versus container cold starts, code runs in every city rather than a chosen region, and pricing includes no egress charges on R2. Lambda offers bigger memory/runtime envelopes for heavy batch compute. For latency-sensitive, globally-distributed request handling, Workers is usually the stronger fit.
Is the platform a lock-in risk?
The core APIs are web standards, R2 speaks the S3 API and D1 speaks SQLite's SQL dialect, which keeps application logic portable. Platform-specific services like Durable Objects would need re-architecting elsewhere — we flag those trade-offs explicitly during architecture design.