Because you can't, in the general case, recreate the setup on a different platform? That's like the definition of that expression.
BTW here's Deno saying Deno Deploy is process-per-deployment with seccomp. No idea if that's always true, but I'd expect them to boast about it if they were doing something different. https://deno.com/blog/anatomy-isolate-cloud
Process-per-deployment is something you can reasonably recreate on top of K8S or whatever for self-hosting. And there's always KNative. Note that in that setting scheduling and tenant sandboxing are not the responsibility of the hosting provider.
Personally, I haven't really felt that cold starts are a major problem when I control my stack, don't compile Javascript at startup, can leave 1 instance idling, and so on. Which is why I'm pretty much ok with the "containers serving HTTP" stereotype for many things, when that lets me move them between providers with minimal trouble. Especially considering the pain I've felt with pretty much every "one vendor" stack, hitting every edge case branch on my way falling down the stack of abstractions. I've very very much tried to use Durable Objects over and over and keep coming back to serving HTTP with Rust or Typescript, using Postgres or SQLite.
Pretending you don't see the whole argument for why people want the option of self-hosting the whole real thing really comes across as the cliched "It is difficult to get a man to understand something, when his salary depends upon his not understanding it!"
And that part isn't open source, AFAICT.
> Because you can't, in the general case, recreate the setup on a different platform?
You also can't recreate Lambda on Google Cloud since Lambda's scheduler is not open source.
But you can use Google Cloud Functions instead.
None of these schedulers are open source. Not Deno Deploy, not Supabase, and yeah, not ours either. Standard practice here is to offer an open source local runtime that can be used with other schedulers, but not to open source the cloud scheduler itself.
> Pretending you don't see the whole argument for why people want the option of self-hosting the whole real thing
Yes I get that everyone would like to have full control over their whole stack and would like to have it for free, because of course, why wouldn't you? I like those things too!
But we're a business, we gotta use our competitive advantage to make money.
The argument that I felt mariopt was making, when they said "being tied to only 1 vendor is problematic", is that some proprietary technology locks you in when you use it. Like if you build a large application in a proprietary programming language, then the vendor jacks up the prices, you are stuck. All I'm saying is that's not the case here: we've open sourced the parts needed so that you can switch vendors. The other vendor might not be as fast and cheap as us, but they will be just as fast and cheap as they'd have been if you had never used us in the first place.
I will also note, if we actually open sourced the tech, I think you'd find it not as useful as you imagine. It's really designed for running a whole multi-tenant hosting service (across a globally distributed network) and would be massive overkill for just hosting your own code. workerd is actually better for that.
> Durable Objects
I want to be forthright and admit my argument doesn't currently hold up here. workerd's implementation of Durable Objects doesn't scale at all, so can't plausibly be used in production. We actually have some plans to fix this.
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"?