Cloudflare Workers: Edge Computing for AI Applications

Every millisecond of latency costs you. In AI applications—where users expect instant responses and real-time interactions—the difference between a server in Virginia and one in your user's city can mean the difference between a seamless experience and an abandoned session.

This isn't theoretical. We run asabove.tech on Cloudflare Pages. Our voice agents process audio through Workers. Email routing happens at the edge. API endpoints respond in under 50ms globally. The infrastructure that would have required a team of DevOps engineers five years ago now deploys with a single command.

This guide is the practical walkthrough I wish I'd had—covering everything from your first "hello world" Worker to production deployments handling real traffic. We'll use actual code from our infrastructure, not sanitized examples. By the end, you'll understand not just how to use Workers, but when they're the right choice—and when they're not.

1. What Is Edge Computing and Why It Matters

Traditional cloud computing centralizes processing in a few massive data centers. Your server might be in us-east-1 (Virginia), and a user in Tokyo experiences 150ms+ of latency just from the physics of light traveling through fiber optic cables. That's before your application even starts processing.

Edge computing flips this model. Instead of users coming to your server, your code runs on servers distributed across the globe—as close to users as possible. Cloudflare operates 300+ data centers in 100+ countries. When a user in Tokyo makes a request, it's handled by a server in Tokyo. When someone in São Paulo requests the same endpoint, a server in São Paulo handles it.

Why This Matters for AI Applications

AI applications have unique latency requirements that make edge computing particularly valuable:

• Voice interfaces: Users expect responses within 200-300ms for natural conversation. Every millisecond of network latency compounds. Voice-to-text, AI processing, text-to-speech—each step adds latency. Starting with a 150ms network penalty makes responsive voice agents nearly impossible.
• Real-time features: AI-powered autocomplete, live translation, streaming responses—these require sub-100ms round trips to feel instantaneous.
• Cost optimization: Edge processing can filter, validate, and transform requests before they hit expensive AI APIs. Rejecting invalid requests at the edge saves API costs and reduces load on origin servers.
• Resilience: Edge networks absorb DDoS attacks, handle traffic spikes, and keep serving cached content even if your origin is down.

Edge Computing Trade-offs

Edge isn't magic. Understanding the trade-offs helps you architect correctly:

The key insight: edge is for request handling, not heavy computation. Use edge workers to route, validate, transform, cache, and respond quickly. Use traditional servers (or serverless functions with longer timeouts) for heavy lifting like AI inference.

2. Cloudflare Workers vs Traditional Hosting

Before diving into code, let's compare Workers to alternatives you might consider. Each has its place—the goal is choosing the right tool.

Decision Framework

Use this mental model when choosing:

3. Setting Up Wrangler CLI

Wrangler is Cloudflare's CLI for managing Workers. It handles local development, deployment, secrets, and configuration. Let's get it running.

Installation

# Install globally with npm
npm install -g wrangler

# Or use npx (no global install needed)
npx wrangler --version

# Authenticate with your Cloudflare account
wrangler login

The wrangler login command opens a browser window for OAuth authentication. After approving, Wrangler stores credentials locally and you're ready to deploy.

Project Structure

A typical Workers project looks like this:

Configuration: wrangler.toml

The wrangler.toml file is the heart of your Worker configuration:

# Basic configuration
name = "my-worker"
main = "src/index.ts"
compatibility_date = "2024-01-01"

# Account info (optional - defaults to authenticated account)
account_id = "your-account-id"

# Environment-specific settings
[env.production]
name = "my-worker-production"
route = "api.example.com/*"

[env.staging]
name = "my-worker-staging"
route = "staging-api.example.com/*"

# KV namespace bindings
[[kv_namespaces]]
binding = "CACHE"
id = "abc123..."

# Environment variables (non-secret)
[vars]
ENVIRONMENT = "development"
API_VERSION = "v1"

# Durable Objects
[[durable_objects.bindings]]
name = "SESSIONS"
class_name = "SessionManager"

