Questions about Workers paid pricing
We're on the paid plan for Workers and about to deploy our app. Could I please ask:
- Am I right that if our Worker doesn't receive more than 1,000,000 HTTP requests in a given month we wouldn't pay extra for that?
- What should be understood by "400,000 GB-s" under "Duration"? I've read the linked Duration explainer but still not quite getting it.
- We're coming at this from previously hosting apps on Azure > App services. These are costly. CF Workers seems free at best and cheap at worst. Am I missing something here? I never need to worry about compute provision, RAM, or all that gumf?
Thank you!
8 Replies
Your first two questions are more specific to the billing model you are using:
https://developers.cloudflare.com/workers/platform/pricing/
The new one is "Standard" which is based on Requests and CPU Time
The old ones are "Bundled" which is Requests and you get a set amount of CPU Time to use. and "Unbound" which is Requests + Duration (including the time you're waiting on promises/fetches, unlike CPU Time) which is more complex
App Services are cool, I use them myself. But the whole design is entirely different. You're not going to be able to get .net and especially not asp.net core running on Workers, for example. Workers run on every CF Machine, the same one handling the incoming request. Workers have to be less then 1 MB to be in the fastest storage, otherwise Paid can go up to 10 MB with some cold start hits. You may have to worry about memory if you're doing something really intensive, but usually you don't.
Cloudflare doesn't worry about compute provision either, the magic of it is their deployment. Every machine they have that would handle the incoming request, can also execute your workers. There's no load balancing to your Workers or anything like that.
The downsides are: Really small size limits, pretty much forced to Javascript, other languages are sort of supported via WASM but all of the bindings go back to Javascript in the end, and again size limitations. Workers do not run a web server, they are merely handed the incoming request and can respond to it
https://developers.cloudflare.com/workers/learning/how-workers-works/ is a good read
Thanks, that's really helpful @Chaika . I'll have a read of that article you linked to.
As for pricing/tier, the main pricing page for Workers simply mentions Free and Paid. But the link you gave instead references Free and Standard. Are these equivalent i.e. if I'm on Paid am I on Standard?
And any use of the word "request" means an HTTP request into my worker, right?
PS Really appreciate the quick and detailed response.
But the link you gave instead references Free and Standard. Are these equivalent i.e. if I'm on Paid am I on Standard?Not quite. Standard is still opt in by default as far as I know. It's the future though, the old billing models, "Bundled" and "Unbound" are going away, one reason being because Duration is confusing to figure out. In the dashboard if you go to a Worker -> Settings, at the top is your Usage Model for that worker. In the Workers & Pages overview you can see your default on the right and opt into Standard
And any use of the word "request" means an HTTP request into my worker, right?Correct
Inbound requests to your Worker. Subrequests to external services are not billed on a unit basis, but do impact the duration (wall-clock time) of your Worker.
Riiiight... thank you. That is quite confusing - there's Paid, Bundled, Unbound, Standard...
It looks like the Pricing Pages is just showing the pricing for Standard now
Workers Paid gets you access to the Paid usage models
Standard is the new/latest usage model
Unbound/Bundled are going away
Wicked, thanks. I'll switch onto Standard as you say. Presumably that's free to switch.
It's free to opt into yea. For most Workers its less expensive, and less confusing. Unbound's duration can be very confusing to figure out. It'll tell you how much it thinks you'll save (if you're even going over the included limits)
Nice one, thanks. Can't tell you how much I'm looking to not having to care about architecture compute/provisioning/memory etc.