I see many issues related with the change in v1 regarding websocket connection to the sandbox/runtime agent. Can someone please confirm this: https://github.com/OpenHands/OpenHands/issues/13504 ?

Maybe @straight-sundown-84319 can shed some light. I know he was working on v1 apis. Or he can tag someone else who knows more.

This was actually done before the introduction of V1 with the introduction of nested runtimes, back in last Aug / Sept. The reasoning was that given the inherent instability of sandbox pods, the agent server loop for each conversation was moved into the sandbox and the sandboxes became a lot more autonomous than previously - this meant that issues in a single conversation had a lot less effect on the overall system stability. Please clarify: What do you mean by "self hosted"? Do you mean using the enterprise codebase or the OSS codebase? With the enterprise codebase, typically In our self hosted environments using K8s, an ingress is used to control access to runtime pods and subdomain ids are assigned that way - but path based routing is an option. (So instead of

https://<MY_RUNTIME_ID>.runtime.<MY_DOMAIN>

you can do

https://<MY_DOMAIN>/runtime/<MY_RUNTIME_ID>/

) We avoid this in our SAAS environment due to security concerns - we don't want any arbitrary app server exposed by a single user sandbox to be able to potentially set cookies and such for other sandboxes. We avoided a single websocket endpoint as that would mean that the app server is acting as a proxy for the sandboxed agent servers rather than having clients connect to the sandboxes directly - If you really need it, such a proxy could be added - though this would probably be isolated and separate from the other use cases, and require specific changes in both the frontend and the backend.

Here is a related PR someone created to proxy it: https://github.com/OpenHands/OpenHands/pull/12591

Oh. I also added a WebSockets Gateway: https://github.com/OpenHands/OpenHands/pull/13516