Comment by yencabulator
3 months ago
It's also worth noting that workerd is only a part of the Cloudflare Workers stack. It doesn't have the same security properties.
https://github.com/cloudflare/workerd#warning-workerd-is-not...
(I know you know this, but frankly you should add a disclaimer when you comment about CF or Capnp. It's too convenient for you to leave out the cons.)
Job scheduling and tenant sandboxing are generally the responsibility of the hosting provider, not the JS runtime. If you are going to run workerd on, say, Lambda, then you rely on Lambda for these things, not workerd. No other server JS runtime offers hardened sandboxing either -- they all defer to the hosting provider.
(Though if we assume no zero-days in V8, then workerd as-is actually does provide strong sandboxing, at least as strong as (arguably stronger than) any other JS runtime. Unfortunately, V8 does in fact have zero-days, quite often.)
What mariopt said above was: "being tied to only 1 vendor is problematic." My point here is that when you build on Workers, you are not tied to one provider, because you can run workerd anywhere. And we do, in fact, have former customers who have migrated off Cloudflare by running workerd on other providers.
> frankly you should add a disclaimer when you comment about CF or Capnp
I usually do. Sometimes I forget. But my name and affiliation is easily discovered by clicking my profile. I note that yours is not.
I think it's pretty well understood that Cloudflare does not actually deploy a VM/container/etc per tenant, but you guys are relying on something like detecting bad behavior and isolating or punishing tenants that try to use attacks in the style of rowhammer: https://developers.cloudflare.com/workers/reference/security... -- so there is secret sauce that is not part of workerd, and one cannot get the same platform as open source.
Meanwhile, somebody like Supabase is making the claim that what you see as open source is what they run, and Deno says their proprietary stuff is KV store and such, not the core offering.
Now, do these vendors have worse security, by trusting the V8 isolates more? Probably. But clearly Cloudflare Workers are a lot more integrated than just "run workerd and that's it" -- which is the base Supabase sales pitch, with Postgrest, their "Realtime" WAL follower, etc.
(I am not affiliated with any of the players in this space; I have burned a few fingers trying to use Cloudflare Workers, especially in any advanced setup or with Rust. You have open, valid, detailed, reproducible, bug reports from me.)
I am not very familiar with Supabase edge functions, but it appears to be based on Deno. According to Deno's documentation, it does not implement hardening against runtime exploits, instead recommending that you set that up separately:
https://docs.deno.com/runtime/fundamentals/security/#executi...
The intro blog post for Supabase edge functions appears to hint that, in production, they use Deno Deploy subhosting: https://supabase.com/blog/edge-runtime-self-hosted-deno-func...
Note that Deno Deploy is a hosting service run by Deno-the-company. My understanding is that they have proprietary components of their hosting infrastructure just like we do. But disclaimer: I haven't looked super-closely, maybe I'm wrong.
But yes, it's true that we don't use containers, instead we've optimized our hosting specifically for isolates as used in workerd, which allows us to run more efficiently and thus deploy every app globally with better pricing than competitors who only deploy to one region. Yes, how we do that is proprietary, just like the scheduling systems of most/all other cloud providers are also proprietary.
But how does that make anyone "tied to one vendor"?
2 replies →