Cloudflare Workers in practice: your code at the network edge

For years, web architecture looked the same: the user’s browser on one side, a server (or the cloud) on the other, and hundreds or thousands of kilometres of cable in between. Edge computing turns this around: code runs not in one data centre but in hundreds of locations around the world, as close to the user as possible. Cloudflare Workers is the most popular and, in our opinion, the most mature implementation of this idea. In this article we show how Workers work, how to write and deploy your first script and what we use them for in everyday projects.

What are Cloudflare Workers?

Workers is a serverless platform running in more than 300 locations of the Cloudflare network. When a user in Warsaw sends a request to your application, the code runs at the Warsaw point of presence, not in a data centre in Frankfurt or Virginia. The result: latency measured in single milliseconds.

A technical detail that sets Workers apart from classic serverless functions (AWS Lambda, Google Cloud Functions): instead of containers, Cloudflare uses V8 isolates, the same mechanism the Chrome browser uses to separate tabs. An isolate starts in a fraction of a millisecond, so the “cold start” problem, which can add a second of latency in Lambda, practically does not exist here. The price is a few limitations: the code must be JavaScript/TypeScript (or compile to WebAssembly), and instead of the Node.js API we get the standard Web APIs: fetch, Request, Response, URL, crypto.

The programming model: everything is a request

In its simplest form, a Worker is a function that receives a Request object and must return a Response object. A minimal example:

export default {
  async fetch(request, env, ctx) {
    return new Response("Hello from the edge!", {
      headers: { "content-type": "text/plain; charset=utf-8" }
    });
  }
};

If you have ever written frontend code using fetch, you will feel right at home: these are exactly the same interfaces, just on the other side of the connection. A Worker can handle the request entirely by itself, modify it and pass it on to your server (proxy mode), or call any external API itself.

Your first project in 5 minutes

The tool for working with Workers is Wrangler. We create a new project with a single command:

npm create cloudflare@latest my-worker
cd my-worker
npx wrangler dev      # local development environment
npx wrangler deploy   # deploy to production

wrangler dev starts a local server that simulates the edge environment (with hot reload), and wrangler deploy publishes the code globally: within a dozen or so seconds the script is running all over the world at a *.workers.dev address or under your own domain connected to Cloudflare.

What do we use Workers for in practice?

1. Security headers and small fixes without touching the backend

A classic scenario: the website runs on shared hosting or on an old system where changing the server configuration is a hassle. A Worker can add headers to every response:

export default {
  async fetch(request) {
    const response = await fetch(request);
    const fresh = new Response(response.body, response);
    fresh.headers.set("Strict-Transport-Security", "max-age=31536000");
    fresh.headers.set("X-Content-Type-Options", "nosniff");
    fresh.headers.set("Referrer-Policy", "strict-origin-when-cross-origin");
    return fresh;
  }
};

2. Redirects and URL clean-up

Did a store migration change the URL structure? Instead of maintaining hundreds of rules in .htaccess, the redirect logic can live in a Worker, with the full power of JavaScript: redirect maps, regular expressions, rules depending on country or device.

3. An API proxy with a hidden key

The frontend needs data from a paid API, but the key must not be exposed in the browser. A Worker acts as a secure intermediary:

export default {
  async fetch(request, env) {
    const url = new URL(request.url);
    const target = "https://api.example.com" + url.pathname;
    return fetch(target, {
      headers: { "Authorization": "Bearer " + env.API_KEY }
    });
  }
};

The key goes into an environment variable (wrangler secret put API_KEY) and never leaves the Cloudflare infrastructure.

4. A/B tests without page flicker

Classic A/B tools swap content with JavaScript after the page has loaded, so the user sees a “jump”. A Worker can split traffic into variants before the response even leaves the Cloudflare network: it assigns a variant, saves it in a cookie and serves the right version from the first byte.

5. Geographic personalisation

Every request carries a request.cf object with information about the user’s country, city and time zone. Switching the currency, language or banner content for visitors from another country takes literally a few lines.

Limits and costs

The free plan allows 100,000 requests a day with a limit of 10 ms of CPU time per request, which is more than enough for redirects, headers or a simple proxy. The paid plan (5 USD a month) gives 10 million requests and a CPU limit of tens of milliseconds, enough even for rendering pages or processing data. An important nuance: what counts is CPU time, not waiting time; while a Worker waits for a response from an external API, the meter is stopped.

What can’t Workers do on their own?

By definition, an isolate remembers nothing between requests: there is no disk and no shared memory. For storing state, Cloudflare offers separate services that are attached to a Worker through so-called bindings: KV (a lightning-fast key-value store), R2 (S3-style object storage), D1 (SQLite at the edge) and Durable Objects (consistent state and coordination). We take a close look at the first two in the next articles of this series: KV first, then R2.

Summary

Cloudflare Workers take the whole burden of maintaining servers off your shoulders, while giving you something classic hosting cannot: code execution a dozen or so milliseconds from the user, in 300 places at once. At Okinet we use them both in large projects (APIs, personalisation, caching) and for small improvements to existing websites, because a few dozen lines at the edge often achieve what would otherwise require rebuilding the backend. If you are wondering whether edge computing makes sense for your project, let’s talk.