Run node.js for worker

Currently, the workers lack node.js support to be a real serverless provider. While it is possible to use webworker to run some packages, any native code parts (eg crypto, fs) won’t run.

This is why a potential use case, where I would like to run a worker for fido2 deployment, won’t be possible with Cloudflare - there are dozens of libraries for PHP, Node.js and Go, but none for javascript only. My own attempts to re-code the whole design doesn’t work due to crypto issues and I can’t use the simple crypto parts from Node.

So when can we expect to use real node.js code for a real serverless deployment? Is it currently planned or out of reach?

These are components programmed into node, so they won’t work since Workers isn’t node (it’s v8 with their own layer on top).

See standard APIs for the list of things CF implements, eg webcrypto is fully supported.


@bert.barthelona, @Judge have pointed you in the right direction.

I’ve worked only on CF Workers for many months now and it’s made me a much better developer. With less code comes less complexity and having to think more about the design of the applications, with the added benefit of much higher performance and less bugs.

With improvements in the Key-value-database and (possibly) worker-queues, there will not be much that we cannot create.


I am aware of that, that’s why I asked - so there isn’t any plan to extend it to a NodeJs stack? Having to program all tools from scratch because you don’t want to support it doesn’t appear very user-friendly to me, even though it is understandable from an architecture standpoint. It works for a “you can script small things for your website”, but not for the serverless direction Cloudflare wants to go.

It actually is - feel free to try programming crypto in native JS yourself. You can find the official nodejs-crypto library here that is audited and tested:
Otherwise you need to re-program, test, audit and maintain it yourself, which is simply not feasible, considering there are dozens of existing node implementations already.

There’s a reason why Lambda, GCP, etc. Have cold starts of 200+ ms in node environments.

Any given Isolate can start around a hundred times faster than I can get a Node process to start on my machine. Even more importantly, they consume an order of magnitude less memory than that process.

I strongly encourage reading the rest of the blog post for why this decision was made.

I have actually done that and built in Auth with cookies, JWT, sessions, hashing and even request signing with the web crypto. Was it easy? No… but is it possible? Yes. And it’s a reliable API that’s well documented.

Oh, and it’s roughly 100kb.

1 Like

Also the use on Web Crypto API doesn’t count towards your CPU limit.

1 Like

I know that this decision was a good one for most use cases, but as mentioned there are some that require different decisions - costs to maintain a separate crypto project are in a different ballpark compared to a few seconds for a cold start, especially for pages with less volume.
While I understand that you do not plan to use NodeJs stack in a full way, is it planned or can be evaluated to optionally offer NodeJs opt-in workers?

Tell me once you have Fido2 ported to webcrypto in a secure way - I’ll buy you a beer :wink:

Didn’t know that, that’s great to hear! Is that documented somewhere?

This is incorrect. The runtime still counts CPU time executing the WebCrypto implementation. It’s far more efficient than native JS implementations, but if you do many heavyweight operations (like PBKDF2 key derivation) in the context of a single request, you’ll start seeing requests fail with an 1102.


Soon to take on Fido, just finished OTP yesterday (yubikey).

Yeah, crypto will drain CPU time, bcrypt and Argo 2 won’t work at all.

I see, you’re very enthusiastic, and should libraries move to native scripts workers make a lot more sense.

Are you sharing your developments publicly? Where could I follow to stay up-to-date wirh it?

Thanks, unfortunately this is all code going to the employer. I’ll start writing a blog about it when the contract expires :wink:

Thanks for the correction/clarification.:+1:

I think we can use it

Please consider at least adding optional support for node.js. It is putting back pressure on node package maintainers to support barebones runtimes like these.

There’s a node_compat flag for wrangler which will attempt to polyfill Node native APIs - but some things are simply not possible with Workers, Node or not.

They have no concept of a filesystem so anything relying on fs just wouldn’t work - although someone could probably polyfill that to use R2 as the underlying filesystem.

1 Like