I guess one way would be to name your executable/object code appropriately, eg. mywebapp.io.exe, and have what would be a kind of reverse proxy (listening on a

I guess one way would be to name your executable/object code appropriately, eg. mywebapp.io.exe, and have what would be a kind of reverse proxy (listening on a socket) open this executable/dll and apply it to incoming requests to mywebapp.io. It's really just associating executables with a host/domain name, isn't it? Of course, it would be nice to serve different resources on the same domain using different executables, but I guess this could work too, if we just define domain->resource->executable routes. It's really just changing the interface from a TCP socket, that a running executable is listening on, to something more sane, like an .so/.dll file which exposes a httpmain() function which accepts a HTTP request as an argument. Then the reverse proxy would be a caller of a function, rather than a dispatcher of data. Then Amazon/Google/MSAzure would have this reverse proxy, which wouldn't be a reverse proxy at all anymore, running on their infrastructure. You would distribute your web app as a Xen image, and the reverse proxy/"web function proxy" would boot up your VM instance on incoming requests, charging for the number of milliseconds the instance runs.