Still though:

> As hinted above, the full Cloudflare Workers service involves a lot of technology beyond workerd itself, including additional security, deployment mechanisms, orchestration, and so much more. workerd itself is a portion of our runtime codebase, which is itself a small (albeit critical) piece of the overall Cloudflare Workers service.

The parts we released are the parts you'd need to host your app on other typical cloud hosting services in a typical way (e.g. using kubernetes), which should address lock-in concerns.

The parts we did not release are the parts that would only really be useful for building your own hosting service to compete with Cloudflare. These parts would not be particularly useful to someone who merely wants to run their own code -- in fact, they'd be excessively difficult to operate for that use case. This is on par with other services, e.g. my understanding is Deno Deploy has not released this part of their code either.

I get it, but it means you end up with the arbitrary and limited API that you’d mostly only use for the benefits at the edge, except now you aren’t at the edge and still have all the limitations. Which is the point I’ve been making.