Skip to content
Blog

Edge Computing: Deploying Globally with Cloudflare Workers

Serverless JavaScript that runs in 300+ cities, before it even reaches your origin. How to build, bind, and scale applications with Cloudflare Workers.

Published on • August 10, 2026

AI Assistant

“Move compute closer to the user” sounds like a slogan until you feel the difference: an API that answers in 20ms because the code ran in the data center across the street from your user, not the one across the ocean. Cloudflare Workers is a serverless runtime that executes your JavaScript on Cloudflare’s global network — 300+ cities — so every request is handled near its source, with zero infrastructure to manage.

In this post, you will learn what runs on the Workers edge, how to build and deploy a Worker with Wrangler, how bindings give you storage and AI with a few lines of code, and the patterns for routing, caching, and scheduled jobs.

What makes a Worker different

Workers run on the V8 runtime — JavaScript and WebAssembly — deployed to Cloudflare’s network, not a single region. Key properties:

  • No cold-start regions to pick. Every request runs at the nearest edge. There is no “us-east-1” to choose and no server to provision.
  • HTTP-native. A Worker is a function that receives a Request and returns a Response — the entire Web platform API is available.
  • Durable state on demand. Stateless by default, with Durable Objects for coordinated state and bindings for KV, D1, R2, and Vectorize.

The simplest possible Worker:

export default {
  async fetch(request: Request): Promise<Response> {
    return new Response("Hello, edge!", {
      headers: { "content-type": "text/plain" },
    });
  },
};

Build and deploy with Wrangler

Wrangler is the Workers CLI — it scaffolds, deploys, and runs your worker locally:

npm create cloudflare@latest my-worker -- --type hello-world
cd my-worker
wrangler dev      # local dev server
wrangler deploy   # deploy to the global network

wrangler.toml (or wrangler.jsonc) is the config file — where bindings, cron triggers, and routes are declared:

name = "my-worker"
main = "src/index.ts"
compatibility_date = "2026-08-01"

[vars]
ENVIRONMENT = "production"

[[d1_databases]]
binding = "DB"
database_name = "app-db"
database_id = "<your-database-id>"

Bindings: storage and services in a few lines

Bindings are the killer feature — they attach Cloudflare services to your Worker as variables with zero boilerplate:

  • KV — low-latency key-value storage, great for config, redirects, and cache-aside data.
  • D1 — a serverless SQLite database for relational data.
  • R2 — S3-compatible object storage with zero egress fees.
  • Vectorize — a vector database for semantic search.
  • Workers AI — serverless GPUs for running models.

A worker that uses KV and D1 together:

export default {
  async fetch(request: Request, env: Env): Promise<Response> {
    const url = new URL(request.url);
    const slug = url.pathname.slice(1);

    // Try KV first (fast, edge-cached)
    const cached = await env.KV.get(`page:${slug}`);
    if (cached) return new Response(cached, { headers: { "content-type": "text/html" } });

    // Fall back to D1 (relational)
    const { results } = await env.DB.prepare(
      "SELECT * FROM pages WHERE slug = ?",
    ).bind(slug).all();

    if (!results[0]) return new Response("Not found", { status: 404 });

    const html = render(results[0]);
    await env.KV.put(`page:${slug}`, html, { expirationTtl: 300 });
    return new Response(html, { headers: { "content-type": "text/html" } });
  },
};

Routing, middleware, and the request lifecycle

A Worker is a fetch handler, but production workers usually branch on the request: static assets, an API path, an auth check, then fall through. The platform also gives you access to the full Request/Response lifecycle — you can inspect, cache, or rewrite anything.

export default {
  async fetch(request: Request, env: Env): Promise<Response> {
    const url = new URL(request.url);

    // CORS preflight for the API
    if (request.method === "OPTIONS") {
      return new Response(null, {
        headers: {
          "access-control-allow-origin": "*",
          "access-control-allow-methods": "GET, POST, PUT, DELETE",
          "access-control-allow-headers": "content-type",
        },
      });
    }

    if (url.pathname.startsWith("/api/")) {
      return handleApi(request, env);
    }

    return env.ASSETS.fetch(request); // serve static assets
  },
};

Cron triggers and background work

Workers aren’t only request handlers. Cron triggers fire a scheduled handler on a schedule — useful for cleanup, aggregation, or pre-warming caches:

export default {
  async scheduled(controller: ScheduledController, env: Env): Promise<void> {
    await env.DB.prepare("DELETE FROM sessions WHERE expires_at < now()").run();
    console.log("purged expired sessions at", new Date().toISOString());
  },
};

Declared in config:

[[triggers]]
crons = ["0 3 * * *"]   # daily at 03:00 UTC

Smart Placement and global persistence

Two options worth knowing as you scale:

  • Smart Placement moves a Worker closer to the backend it calls (a database or origin) rather than the user, when the bottleneck is an upstream API — cutting latency when your compute waits on a faraway origin.
  • Durable Objects give you strongly-consistent, coordinated state at the edge — for real-time coordination, rate limiting, or a single source of truth that many Workers share. Use them when you need “one of these, globally” rather than “a copy of this, everywhere.”

Putting It All Together

A complete example — a Worker with static assets, a KV-cached D1-backed API, CORS handling, and a scheduled cleanup — is in this repository. Clone it, run wrangler dev, add the bindings via wrangler d1 create, then wrangler deploy and hit the API from anywhere.

Conclusion & Next Steps

You can now deploy a Worker to the edge: you understand the request lifecycle, how bindings wire in KV, D1, R2, and Vectorize, how cron triggers run background jobs, and when Smart Placement or Durable Objects make sense. Next steps: add Workers AI for an inference endpoint, set up a custom domain with wrangler routes, and measure the latency difference between your origin and the edge — it’s usually dramatic.

References / Sources

cloudflare edge-computing workers serverless web-development