Cloudflare Workers
We build and run production products on Cloudflare's edge, where one Worker serves the app and the API together, and the surrounding services replace most of what a traditional cloud bill is spent on.
| In production | Since 2025 |
|---|---|
| Projects | 4 |
| Evidence | 4 products in production |
- Workers for SSR and API in one deploy
- R2 for object storage
- Hyperdrive for pooled Postgres access
- Durable Objects for coordination and state
- Cron Triggers for scheduled work
- Multi-tenant routing by hostname
Global audience, no region to pick
Code runs near the user by default, so there is no primary region to choose and no second one to pay for.
Spiky or unpredictable traffic
Scaling is not something you configure. A quiet product costs almost nothing and a busy one does not need a capacity plan.
You want a small surface to operate
One Worker holding SSR, API, auth and billing is far less to run than a cluster, which matters when nobody is on call.
Scheduled and queued work
Cron Triggers and queues cover most of what a separate job runner used to be needed for.
Long-running or CPU-heavy work
Video transcoding, large batch jobs and anything measured in minutes belong on machines you rent, not on an edge runtime.
A dependency that needs full Node
Node compatibility is good and improving, but some native or long-lived libraries still will not run. This is worth checking before committing.
You are already deep in another cloud
If your data and team are established on AWS, moving the front door to the edge is often the only part worth doing.
Heavy stateful connections
Durable Objects cover coordination well, but a workload built around persistent connections to a single big instance is a poor fit.
What we have run on it
Companion AI is a multi-tenant AI-companion platform on Workers: four independently branded consumer sites served from one backend, routed by hostname, with R2, Hyperdrive and Durable Objects behind it and roughly 108k lines of TypeScript across the monorepo.
Socialog runs a cron-driven publish engine at the edge, fanning one post out to seven networks through per-platform adapters, with retry and idempotency handled in the queue rather than hoped for. MandarinAI serves both the app and the whole API from a single Worker. Bikkel ships two product surfaces, auth with passkeys, and billing as one Worker.
This site runs on it too, at roughly 262 KB gzipped for thirty-one prerendered pages.
Why it changes the economics
The interesting part is not latency. It is that the operational surface collapses. There is no cluster to size, no region to fail over, no autoscaling policy to tune, and no idle capacity to pay for overnight. For a small team, the platform stops being something that needs a person.
That is also the honest limit of it: the same constraints that make it cheap to operate make it wrong for workloads that need to sit and think for a while.
Migrating onto it
Usually the front door moves first (SSR, routing, static assets, auth) while the heavy backend stays where it is behind Hyperdrive or a private connection. That gets most of the benefit without a rewrite, and it leaves an obvious exit if the fit turns out to be wrong.
Tell us the one thing it has to do.
If it's sharp enough to prove in a week, we'll say so and give you a date. If it isn't, we'll tell you that too, along with what we'd build first instead.