I really like the offering that Cloudflare has with workers, but for me they just seem to be lacking some DX tooling/solutions. Debugging is hell, but for quick projects like this I'll definitely look into it again. These days Railway is my go-to for hosting "throw-away" projects.
Always wondering how its going for folks that are using Cloudflare Workers as their main infra?
Cloudflare Workers has really improved lately, e.g. "Observations" and "Metrics", and on top of that their product suite keeps growing all the time. If you use Astro[1] together with Cloudflare then you have a solution that is at least on par with NextJS and Vercel, but that only costs a fraction. My latest project[2] also uses Astro and Cloudflare and it is rendered on the "edge" (i.e. SSR) in about 100ms – you won't get better performance.
I use Cloudflare Pages for my blog, and I really like it, but my static blog generator (Quartz) only supports Giscus, which requires signing in with a GitHub account.
I was thinking I might be able to hobble together a vibe-coded straightforward thing with Rust-> WASM to make an embeddable comment system, using Cloudflare Workers.
I gotta say that Workers are shockingly pleasant to use. I think I might end up using them for a bigger project.
As someone growing up with shared hosting, VPS and eventually K8s, I never really got Cloudflare's offering (apart from CDN/DDOS/DNS). I'm not sure if it's their positioning or if I never had the problems they're trying to solve, but it just doesn't click for me. Durable objects, Wrangler, D1, some custom Node.js API... it's all kind of opaque to me how it really solves any problem better than just using Postgres, Redis, etc on top of K8S or something like that.
The really annoying thing about Cloudflare is that Workers don’t belong to zones (i.e. editing any worker is an account level permission, either: Read only or Edit), and thus you can’t scope a particular user or API key access to a particular set of workers.
This means you can’t physically set different permissions between prod and dev workers, which is a disaster waiting to happen.
(You can’t just make a second Cloudflare account for Prod, because it won’t let you
bind single sign-on to two different accounts…)
It also means any employee in the company can just open a dev branch, print out the dev deploy key (from the Pipeline), and use it to deploy to prod. It’s currently impossible to block or mitigate.
I was also suspicious of Cloudflare as a full platform, but now it's one of my favorite ways to develop and scale web applications. I have implemented Minifeed[1] (and Exotext [2]) completely in Cloudflare Workers (except for the full-text search, for which I use a self-hosted instance of Typesense; though in my testing, Cloudflare's D1 database does come with full-text search enabled - it's SQLite compatible, and it works well!).
I also didn't want to have any kind of rich frontend layer, so all my HTML is generated on the backend. I don't even use complex templating libraries, I just have a few pure functions that return HTML strings. The only framework in use is Hono which just makes HTTP easier, although standard handlers that Cloudflare offers are just fine; it takes maybe 2-3 times more lines of code compared to Hono.
D1 is a fine database. Queues are fantastic for my purpose (cron-scheduled fetches of thousands of RSS feeds). Vector database is great, I generate embeddings for each fetched blog post and store them in the vector database, which allows me generate "related" posts and blogs. R2 is a simple S3-compatible object storage, though I don't have many files to store. Deployments and rollbacks are straight-forward, and the SQLite database even has time-travel when needed. (I've also tried Workflows instead of Queues, but found them unstable while in open beta; I haven't tried them after they became generally available.)
I know this might sound like an ad or something; I have nothing to do with Cloudflare. In fact, I couldn't even get through to the initial interview for a couple of their positions :/ It's just I always had this cloud over my head every time I needed to create and maintain a web project. Ruby on Rails + Heroku combo was probably the easiest in this regard, abstracting away most of the stuff I hate to deal with (infra, DB, deployment, etc.) But it was still not as robust and invisible, and also pricey (Heroku). Cloudflare workers is an abstraction that fits my mindset well: it's like HTTP-as-a-service. I just have to think in terms of HTTP requests and responses, while other building blocks are provided to me as built-in functions.
Minifeed has been chugging along for 2+ years now, with almost 100% uptime, while running millions of background jobs of various types of computing. And I didn't have to think of different services, workers, scaling and stuff. I am well aware of how vendor-locked in the project is at this point, but I haven't enjoyed web development before as much as I do now.
The only two big missing pieces for me are authentication/authorization and email. Cloudflare has an auth solution, but it's designed for enterprise I think. I just didn't get it and ended up implementing simple old-school "tokens in db + cookie". For email - they have announced the new feature, so I hope I can migrate away from Amazon SES and finally forget about the nightmare of logging into the AWS console (I have written step-by-step instruction notes for myself which feel like "how to use a TV" note for some old, technically-unsavvy person).
Just be super careful to understand what CPU time means before you go ahead and waste time on this. They don't immediately flag this, but once you go past a very, very very small time threshold on used CPU time, they'll start aborting requests. This does not happen (as harshly) on fully paid accounts, of course.
But since many are comfortably being dragged into the Cloudflare vortex through their otherwise generously free offers, you'll find that the Cloudflare Worker CPU time limitation can turn into a huge waste of time, after the fact, once you realize the worker code you converted a few days ago and you're all joyful about suddenly starts failing a few days later.
Addendum: Just to illustrate the moment where you'll trip over it: here it casually mentions the default minimum being 30s, without being clear that this *only* applies to paid accounts. Only further down somewhere there's a tiny mention of 10ms!
https://developers.cloudflare.com/workers/platform/limits/#c...
So, if your script can get by with a max of 10 milliseconds of CPU time per invocation (not runtime), you'll be fine. You will, however, and this is crucial, only realize this a few days in. They're taking the average and eventually cap you and it stops responding.
9 comments
[ 2.0 ms ] story [ 31.4 ms ] threadAlways wondering how its going for folks that are using Cloudflare Workers as their main infra?
[1]: https://astro.build
[2]: https://www.viewdiff.ai
I was thinking I might be able to hobble together a vibe-coded straightforward thing with Rust-> WASM to make an embeddable comment system, using Cloudflare Workers.
I gotta say that Workers are shockingly pleasant to use. I think I might end up using them for a bigger project.
This means you can’t physically set different permissions between prod and dev workers, which is a disaster waiting to happen.
(You can’t just make a second Cloudflare account for Prod, because it won’t let you bind single sign-on to two different accounts…)
It also means any employee in the company can just open a dev branch, print out the dev deploy key (from the Pipeline), and use it to deploy to prod. It’s currently impossible to block or mitigate.
I also didn't want to have any kind of rich frontend layer, so all my HTML is generated on the backend. I don't even use complex templating libraries, I just have a few pure functions that return HTML strings. The only framework in use is Hono which just makes HTTP easier, although standard handlers that Cloudflare offers are just fine; it takes maybe 2-3 times more lines of code compared to Hono.
D1 is a fine database. Queues are fantastic for my purpose (cron-scheduled fetches of thousands of RSS feeds). Vector database is great, I generate embeddings for each fetched blog post and store them in the vector database, which allows me generate "related" posts and blogs. R2 is a simple S3-compatible object storage, though I don't have many files to store. Deployments and rollbacks are straight-forward, and the SQLite database even has time-travel when needed. (I've also tried Workflows instead of Queues, but found them unstable while in open beta; I haven't tried them after they became generally available.)
I know this might sound like an ad or something; I have nothing to do with Cloudflare. In fact, I couldn't even get through to the initial interview for a couple of their positions :/ It's just I always had this cloud over my head every time I needed to create and maintain a web project. Ruby on Rails + Heroku combo was probably the easiest in this regard, abstracting away most of the stuff I hate to deal with (infra, DB, deployment, etc.) But it was still not as robust and invisible, and also pricey (Heroku). Cloudflare workers is an abstraction that fits my mindset well: it's like HTTP-as-a-service. I just have to think in terms of HTTP requests and responses, while other building blocks are provided to me as built-in functions.
Minifeed has been chugging along for 2+ years now, with almost 100% uptime, while running millions of background jobs of various types of computing. And I didn't have to think of different services, workers, scaling and stuff. I am well aware of how vendor-locked in the project is at this point, but I haven't enjoyed web development before as much as I do now.
The only two big missing pieces for me are authentication/authorization and email. Cloudflare has an auth solution, but it's designed for enterprise I think. I just didn't get it and ended up implementing simple old-school "tokens in db + cookie". For email - they have announced the new feature, so I hope I can migrate away from Amazon SES and finally forget about the nightmare of logging into the AWS console (I have written step-by-step instruction notes for myself which feel like "how to use a TV" note for some old, technically-unsavvy person).
[1] https://minifeed.net/
[2] https://exotext.com/
But since many are comfortably being dragged into the Cloudflare vortex through their otherwise generously free offers, you'll find that the Cloudflare Worker CPU time limitation can turn into a huge waste of time, after the fact, once you realize the worker code you converted a few days ago and you're all joyful about suddenly starts failing a few days later.
Addendum: Just to illustrate the moment where you'll trip over it: here it casually mentions the default minimum being 30s, without being clear that this *only* applies to paid accounts. Only further down somewhere there's a tiny mention of 10ms! https://developers.cloudflare.com/workers/platform/limits/#c...
Here is the only other mention of it: https://developers.cloudflare.com/workers/platform/pricing/
So, if your script can get by with a max of 10 milliseconds of CPU time per invocation (not runtime), you'll be fine. You will, however, and this is crucial, only realize this a few days in. They're taking the average and eventually cap you and it stops responding.