# Workers AI
[ai]
binding = "AI"

Essential Commands

4. Your First Worker: Hello World to Production

Let's build a Worker from scratch, understanding each part along the way. We'll start simple and add complexity until we have something production-ready.

The Simplest Worker

export default {
  async fetch(request: Request): Promise<Response> {
    return new Response("Hello, World!");
  }
};

That's it. A Worker is an object with a fetch handler that receives a Request and returns a Response. The interface mirrors the web standard Fetch API—if you know how to use fetch() in the browser, you understand the basics.

Adding Request Handling

Let's make it actually do something useful:

export default {
  async fetch(request: Request): Promise<Response> {
    const url = new URL(request.url);
    
    // Route based on path
    switch (url.pathname) {
      case "/":
        return new Response("Welcome to the API");
      
      case "/health":
        return Response.json({ status: "healthy", timestamp: Date.now() });
      
      case "/echo":
        if (request.method !== "POST") {
          return new Response("Method not allowed", { status: 405 });
        }
        const body = await request.json();
        return Response.json({ received: body });
      
      default:
        return new Response("Not found", { status: 404 });
    }
  }
};

Adding Type Safety and Environment

Production Workers need type-safe access to bindings (KV, secrets, etc.):

// Define your environment bindings
interface Env {
  // Secrets (set via wrangler secret put)
  API_KEY: string;
  
  // KV namespaces
  CACHE: KVNamespace;
  
  // Environment variables (from wrangler.toml [vars])
  ENVIRONMENT: string;
  
  // Workers AI binding
  AI: Ai;
}

export default {
  async fetch(request: Request, env: Env, ctx: ExecutionContext): Promise<Response> {
    // Now you have type-safe access to all bindings
    const apiKey = env.API_KEY;
    const cached = await env.CACHE.get("some-key");
    
    return new Response(`Environment: ${env.ENVIRONMENT}`);
  }
};

A Production-Ready API Worker

Here's a more complete example with error handling, CORS, logging, and proper structure:

interface Env {
  API_KEY: string;
  CACHE: KVNamespace;
  ALLOWED_ORIGINS: string;
}

// CORS headers for browser requests
function corsHeaders(origin: string | null, allowedOrigins: string): HeadersInit {
  const allowed = allowedOrigins.split(",");
  const allowOrigin = origin && allowed.includes(origin) ? origin : allowed[0];
  
  return {
    "Access-Control-Allow-Origin": allowOrigin,
    "Access-Control-Allow-Methods": "GET, POST, OPTIONS",
    "Access-Control-Allow-Headers": "Content-Type, Authorization",
  };
}

// Error response helper
function errorResponse(message: string, status: number, headers: HeadersInit = {}): Response {
  return Response.json(
    { error: message, status },
    { status, headers }
  );
}

// Main handler
export default {
  async fetch(request: Request, env: Env, ctx: ExecutionContext): Promise<Response> {
    const url = new URL(request.url);
    const origin = request.headers.get("Origin");
    const cors = corsHeaders(origin, env.ALLOWED_ORIGINS);
    
    // Handle CORS preflight
    if (request.method === "OPTIONS") {
      return new Response(null, { status: 204, headers: cors });
    }
    
    try {
      // Route to handlers
      let response: Response;
      
      if (url.pathname === "/api/data") {
        response = await handleData(request, env);
      } else if (url.pathname.startsWith("/api/cache")) {
        response = await handleCache(request, env, url);
      } else {
        response = errorResponse("Not found", 404);
      }
      
      // Add CORS headers to all responses
      const newHeaders = new Headers(response.headers);
      Object.entries(cors).forEach(([key, value]) => newHeaders.set(key, value));
      
      return new Response(response.body, {
        status: response.status,
        headers: newHeaders
      });
      
    } catch (error) {
      console.error("Worker error:", error);
      return errorResponse("Internal server error", 500, cors);
    }
  }
};

