Compute at the Edge
Going live
Lesson 5 of 5
What you'll learn
- Deploy with
wrangler deployand put the Worker on a route or custom domain - Watch production with
wrangler tailand 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.
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.
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.