This is pretty cool. Have you considered not killing the instance after the user disconnects, but pausing the container instead? This opens up the whole tradeoff space between how long you keep the state vs cost to the infrastructure/price to the user.
In the case of containers it gets tricky because of how it interacts with the scheduler (e.g. if a node is idle but has a bunch of paused containers that could be unpaused at any time, the scheduler has to decide how to proceed), but I love the concept. It's something I've thought a bit about in a world where the server can be compiled to WebAssembly, because it's imaginable to suspend it and serialize the memory state so that it can be sent off to storage somewhere and pulled out when the next request comes in. This was actually part of the motivation behind a library I wrote called Stateroom (https://github.com/drifting-in-space/stateroom), which creates a stateful WebSocket server as a WebAssembly module, but I haven't yet implemented the ability to freeze the state of the module between requests.
