BuildBot

Compute at the Edge

Going live

Lesson 5 of 5

What you'll learn

  • Deploy with wrangler deploy and put the Worker on a route or custom domain
  • Watch production with wrangler tail and the analytics dashboard
  • Respect CPU-time and request limits, and ship new versions as gradual rollouts

npx wrangler deploy uploads your Worker and it is live globally in seconds — no regions to pick, no capacity to provision. Out of the box it answers on <name>.<your-subdomain>.workers.dev, which is fine for APIs and internal tools. For real traffic you attach it to your own DNS, one of two ways:

# Routes: match URL patterns on a zone you have on Cloudflare.
routes = [
  { pattern = "example.com/api/*", zone_name = "example.com" }
]

# Or a custom domain: Cloudflare creates the DNS record and certificate for you.
# routes = [{ pattern = "api.example.com", custom_domain = true }]

Routes run the Worker in front of an existing site for matching paths — ideal for augmenting an origin (/api/* to the Worker, everything else passes through). A custom domain makes the Worker be the origin for a hostname, with DNS and TLS managed automatically.

Watching it run

npx wrangler tail streams live production logs — every console.log, exception, and request outcome — to your terminal, filterable by status or method; it's the first tool to reach for when production misbehaves. For the aggregate view, the dashboard's analytics show requests, errors, CPU time percentiles, and per-location traffic, and enabling observability in config persists structured logs for querying after the fact.

Limits: CPU time, not wall clock

The number that matters most: Workers meter CPU time — milliseconds actively executing JavaScript — not wall-clock time. Time spent awaiting a fetch to your origin or a D1 query costs nothing. The free plan allows about 10 ms CPU per request (plenty: typical handlers use well under 5 ms) plus 100,000 requests/day; paid raises CPU to 30 s and removes the daily cap. There's also a subrequest budget per request and 128 MB of memory per isolate. If you're CPU-bound at the edge — parsing megabytes of JSON, cryptographic mining of any kind — that work belongs elsewhere.

Deploy is instant; trust shouldn't be

wrangler deploy cuts 100% of global traffic to the new code immediately. For anything load-bearing, use gradual rollouts: wrangler versions upload publishes a version without traffic, then wrangler versions deploy splits traffic by percentage between old and new. Watch error rates at 10%, then walk it up.

Model a gradual rollout

Run it. Two versions of a Worker sit behind a traffic split, exactly like wrangler versions deploy with a 90/10 split. Check the counts, then promote v2 by editing the percentages — the printed distribution should follow.

Loading editor…
Knowledge check

What does the Workers CPU-time limit actually measure?

That's the course: a fetch handler on web standards, wrangler and bindings, KV and the cache, D1 and Durable Objects, and a deploy you can watch and roll out gradually — the whole path from Response.json() to production at the edge.

Saved on this device. Sign in to sync your progress everywhere.