Your comment might be a bit blunt, but those harsh reactions to it do not help, either (but thanks for voicing for me though) I just want to be clear that I am

Your comment might be a bit blunt, but those harsh reactions to it do not help, either (but thanks for voicing for me though) I just want to be clear that I am not affiliated with Deno Deploy in any way. I think that vendor lock-in is a fair concern. I actually added documentation on self-hosting on a server after I saw your comment. The repository had a lot of reference to Deno Deploy, because it’s vendor-specific feature, BroadcastChannel, made it possible for the service to be distributive while maintaining low-latency, based on my own test results. Another great product that offers a similar feature is Cloudflare Worker (Durable Objects). However, it’s server framework is more restricted that I am not able to write a TCP hole-punching rendezvous service on top of it. Yes, I’ve been trying to implement this idea for long until I found Deno Deploy. IMHO, vendor-specific features can be carefully designed to avoid much of the migration cost. Usually, those features try to provide an interface that is close to open standard. For example, when I first tried to migrate a Python service from container to Vercel serverless function (now.sh at the time), I only changed one line of code and wrote a 10-line config, because they accepted any Python app written in WSGI. It’s not always a dilemma when it comes to decision on vendor-specific features.