Edge Computing with Cloudflare Workers: A Practical Guide for Devs

By 2026, the conversation about web performance has moved. It no longer happens in regional data centers — it happens at the edge, in the hundreds of POPs scattered across major cities, where the distance between a user and the code answering their request is measured in tens of milliseconds, not hundreds. Cloudflare Workers is one of the most mature platforms in this movement, running in over 330 cities worldwide. For developers coming from the traditional world of Node.js servers in containers, working at the edge requires unlearning a few things and learning others: there is no persistent filesystem, no long-running process, and every request is an isolated universe. This guide shows what actually matters in practice, with real examples.

I deployed my first Worker to production about 14 months ago, as a JWT authentication layer in front of an internal API running in São Paulo. The concrete problem was simple and annoying: users in Japan and Australia suffered 380ms just to hit a middleware validating a token. Moving that validation to Workers dropped the global p95 from 612ms to 94ms, without changing a single line of the original API. I was surprised at how little code it took — fewer than 80 lines — and at how much the "everything is stateless and ephemeral" mental model forced me to simplify the design. Today I have three Workers in production, all on the Bundled plan at five dollars a month, processing around 4 million requests monthly.

What edge computing actually means

Edge computing is the idea of running code as close as possible to the end user, instead of concentrating everything in a central data center. Instead of a request from Lisbon travelling 9 thousand kilometers to Virginia, it hits a POP in Lisbon itself, where the code is already pre-deployed. This reduces latency, lowers origin load and, when done well, makes applications perceptibly faster — especially on mobile networks where RTT dominates everything.

But "edge" has become a generic term. In practice, three models coexist: traditional CDN (caches static assets, little logic), edge functions (runs JavaScript/WASM in response to requests), and edge state (stores data close to the user, like KV and Durable Objects). When we talk about Cloudflare Workers, we are looking at the last two — and that is where things get interesting.

Workers vs Vercel Edge vs Netlify Edge vs Deno Deploy

The edge functions market matured fast. Today, besides Cloudflare, Vercel, Netlify and Deno Deploy all offer serious runtimes. Each has its particularities, and choosing involves trade-offs that go beyond price.

Cloudflare's most obvious advantage is POP density: 330+ versus Vercel's 18 (which under the hood uses AWS Lambda@Edge in many regions). That translates into lower latency at the tail of the distribution, where users in under-served countries usually suffer. The downside is that framework integration for things like Next.js is a bit more manual — though it has improved significantly with the @opennextjs/cloudflare adapter and OpenNext.

Anatomy of a Worker

A Worker is, at its core, a handler that receives a Request and returns a Response, using APIs that follow Web standards (Fetch, Streams, Crypto). You do not have fs, you do not have Node's http, you do not have a long-running event loop. Each invocation is an isolate that lives for the request lifetime.

export default {
  async fetch(request, env, ctx) {
    const url = new URL(request.url);
    if (url.pathname === "/api/hello") {
      const cached = await env.KV.get("greeting");
      const body = cached ?? "Hello from the edge";
      if (!cached) {
        ctx.waitUntil(env.KV.put("greeting", body, { expirationTtl: 60 }));
      }
      return new Response(JSON.stringify({ body }), {
        headers: { "content-type": "application/json" },
      });
    }
    return new Response("Not found", { status: 404 });
  },
};

Notice three important things: env carries bindings (KV namespace, secrets, R2 buckets), ctx.waitUntil extends the lifecycle for non-blocking async work after the response, and every I/O API is based on fetch and Promises. This model eliminates an entire category of bugs related to shared state between requests, but requires discipline when you actually need persistence.

KV, R2, D1 and Durable Objects: when to use each

One of Cloudflare's most important moves in the last two years was turning Workers into a full platform with native storage primitives. Each solves a specific problem:

• KV: eventually consistent key-value store, very fast reads (edge cached), slower writes. Ideal for configs, feature flags, cached sessions. Watch out for write propagation, which can take up to 60 seconds to spread globally.
• R2: S3-compatible object storage, with no egress fees. Perfect for images, user uploads, backups. In projects that served video over AWS, moving to R2 cut the bill by 70-90%.
• D1: SQLite-based serverless SQL database with global replicas. Mature in 2026 and able to fit many small-to-medium OLTP use cases. Great for apps that do not need full Postgres.
• Durable Objects: the most underrated piece of the platform. Provides strong consistency, coordination, and state with geographic locality — useful for chat rooms, real-time collaboration, global rate limiting, or distributed counters.

In a recent project, I built a distributed rate limiter using Durable Objects: each API key has its own object, living in a fixed region, keeping the sliding window consistent even if requests hit different POPs. Trying that with a central Redis would cost latency on every request; with DO, only the first request of the window needs to cross the ocean.

Use cases that make sense (and those that don't)

Not every nail fits this hammer. Workers shines in scenarios like:

• Authentication and authorization before the origin (JWT validation, header rewriting).
• A/B testing and feature flagging with runtime routing.
• Response transformations (HTMLRewriter, i18n, image optimization).
• Latency-critical APIs with light state (KV/D1).
• Smart proxies, custom WAF, bot detection.
• High-volume webhooks with quick processing.

On the other hand, avoid Workers for: long jobs that exceed CPU time, apps that depend on specific Node libraries (though the nodejs_compat flag has improved a lot), processing large files in memory, or anything needing arbitrary TCP sockets. For those, use Containers on Cloudflare (released in 2025) or keep a traditional origin.

Real-world pricing and limits

The free plan gives you 100k requests per day and 10ms of CPU per request, which already covers many side projects. The paid plan (Bundled, US$ 5/month) includes 10 million requests and 30 seconds of CPU per request — enough for serious applications, including production. Beyond that, it's US$ 0.30 per million extra requests. The trick is that CPU time is not wall time: a Worker waiting on an upstream fetch for 2 seconds only consumes a few milliseconds of CPU.

In my stack, Workers sits at a fixed 5 dollars a month and has never surprised me on the bill. For a small dev team, that is liberating compared to the anxiety of managing auto-scaling on Kubernetes. I recommend reading the official pricing documentation before planning heavy architectures, because storage and egress for R2/D1 have their own tables.

Deploy and observability

The official CLI is wrangler, which today covers deployment, local dev (via miniflare), log tailing, bindings and D1 migrations very well. GitHub Actions pipelines end up being 3-4 lines. For observability, I recommend enabling Workers Logs and integrating with Baselime or Axiom — latency measured at the POP itself helps detect regional issues before users complain. A great reference is the official Cloudflare blog, which publishes honest post-mortems about incidents and deployments. You can also compare with Vercel's edge functions docs to understand where each platform draws its lines.

Conclusion

After more than a year running Workers in production, my opinion is that the platform has become the default choice for new APIs with global traffic that don't need Postgres or long-running processes. The 5-dollar ceiling covers more than it seems, deployment is the fastest I have ever used, and the combination with R2 + D1 removes the infrastructure management headache. Weak spots exist — debugging Durable Objects is still harder than it should be, and some framework ecosystems need adapters — but none are deal-breakers. If you are starting a new project in 2026 and the first tool you think of is Kubernetes or Lambda, I recommend trying Workers for a week. The curve is short, and the savings in operational time outweigh any initial surprise. For those wanting to go deeper, the official resources at developers.cloudflare.com/workers and the Durable Objects docs are the best starting points today.