Reference · Diagram Design

Cloudflare Workers

What a Worker is, who can call it, what it can reach, and the four ways it gets deployed.

Cloudflare Workers: callers, the Worker itself, its bindings, deployment paths and limits A diagram in three layers. The request path shows who can call a Worker (browser, your own server, curl, another Worker, cron triggers, queues, email) flowing over HTTPS into the Worker, which in turn reaches bindings such as KV, D1, R2, Durable Objects, Queues, Workers AI, Vectorize, Hyperdrive, Browser Run, service bindings and any HTTPS API. The second layer lists four deployment paths: Wrangler CLI, the dashboard, Git push via Workers Builds, and GitHub Actions. The third layer covers the runtime model, free versus paid limits, and the ways a Worker differs from a Node server. REQUEST PATH Who can call it · Browser / frontend — yes, CORS rules apply · Your own server — plain HTTPS, any cloud · curl / Postman — nothing special needed · Another Worker — service binding, no hop · Cron Trigger — scheduled handler · Queue — consumer handler, in batches · Email routing — email handler Public by default. The auth is yours to add — in code, or with Access / mTLS / WAF. HTTPS The Worker https://api.your-name.workers.dev · Your JS / TS — deployed once, runs everywhere · 300+ cities — executes near the caller · V8 isolate — not a container, ~0 ms cold start · Handlers — fetch · scheduled · queue · email · One isolate per request — nothing to size · Custom domain or route replaces workers.dev It is an HTTP endpoint, not a server you keep running. BINDINGS What it can reach · KV — key-value, fast global reads · D1 — SQL database · R2 — object storage, S3-compatible · Durable Objects — stateful coordination · Queues — push work to run later · Workers AI · Vectorize — models & vectors · Hyperdrive — your existing Postgres / MySQL · Browser Run · Containers — heavier jobs · Service bindings — call another Worker · fetch() — any public API · VPC for private HOW YOU DEPLOY IT Wrangler CLI wrangler deploy From your machine or any CI. Every path below ends up here. Dashboard Edit & deploy in the browser. No repo, no build step. Good for quick fixes only. Git push — Workers Builds Connect GitHub / GitLab once. Push the branch, it deploys. PR comments + preview URLs. GitHub Actions cloudflare/wrangler-action Needs API token + account ID. For Bitbucket or custom steps. WHAT TO WATCH OUT FOR Runtime model · V8 isolates — not containers, not VMs · ~0 ms cold start — nothing to warm up · 128 MB memory per isolate, both plans · No filesystem and no long-lived process Limits — free vs paid · CPU time — 10 ms free · 30 s paid (max 5 min) · Subrequests — 50 free · 10,000 paid · Bundle size — 3 MB free · 10 MB paid, gzipped · Env vars — 64 free · 128 paid, 5 KB each Not a Node server · Web APIs first — nodejs_compat for the rest · 6 outbound connections at a time · HTTP — no wall-clock cap while connected · Cron / Queue / alarms — 15 min cap THE WORKER — everything else is what calls it or what it calls