Cloudflare Workers let you run JavaScript at the edge - on servers in over 300 cities worldwide, as close to your users as physically possible. No containers, no servers to manage, no cold starts worth worrying about. You write a function, deploy it, and it runs globally in seconds. If you have ever set up a VPS, configured Nginx, and dealt with SSL certificates just to serve a simple API, Workers will feel like a revelation.

What Workers Actually Are

A Worker is a JavaScript (or TypeScript, Rust, Python) function that intercepts HTTP requests and returns responses. It runs on Cloudflare's network using V8 isolates - the same JavaScript engine that powers Chrome, but without the full browser overhead. Each request gets its own lightweight execution environment that spins up in microseconds.

Workers are not traditional serverless functions like AWS Lambda. There are no cold starts that matter (sub-millisecond), no regional deployments to configure, and the free tier gives you 100,000 requests per day. For most side projects and small businesses, that free tier is more than enough.

Setting Up Wrangler

Wrangler is Cloudflare's CLI for creating, developing, and deploying Workers. Install it globally:

npm install -g wrangler

Log in to your Cloudflare account:

wrangler login

This opens your browser to authenticate. Once done, create a new project:

wrangler init my-first-worker
cd my-first-worker

You get a project with a wrangler.toml config file and a src/index.js (or .ts) entry point. That is the entire project structure. No framework, no build pipeline, no configuration maze.

Hello World Worker

Open src/index.js. A Worker exports a fetch handler that receives a Request and returns a Response:

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

    if (url.pathname === "/api/hello") {
      return new Response(
        JSON.stringify({ message: "Hello from the edge!" }),
        {
          headers: { "content-type": "application/json" }
        }
      );
    }

    return new Response("Not found", { status: 404 });
  }
};

Run it locally:

wrangler dev

Open http://localhost:8787/api/hello and you see your JSON response. The local dev server uses the actual Workers runtime, so what works locally will work in production.

Adding KV Storage

Workers KV is a global key-value store. It is eventually consistent (reads are fast everywhere, writes propagate globally within seconds) and perfect for configuration, cached data, and simple state.

Create a KV namespace:

wrangler kv namespace create MY_DATA

Add the binding to wrangler.toml (Wrangler prints the exact config to copy). Then use it in your Worker:

export default {
  async fetch(request, env) {
    const url = new URL(request.url);

    if (url.pathname === "/api/visits") {
      const count = parseInt(await env.MY_DATA.get("visits") || "0");
      await env.MY_DATA.put("visits", String(count + 1));
      return new Response(
        JSON.stringify({ visits: count + 1 }),
        { headers: { "content-type": "application/json" } }
      );
    }

    return new Response("Not found", { status: 404 });
  }
};

KV reads are fast (cache-speed), writes are durable and globally distributed. For most use cases - counters, feature flags, user settings, cached API responses - KV is all you need.

Deploy to Production

When you are ready:

wrangler deploy

That is it. Your Worker is live on a workers.dev subdomain within seconds. Every Cloudflare data center in the world is serving your code. You can check deployment status and logs in the Cloudflare dashboard or use wrangler tail to stream live logs from the command line.

Custom Domains

To serve your Worker from your own domain, add a route in wrangler.toml:

[routes]
pattern = "yourdomain.com/*"
zone_name = "yourdomain.com"

Or use the Cloudflare dashboard to add a custom domain to your Worker. If your domain is already on Cloudflare, the DNS is handled automatically. SSL is free and automatic. No certificate management, no renewals, no configuration.

Why Workers Over Traditional Hosting

For many projects, Workers replace the entire stack. Here is what you do not need anymore:

• No web server (Nginx, Apache) - the Worker IS the server
• No container orchestration - no Docker, no Kubernetes
• No SSL configuration - automatic and free
• No CDN setup - code runs at the edge by default
• No scaling concerns - Cloudflare handles millions of requests automatically
• No server maintenance - no OS updates, no security patches

The tradeoffs are real: Workers have a 128MB memory limit, CPU time is capped per request, and you are locked into Cloudflare's ecosystem. For simple APIs, static sites with dynamic elements, redirects, A/B testing, and edge middleware, those limits rarely matter.

What to Build Next

Now that you have the basics, try building a URL shortener with KV, an API proxy with caching, a contact form handler, or a full website (like this one). Workers pair well with D1 (Cloudflare's SQLite database), R2 (object storage), and Durable Objects (for stateful applications). The ecosystem keeps growing, and the developer experience keeps getting better.

Check out our deeper Workers guide for more advanced patterns, or explore the official docs for the complete API reference.