// Handler functions
async function handleData(request: Request, env: Env): Promise<Response> {
  // Validate API key
  const authHeader = request.headers.get("Authorization");
  if (authHeader !== `Bearer ${env.API_KEY}`) {
    return errorResponse("Unauthorized", 401);
  }
  
  // Process request
  return Response.json({
    message: "Authenticated successfully",
    timestamp: new Date().toISOString()
  });
}

async function handleCache(request: Request, env: Env, url: URL): Promise<Response> {
  const key = url.pathname.replace("/api/cache/", "");
  
  if (request.method === "GET") {
    const value = await env.CACHE.get(key);
    if (!value) {
      return errorResponse("Not found", 404);
    }
    return Response.json({ key, value: JSON.parse(value) });
  }
  
  if (request.method === "POST") {
    const body = await request.json();
    await env.CACHE.put(key, JSON.stringify(body), { expirationTtl: 3600 });
    return Response.json({ success: true, key });
  }
  
  return errorResponse("Method not allowed", 405);
}

Deploy to Production

# Set your secret
wrangler secret put API_KEY
# Enter: your-secret-api-key

# Deploy
wrangler deploy

# Watch logs
wrangler tail

5. Cloudflare Pages for Static Sites

While Workers handle dynamic requests, Cloudflare Pages is optimized for static sites and frontend applications. It's what we use for asabove.tech—and it's remarkably simple for what it delivers.

Pages vs Workers: When to Use Which

Setting Up Pages

Option 1: Git Integration (Recommended)

1. Push your site to GitHub or GitLab
2. Go to Cloudflare Dashboard → Pages → Create a project
3. Connect your repository
4. Configure build settings (if using a framework)
5. Deploy

Every push to your main branch triggers a deployment. Pull requests get preview URLs. It's the simplest CI/CD setup possible.

Option 2: Direct Upload with Wrangler

# Deploy a directory directly
wrangler pages deploy ./dist

# Create a new project
wrangler pages project create my-site

# Deploy to specific project
wrangler pages deploy ./dist --project-name my-site

Build Configuration for Frameworks

Pages Functions: Adding Server-Side Logic

Pages supports "Functions"—Workers that run alongside your static site. Create a functions directory, and files become API endpoints:

export async function onRequest(context) {
  return new Response(JSON.stringify({
    message: "Hello from Pages Functions!",
    timestamp: new Date().toISOString()
  }), {
    headers: { "Content-Type": "application/json" }
  });
}

// Dynamic route: /api/users/123 → params.id = "123"
export async function onRequest(context) {
  const { params } = context;
  
  return new Response(JSON.stringify({
    userId: params.id,
    // In reality, fetch from database
    name: `User ${params.id}`
  }), {
    headers: { "Content-Type": "application/json" }
  });
}

Custom Domain Setup

1. In Pages project settings, go to "Custom domains"
2. Add your domain (e.g., asabove.tech)
3. If using Cloudflare DNS: automatic configuration
4. If using external DNS: add the provided CNAME record

6. Email Workers and Routing

One of Cloudflare's hidden gems: Email Routing with Workers. You can receive emails at your domain and process them with code—parsing, forwarding, triggering workflows, storing data.

Setting Up Email Routing

1. Enable Email Routing: In Cloudflare Dashboard, go to your domain → Email → Email Routing → Enable
2. Add DNS records: Cloudflare will prompt you to add MX records (automatic if using Cloudflare DNS)
3. Create catch-all rule: Route all addresses to a Worker

Basic Email Worker

name = "email-handler"
main = "src/index.ts"
compatibility_date = "2024-01-01"

# Enable email handling
[[email]]
enabled = true

import { EmailMessage } from "cloudflare:email";
import { createMimeMessage } from "mimetext";

interface Env {
  FORWARD_TO: string;
  KV_EMAILS: KVNamespace;
}

