Workers Unbound: initial questions

Just seen the Workers Unbound. Looks great. I see it’s pitched as a rival specifically to AWS Lambda in the post. Which makes sense, it’s serverless but faster and cheaper.

So based on that comparison, a few questions (which I appreciate may not be answerable if it’s currently private):

  1. Is there a limit on deployment size? A Worker can be up to 1MB, whereas a Lambda zip can be 50MB (zipped). Does it keep the 1MB limit, or move to a Lambda-competing larger size?

  2. Is there any /tmp space available? Again, Lambda has some kind of storage available for temporary operations on disk, like downloading a file, processing it etc.

  3. Is there still the same issue Workers has where a Worker can not call another Worker (within the same zone)? As I read it, you couldn’t have e.g. call Which is useful if you have e.g. and want to call that API from other domains. Based on Issue With Worker-To-Worker HTTPS request Since with Lambda (with API Gateway) you can call you own subdomains.

  4. Are you still limited to the service worker api? With the expansion to other languages, I wondered if you can use a general NodeJS app which is JavaScript. Or are all the other languages converted behind the scenes and so you can’t simply copy across an Express project. Again, yes, like Lambda.

Thanks. (Sounds like I’m promoting Lambda here, which I’m not! It would be great to have something faster and cheaper. Just trying to understand where the issues may arise)


I’m not from Cloudflare, but some observations here.

  1. It will most likely stay 1MB, because deployment speed is important on a distributed system. Which means, to send the “system” worldwide, it can’t have bandwidth issues.

  2. That would be useful, but I doubt it, since KV is currently used for hosting files (In Cloudflare Worker Sites).

  3. I don’t think they have solved that yet, since it’s a security issue. We really do need CNAME possibility though…

  4. It will always be service worker API (Because of their isolates architecture) - but they do add features on top of it, which means some NodeJS API’s might be added but probably under other names.

  1. I strongly recommend you to join the beta, make your requests to the team, 1MB is limit, but it can change depending on feedback and market analysis.

  2. You could store this in global variables of worker(128Mb Bundled or more Unbound) or in kv pair (10Mb).

  3. For this you should contact support, there might by a solution for this, but you could also build a package sharable on your workers that interact with your APIs, it will save you requests.

  4. The are plenty of packages you can use you just have to use webpack.


Thanks for the replies, that’s helpful

If you don’t need more than one leve of depth, but to simply call a secondary Worker for some additional processing, you can use the subdomain. Those can be called. Alternatively either use a secondary domain, it won’t increase pricing (just the actual domain).

1 Like

That’s one workaround I guess.

Is the still available even when you use a custom domain? Like you can use both? Or is it one or the other?

Only I was thinking let’s say you have and The can’t call the if both are Workers, since they are on the same domain. But as you say, internally, could call (or whatever it is) as that is a separate domain.

But if you have to choose custom domain or domain then it gets more awkward maintaining two copies of the api.

Interesting idea though, thanks.

You can use one, the other or both. You can chose it from Wrangler or the UI.

You could technically do → etc, you would need to make sure you always alternate, which is a pain, but not that much if coded right.

1 Like

My painpoint is external domains though, we can’t offer it to clients without them being on Cloudflare.

You could use the SaaS offering, that should work, but it would still need to pass through.

Still waiting for pricing on that, they don’t seem to be that interested in small business.

Well, at the beginning be very excited about the announcement, but after checking the numbers, I believe that it will only be useful in extremely specific cases:

I can explain, but rather a small context:

Total Requests 1.000.000
Egress / Req. (KiB) 3
Price (GB-Sec) RAM (MiB) Duration (ms) Req / MM Accumulated Egress ($/GiB) Total+Egress
Workers Bundled $0,0000800000 128 50 $0,00 $0,50 $0,00 $0,50
Workers Unbound $0,0000125000 1024 1000 $0,15 $12,65 $0,09 $12,91
AWS Lambda $0,0000166667 1024 1000 $0,20 $16,87 $0,09 $17,12
AWS Lambda $0,0000166667 128 100 $0,20 $0,41 $0,09 $0,67
Workers Unbound $0,0000125000 128 100 $0,15 $0,31 $0,09 $0,56
Workers Unbound $0,0000125000 128 50 $0,15 $0,23 $0,09 $0,49
Workers Unbound $0,0000125000 128 10 $0,15 $0,17 $0,09 $0,42

There is no way to make a request without consuming memory, duration and not returning at least a few bytes. Thus, the total value is always a set of these values. Before we had a very simple way of working: 1,000,000 on 128MiB@50ms cost $0.50; You don’t have to worry about anything.

Now, with the egress rate, it only makes sense if you return less than 3KiB, and considering all the HTTP overhead (including the “CF- *” headers) this number will explode quickly.

Google Cloud Functions should beat Workers Unbound from 75KiB per call precisely because of the CDN Internerconnect. Not counting other few members of the Bandwidth Alliance, who either do not charge for traffic (scaleway), or when they do it costs 1 $/TiB (cherryservers) !

And if we compare to other Serverless platforms like Cloud Run the Unbound doesn’t seem worth it.

Anyway, i have 3 questions:

  • Is there a minimum duration fee? (100ms for AWS/Google)
  • Will the memory remain limited to 128MiB?
  • Will the memory remain to be shared by several calls?