Deploying on Cloudflare Workers

Cloudflare Workers run your code at the edge. Not on one server in Virginia. On hundreds of points of presence around the world.

When a user hits your app, the request lands on a machine close to them. Your handler runs there. That is the whole pitch.

What is a Worker?

A Worker is a JavaScript (or WebAssembly) function that Cloudflare runs on every request.

You write a small script. Cloudflare deploys it globally. No servers to patch. No load balancer to configure.

Example — a minimal HTTP handler:

export default {
  async fetch(request) {
    return new Response("Hello from the edge")
  }
}

That is a complete Worker. Deploy it with Wrangler and you have a URL in seconds.

Workers are not traditional Node.js. They run on workerd, Cloudflare’s open-source runtime. It feels like the browser and the WinterCG standards — fetch, Request, Response, Web Crypto.

You do not get the full Node API. No fs. No native modules built for Node. That trade-off buys you cold starts measured in milliseconds and global distribution by default.

Wrangler basics

Wrangler is the CLI for Workers. Install it, log in, deploy.

npm create cloudflare@latest my-app
cd my-app
npx wrangler dev

wrangler dev runs your Worker locally with the same runtime semantics as production. When you are happy:

npx wrangler deploy

Your wrangler.jsonc (or wrangler.toml) declares the Worker name, bindings, and routes. Bindings connect your code to Cloudflare services — KV, D1, R2, queues, and more — without hard-coding credentials.

D1, KV, and R2 at a glance

Most real apps need storage. Cloudflare bundles three options:

KV is a global key-value store. Great for config, feature flags, cached JSON. Reads are fast everywhere. Writes propagate eventually. Not a relational database.

D1 is SQLite at the edge. You get SQL, migrations, and a familiar model. Good for apps with structured data at modest scale. StackPlan itself runs on D1 in production.

R2 is object storage. S3-compatible API, no egress fees to the internet when paired with Workers. Photos, uploads, static assets, backups.

Pick KV for simple cache-like data. Pick D1 when you need queries and relations. Pick R2 for files and blobs.

The free tier reality

Cloudflare’s free tier is genuinely generous for side projects.

You get a large allowance of Worker requests per day. D1 and KV have free quotas too. R2 includes free storage and operations.

The catch is not the free tier itself. It is surprises at scale. A viral post can burn through paid tiers fast if you add Workers Paid, extra D1 rows, or R2 egress to non-Cloudflare destinations.

My advice: model costs at 1k and 10k daily users before you commit. The platform is cheap until it is not — usually when you add paid plans, long-running CPU, or heavy database writes.

When Workers fit

Workers shine when:

You want global latency without running servers in multiple regions
Your app is request/response — APIs, SSR, edge middleware
You are fine with SQLite (D1) or external Postgres over Hyperdrive
You like one bill from a vendor that also handles DNS, CDN, and DDoS

StackPlan recommends Workers often for indie SaaS, marketing sites with dynamic bits, and APIs that need to be fast worldwide.

When they do not

Skip Workers (or use them only as a CDN layer) when:

You need long-running jobs — video transcoding, ML training, big cron batches
Your stack assumes full Node — some npm packages simply will not run
You want a managed Postgres with zero glue — Railway or Supabase may be simpler
You are team-deep in Docker and want one container everywhere

None of this means Workers are weak. They are specialized. Edge compute for HTTP-shaped work.

If you are building a typical web app with an API and a database, Workers plus D1 or Hyperdrive to Postgres is a credible production stack. If you are running a worker queue that processes gigabytes of video, look elsewhere.