export default {
  async email(message: EmailMessage, env: Env, ctx: ExecutionContext) {
    // Parse email details
    const from = message.from;
    const to = message.to;
    const subject = message.headers.get("subject") || "(no subject)";
    
    console.log(`Email received: ${from} → ${to}: ${subject}`);
    
    // Get email body
    const rawEmail = await new Response(message.raw).text();
    
    // Store in KV for logging
    await env.KV_EMAILS.put(
      `email:${Date.now()}`,
      JSON.stringify({ from, to, subject, receivedAt: new Date().toISOString() }),
      { expirationTtl: 86400 * 30 } // 30 days
    );
    
    // Forward to destination
    await message.forward(env.FORWARD_TO);
  }
};

Advanced Email Handling

Here's a more sophisticated example with routing logic, auto-replies, and webhook triggers:

import { EmailMessage } from "cloudflare:email";
import { createMimeMessage } from "mimetext";

interface Env {
  // Forwarding destinations
  SUPPORT_EMAIL: string;
  SALES_EMAIL: string;
  DEFAULT_EMAIL: string;
  
  // Webhook for notifications
  WEBHOOK_URL: string;
  
  // Storage
  KV_EMAILS: KVNamespace;
}

// Route emails based on recipient address
function getDestination(toAddress: string, env: Env): string {
  const localPart = toAddress.split("@")[0].toLowerCase();
  
  const routes: Record<string, string> = {
    "support": env.SUPPORT_EMAIL,
    "help": env.SUPPORT_EMAIL,
    "sales": env.SALES_EMAIL,
    "contact": env.SALES_EMAIL,
    "info": env.DEFAULT_EMAIL,
  };
  
  return routes[localPart] || env.DEFAULT_EMAIL;
}

// Check if email looks like spam
function isLikelySpam(from: string, subject: string): boolean {
  const spamIndicators = [
    /\b(viagra|cialis|lottery|winner|prince|inheritance)\b/i,
    /^.{0,5}$/, // Very short subject
    /URGENT.*REPLY/i,
  ];
  
  return spamIndicators.some(pattern => pattern.test(subject));
}

// Send webhook notification
async function notifyWebhook(data: object, webhookUrl: string): Promise<void> {
  await fetch(webhookUrl, {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify(data)
  });
}

export default {
  async email(message: EmailMessage, env: Env, ctx: ExecutionContext) {
    const from = message.from;
    const to = message.to;
    const subject = message.headers.get("subject") || "(no subject)";
    
    console.log(`Processing: ${from} → ${to}: ${subject}`);
    
    // Spam check
    if (isLikelySpam(from, subject)) {
      console.log("Rejected as spam");
      message.setReject("Message rejected");
      return;
    }
    
    // Determine destination
    const destination = getDestination(to, env);
    
    // Log to KV
    const emailId = `email:${Date.now()}:${Math.random().toString(36).slice(2)}`;
    await env.KV_EMAILS.put(emailId, JSON.stringify({
      from,
      to,
      subject,
      destination,
      receivedAt: new Date().toISOString()
    }));
    
    // Send webhook notification (non-blocking)
    ctx.waitUntil(
      notifyWebhook({
        type: "email_received",
        from,
        to,
        subject,
        destination,
        id: emailId
      }, env.WEBHOOK_URL)
    );
    
    // Forward the email
    await message.forward(destination);
    
    console.log(`Forwarded to ${destination}`);
  }
};

Email Routing Patterns

7. KV Storage and Durable Objects

Edge workers are stateless by default—each request is independent. For persistence, Cloudflare provides two primary options: KV for simple key-value storage and Durable Objects for stateful, coordinated workloads.

Workers KV: Global Key-Value Storage

KV is eventually consistent, globally distributed key-value storage. Think of it as a global Redis with ~60-second eventual consistency.

Setting Up KV

# Create a namespace
wrangler kv:namespace create CACHE

# Create a preview namespace (for wrangler dev)
wrangler kv:namespace create CACHE --preview

