You should consider Cloudflare workers
21 September, 2025
I’ve been using Cloudflare for DNS since time immemorial (2017), but for the longest time I didn’t pay much attention to their ever-expanding range of other services.
Over the past few months, I’ve been tinkering with the Workers platform both at work and on my spare time, and would like to point out great (and the not so great) things about it.
Use cases
Workers are meant to run lightweight workloads at the edge, which is something one needs to account for when targeting the platform – heavy number crunching and other compute heavy tasks are not a great fit.
But what if you want to:
- host a lightweight API or personal website?
- run a timed script?
- Serve some files?
Workers will handle stuff like this magnificently, while providing an experience that will be straightforward, frictionless, and affordable.
Value proposal
Cloudflare does not implement the deep, plug-into-everything model of the more IaaS focused platforms, but it covers a huge amount of ground without burying you in boilerplate.
The rather impressive toolbox of service bindings includes, among other things:
- KV storage for key/value lookups
- R2 object storage, an S3 compatible object storage with no egress fees
- D1 for SQL databases (disclaimer: I haven’t tried it personally, might suck)
And of course anything you deploy is automatically backed up Cloudflare’s CDN, which alone is already a huge benefit.
Developer UX
Cloudflare Developer Platform CLI interface Wrangler is excellent.
A capable adult can spin up the usual “hello world” app and have it deployed and accessible on the interent in minutes. The defaults are sensible, and you don’t need to produce a million of lines of YAML or set up IaC tooling before you’ve even written a single line of application code.
Local development is equally as smooth. Miniflare is bundled with Wrangler, and runs your Workers locally, emulating the necessary service bindings the code may depend on.
The overall flow is refreshingly simple: write some code, run it locally, push it out globally, done.
For a concrete example, I recently rewrote a small personal project to run in Workers.
Pricing
Cost structure is almost comically straightforward compared to many other IaaS platforms.
There is a very serviceable free-tier, which in many cases is more than enough for small personal projects. If you outgrow it, the paid plan is five bucks a month. There are obviously some limits in the paid plan as well, but in my honest opinion they are transparent and quite generous.
Issues and negatives
First thing that comes to mind is language support. The choices are basically TypeScript, JavaScript, and to a limited extent Python (unless you want to juggle WebAssembly).
Then there’s the obvious question of performance: both CPU and execution time are capped, and especially in the free tier you can easily exhaust your limits if you don’t pay attention.
Another big thing is the platform ecosystem. I mentioned some of the services above, but admittedly they are nowhere near as mature as what the large players like AWS or GCP provide. Debugging can also be a little sparse: logs are serviceable, but without extra tooling the observability leads something to be desired.
Finally, the access control and permissions could be more granular. You basically have a single toggle that grants a user or an API token write permissions to every single worker on the account. Likely doesn’t matter for most when it comes to personal use, but can be a deal breaker in a production setting.
Final thoughts
Cloudflare Workers as a whole still has some growing up to do, but there is a lot to like already.
The developer UX is impeccable, pricing is affordable, and while it won’t work for every use case (being more akin to a razor blade than a Swiss Army knife), you should at least consider using it, because it’s great!