# Cloudflare Workers: what they are and when to use them

> What a Cloudflare Worker is, which tasks it handles well (redirects, headers, small APIs, scheduled jobs) and when another option is better.

URL: https://codegea.com/en/cloudflare-workers-what-they-are-and-when-to-use-them
Node.js · 2026-10-19 · Derian Pinto

A Cloudflare Worker is a JavaScript function that runs on Cloudflare's network, close to whoever makes the request, without you having a server. You write it, deploy it and Cloudflare runs it every time a request arrives at the route you assigned.

A clarification before going on: codegea.com does not use Workers (from Cloudflare we use DNS and R2). This article is about judgment, backed by what Cloudflare's documentation says, so you know when it makes sense and when it doesn't.

## What a Worker looks like

The bare minimum:

```js
export default {
  async fetch(request) {
    const url = new URL(request.url);

    if (url.pathname === '/old-offer') {
      return Response.redirect('https://yourdomain.com/offer', 301);
    }

    return fetch(request);
  },
};
```

If the path is `/old-offer`, it answers with a 301 redirect. If not, it lets the request through to your site. It is deployed with Cloudflare's command-line tool, `wrangler`:

```bash
npx wrangler deploy
```

## What they are good for

- **Redirects and rewrites** before the request reaches your server. Useful when you have hundreds of old URLs after a migration.
- **Security or cache headers** added to every response, without touching the application.
- **Small APIs**: an endpoint that validates something, queries a service and returns JSON.
- **Protecting or transforming files** in an R2 bucket: checking a signature, resizing or serving with your own rules.
- **Scheduled tasks** (Cron Triggers): cleaning data, sending a notice, refreshing a cache.

## Their limits, which are real

Cloudflare's documentation lists restrictions worth keeping in mind:

- **CPU time.** On the free plan, 10 ms per request. On the paid plan, the default limit is much higher. Time spent waiting on the network or on other calls does not count as CPU.
- **Memory:** 128 MB per instance. With large files you have to work in a stream, not load them whole.
- **Subrequests.** Every `fetch()` or call to R2, KV or D1 counts, and there is a cap per invocation (50 on the free plan).
- **Daily requests.** On the free plan there is a maximum per day.
- **No traditional server.** It is not full Node.js; not every library works.

These numbers change, so check the current documentation before designing something that depends on them.

## When not to use them

- **Heavy CPU work:** processing large images, generating complex PDFs, long calculations. If it goes past the limit, Cloudflare cuts it off.
- **Long tasks:** scheduled jobs and queues have a maximum time.
- **Applications that depend on Node libraries** that don't run in this environment.
- **When you already have somewhere to run the code.** If your site is on Vercel, its functions solve almost everything a Worker would, without adding another platform. That is why on our site API routes live in Next.js.

## Workers and the rest of the series

Workers get along well with R2 and with D1, Cloudflare's SQLite database, which they connect to as *bindings*. If that path interests you, we talk about it in [which databases Payload CMS supports](/en/which-databases-payload-cms-supports), and about R2 in [R2 vs S3](/en/cloudflare-r2-vs-amazon-s3-for-website-images).

## Rule of thumb

Think of a Worker as **light glue** at the edge: redirect, watch, transform, notify. If what you need is the brain of your application, a server or your usual platform's functions are usually a better starting point.