# List namespaces
wrangler kv:namespace list

[[kv_namespaces]]
binding = "CACHE"
id = "abc123..."  # From create command output
preview_id = "def456..."  # From preview create output

Using KV in Your Worker

interface Env {
  CACHE: KVNamespace;
}

export default {
  async fetch(request: Request, env: Env): Promise<Response> {
    const url = new URL(request.url);
    
    // Simple get
    const value = await env.CACHE.get("my-key");
    
    // Get with type
    const jsonValue = await env.CACHE.get("my-json", "json");
    
    // Get with metadata
    const { value: val, metadata } = await env.CACHE.getWithMetadata("my-key");
    
    // Put with expiration
    await env.CACHE.put("temp-key", "temp-value", {
      expirationTtl: 3600 // 1 hour in seconds
    });
    
    // Put with metadata
    await env.CACHE.put("user:123", JSON.stringify({ name: "Alice" }), {
      metadata: { createdAt: Date.now(), version: 1 }
    });
    
    // Delete
    await env.CACHE.delete("old-key");
    
    // List keys (with prefix)
    const keys = await env.CACHE.list({ prefix: "user:", limit: 100 });
    
    return Response.json({ keys: keys.keys });
  }
};

KV Best Practices

• Use for read-heavy workloads: KV is optimized for reads. Writes propagate globally but aren't instant.
• Cache expensive computations: Store API responses, computed results, configuration that changes rarely.
• Set TTLs: Use expirationTtl for data that should expire. Prevents stale data buildup.
• Use prefixes for organization: user:123, cache:api:response. Makes listing and bulk operations easier.

Durable Objects: Stateful Edge Computing

Durable Objects are the answer to "but what if I need real state?" They provide:

• Single-threaded execution (no race conditions)
• Persistent storage local to the object
• WebSocket support (for real-time applications)
• Consistent state across requests

Each Durable Object has a unique ID and lives in one location. All requests to that object route to that location, ensuring consistency.

When to Use Durable Objects

Durable Object Example: Session Manager

export class SessionManager {
  state: DurableObjectState;
  sessions: Map<string, WebSocket> = new Map();
  
  constructor(state: DurableObjectState) {
    this.state = state;
  }
  
  async fetch(request: Request): Promise<Response> {
    const url = new URL(request.url);
    
    if (url.pathname === "/websocket") {
      return this.handleWebSocket(request);
    }
    
    if (url.pathname === "/broadcast") {
      const message = await request.text();
      this.broadcast(message);
      return new Response("Broadcasted");
    }
    
    return new Response("Not found", { status: 404 });
  }
  
  async handleWebSocket(request: Request): Promise<Response> {
    const upgradeHeader = request.headers.get("Upgrade");
    if (upgradeHeader !== "websocket") {
      return new Response("Expected WebSocket", { status: 400 });
    }
    
    const [client, server] = Object.values(new WebSocketPair());
    const sessionId = crypto.randomUUID();
    
    server.accept();
    this.sessions.set(sessionId, server);
    
    server.addEventListener("message", (event) => {
      // Handle incoming messages
      console.log(`Message from ${sessionId}: ${event.data}`);
      
      // Echo back or process
      this.broadcast(`[${sessionId}]: ${event.data}`);
    });
    
    server.addEventListener("close", () => {
      this.sessions.delete(sessionId);
      console.log(`Session ${sessionId} closed`);
    });
    
    // Store session count persistently
    await this.state.storage.put("sessionCount", this.sessions.size);
    
    return new Response(null, {
      status: 101,
      webSocket: client
    });
  }
  
  broadcast(message: string) {
    for (const [id, socket] of this.sessions) {
      try {
        socket.send(message);
      } catch (e) {
        this.sessions.delete(id);
      }
    }
  }
}

export { SessionManager } from "./session";

interface Env {
  SESSIONS: DurableObjectNamespace;
}

export default {
  async fetch(request: Request, env: Env): Promise<Response> {
    const url = new URL(request.url);
    
    // Get room ID from path or query
    const roomId = url.searchParams.get("room") || "default";
    
    // Get the Durable Object for this room
    const id = env.SESSIONS.idFromName(roomId);
    const stub = env.SESSIONS.get(id);
    
    // Forward request to the Durable Object
    return stub.fetch(request);
  }
};

name = "my-app"
main = "src/index.ts"

[[durable_objects.bindings]]
name = "SESSIONS"
class_name = "SessionManager"

[[migrations]]
tag = "v1"
new_classes = ["SessionManager"]

8. Workers AI: Running Models at the Edge

Workers AI brings machine learning inference to the edge. Instead of calling external APIs with added latency, run models directly in Cloudflare's network—text generation, embeddings, image classification, speech recognition, and more.

Available Models

Cloudflare hosts various model categories:

Setting Up Workers AI

name = "ai-worker"
main = "src/index.ts"
compatibility_date = "2024-01-01"

[ai]
binding = "AI"

Text Generation

interface Env {
  AI: Ai;
}

export default {
  async fetch(request: Request, env: Env): Promise<Response> {
    const { prompt } = await request.json();
    
    const response = await env.AI.run("@cf/meta/llama-3-8b-instruct", {
      messages: [
        { role: "system", content: "You are a helpful assistant." },
        { role: "user", content: prompt }
      ],
      max_tokens: 500
    });
    
    return Response.json(response);
  }
};

Streaming Responses

export default {
  async fetch(request: Request, env: Env): Promise<Response> {
    const { prompt } = await request.json();
    
    // Stream the response
    const stream = await env.AI.run("@cf/meta/llama-3-8b-instruct", {
      messages: [
        { role: "user", content: prompt }
      ],
      stream: true
    });
    
    return new Response(stream, {
      headers: { "Content-Type": "text/event-stream" }
    });
  }
};

Embeddings for Semantic Search

interface Env {
  AI: Ai;
  VECTOR_INDEX: VectorizeIndex; // Cloudflare Vectorize
}

export default {
  async fetch(request: Request, env: Env): Promise<Response> {
    const { query } = await request.json();
    
    // Generate embedding for the query
    const embedding = await env.AI.run("@cf/baai/bge-base-en-v1.5", {
      text: query
    });
    
    // Search vector database
    const results = await env.VECTOR_INDEX.query(embedding.data[0], {
      topK: 5,
      returnMetadata: true
    });
    
    return Response.json({ results: results.matches });
  }
};

Speech-to-Text with Whisper

export default {
  async fetch(request: Request, env: Env): Promise<Response> {
    // Get audio data from request
    const audioData = await request.arrayBuffer();
    
    // Transcribe
    const result = await env.AI.run("@cf/openai/whisper", {
      audio: [...new Uint8Array(audioData)]
    });
    
    return Response.json({
      text: result.text,
      language: result.language
    });
  }
};

AI Gateway: Logging and Caching

Cloudflare AI Gateway sits in front of AI providers (OpenAI, Anthropic, Workers AI) and provides:

• Request logging: Track all AI calls, costs, and latency
• Caching: Cache identical prompts to reduce costs
• Rate limiting: Protect against runaway costs
• Fallback: Route to backup providers on failure

// Using AI Gateway with external providers
const response = await fetch(
  "https://gateway.ai.cloudflare.com/v1/YOUR_ACCOUNT/YOUR_GATEWAY/openai/chat/completions",
  {
    method: "POST",
    headers: {
      "Authorization": `Bearer ${env.OPENAI_KEY}`,
      "Content-Type": "application/json"
    },
    body: JSON.stringify({
      model: "gpt-4",
      messages: [{ role: "user", content: "Hello!" }]
    })
  }
);

9. Environment Variables and Secrets

Workers need configuration—API keys, feature flags, environment-specific settings. Cloudflare provides two mechanisms: environment variables (in code) and secrets (encrypted, never in code).

Environment Variables

Non-sensitive configuration goes in wrangler.toml:

[vars]
ENVIRONMENT = "development"
API_VERSION = "v2"
MAX_RESULTS = "100"
FEATURE_NEW_UI = "true"

[env.production.vars]
ENVIRONMENT = "production"
MAX_RESULTS = "50"

[env.staging.vars]
ENVIRONMENT = "staging"

Secrets

Sensitive values (API keys, passwords, tokens) should never be in your codebase:

# Add a secret
wrangler secret put API_KEY
# Prompts for value (not echoed)

# Add secret to specific environment
wrangler secret put API_KEY --env production

# List secrets (shows names, not values)
wrangler secret list

# Delete a secret
wrangler secret delete API_KEY

Using in Code

interface Env {
  // Environment variables (from wrangler.toml [vars])
  ENVIRONMENT: string;
  API_VERSION: string;
  MAX_RESULTS: string;  // Note: always strings!
  FEATURE_NEW_UI: string;
  
  // Secrets (from wrangler secret put)
  API_KEY: string;
  DATABASE_URL: string;
  JWT_SECRET: string;
}

export default {
  async fetch(request: Request, env: Env): Promise<Response> {
    // Access like any other property
    const isProduction = env.ENVIRONMENT === "production";
    const maxResults = parseInt(env.MAX_RESULTS, 10);
    const showNewUI = env.FEATURE_NEW_UI === "true";
    
    // Use secrets for auth
    const response = await fetch("https://api.external.com/data", {
      headers: { "Authorization": `Bearer ${env.API_KEY}` }
    });
    
    return new Response(`Environment: ${env.ENVIRONMENT}`);
  }
};

Environment-Specific Deployments

name = "my-api"
main = "src/index.ts"

# Default (development)
[vars]
ENVIRONMENT = "development"
LOG_LEVEL = "debug"

# Production environment
[env.production]
name = "my-api-production"
routes = [{ pattern = "api.example.com/*", zone_name = "example.com" }]

[env.production.vars]
ENVIRONMENT = "production"
LOG_LEVEL = "error"

# Staging environment
[env.staging]
name = "my-api-staging"
routes = [{ pattern = "staging.example.com/*", zone_name = "example.com" }]

[env.staging.vars]
ENVIRONMENT = "staging"
LOG_LEVEL = "info"

# Deploy to development (default)
wrangler deploy

# Deploy to staging
wrangler deploy --env staging

# Deploy to production
wrangler deploy --env production

# Secrets are environment-specific
wrangler secret put API_KEY --env production
wrangler secret put API_KEY --env staging

API_KEY=dev-key-for-testing
DATABASE_URL=postgres://localhost:5432/dev

10. Custom Domains and DNS

Connecting Workers and Pages to custom domains requires DNS configuration. Cloudflare makes this trivial if you're using their DNS—slightly more involved with external DNS.

Option 1: Cloudflare-Managed DNS (Recommended)

If your domain's nameservers point to Cloudflare:

1. Add your domain to Cloudflare (free plan works)
2. Update nameservers at your registrar
3. Wait for propagation (minutes to hours)
4. Workers and Pages can now route to your domain automatically

Adding Routes to Workers

# Simple route
route = "api.example.com/*"

# Multiple routes
routes = [
  { pattern = "api.example.com/*", zone_name = "example.com" },
  { pattern = "api.example.org/*", zone_name = "example.org" }
]

# Custom domain (automatic SSL)
[[routes]]
pattern = "api.example.com/*"
custom_domain = true

Via Dashboard

1. Go to Workers & Pages → Your Worker → Triggers
2. Add route or custom domain
3. Cloudflare creates necessary DNS records automatically

Option 2: Custom Domain on Pages

1. In Pages project → Custom Domains
2. Add domain (e.g., asabove.tech)
3. Cloudflare handles SSL certificate provisioning
4. If using Cloudflare DNS: automatic
5. If external DNS: add the CNAME record shown

Option 3: External DNS

If you can't move DNS to Cloudflare, you can still use Workers:

# For Workers
Type: CNAME
Name: api
Value: your-worker.your-subdomain.workers.dev

# For Pages
Type: CNAME
Name: www
Value: your-project.pages.dev

SSL/TLS Configuration

Cloudflare automatically provisions SSL certificates for custom domains. Configure encryption mode in your domain settings:

For Workers and Pages with no external origin, "Full (Strict)" works automatically—there's no origin to worry about.

11. Real Examples: Our Deployments

Theory is nice, but let's look at how we actually use Workers in production. These are real deployments running right now.

export default {
  async fetch(request: Request, env: Env): Promise<Response> {
    // 1. CORS preflight
    if (request.method === "OPTIONS") {
      return handleCors(request, env);
    }
    
    // 2. Authentication
    const auth = await validateAuth(request, env);
    if (!auth.valid) {
      return errorResponse("Unauthorized", 401);
    }
    
    // 3. Rate limiting
    const rateLimitOk = await checkRateLimit(auth.userId, env);
    if (!rateLimitOk) {
      return errorResponse("Rate limit exceeded", 429);
    }
    
    // 4. Check cache
    const cached = await getFromCache(request, env);
    if (cached) return cached;
    
    // 5. Route to backend
    const response = await routeToBackend(request, env);
    
    // 6. Cache response
    ctx.waitUntil(cacheResponse(request, response.clone(), env));
    
    return response;
  }
};

Deployment Workflow

Our deployment process for Workers:

12. Pricing and Free Tier Limits

Cloudflare's free tier is genuinely usable for production—not a trial that expires or degrades. Understanding the limits helps you plan.

Workers Pricing

Pages Pricing

Workers AI Pricing

When Costs Grow

Scenarios where you'll exceed free tier:

• 100,000+ requests/day: Time for paid Workers ($5/mo base)
• Heavy KV writes: 1,000 writes/day is low for write-heavy apps
• Durable Objects: Any usage requires paid plan
• Workers AI at scale: Free tier is for experimentation; production needs paid
• Long-running tasks: 10ms CPU limit is tight; paid gives 30 seconds

Even at scale, Workers is often cheaper than alternatives. Compare to Lambda ($0.20/M requests + compute time) or always-on servers ($5-50/mo minimum).

13. When NOT to Use Workers

Workers are powerful, but they're not the right choice for everything. Knowing when not to use them saves you from painful refactors.

Don't Use Workers For:

The Hybrid Architecture

The most effective architectures combine Workers with traditional backends:

Workers excel at the request layer: fast, global, cheap at scale. Traditional infrastructure handles what Workers can't: stateful processing, heavy computation, persistent connections. The edge layer becomes a smart, distributed API gateway.

Summary: Workers Are Right When...

Conclusion: Start Simple, Scale Globally

Cloudflare Workers represent a fundamental shift in how we build web applications. The ability to run code in 300+ locations worldwide, with zero cold starts and minimal configuration, removes barriers that previously required entire DevOps teams to overcome.

For AI applications specifically, edge computing isn't optional—it's essential. Voice interfaces demand sub-200ms latency. Real-time features need instant responses. API gateways must protect expensive AI backends from abuse. Workers provide the infrastructure to make all of this possible without managing servers.

Our deployments at asabove.tech demonstrate the practical reality: static sites on Pages, voice agents processing audio through Workers, email routing without external services, API endpoints responding in milliseconds globally. The combined monthly cost? Zero, on the free tier.

The edge is no longer a luxury for companies with massive infrastructure budgets. It's accessible to anyone who can write JavaScript. The tools are mature, the documentation is solid, and the free tier is generous enough for real production use.

Every millisecond of latency you eliminate is a user experience improved. Every request handled at the edge is a backend server protected. Every global deployment is infrastructure you didn't have to manage.

Deploy to the edge. Your users are there.