Hey everyone! 👋 I've been seeing conversations lately around challenges with self-hosting OpenHands, especially related to Docker setups, and I'd love to hear more from the community. If you're currently self-hosting, would you mind sharing: • What does your setup look like? (Docker, bare metal, proxmox etc.) • Has it been relatively smooth, or did you hit any major snags getting things running? • Any tips or configs that made your life easier? I'd really like to learn and understand where self-hosting of the GUI is working well and where it's falling short. So your experience, good or bad, helps us make things better for everyone 😄

I am leaning onto Docker sandboxes for local deployment of the openhands AGENT (not necessarily over a locally hosted model). It’s complex but it’s coming together. Docker sandboxes are also quite new and they had some breaking changes. I think they are well worth it though: they go beyond just a docker container, because they provide filesystem, network, and hypervisor isolations, whereas a docker container only offers filesystem isolation. If you are running in a VM somewhere, you can just run a container because the rest is kind of taken care of at the VM level on the hosting environment, but running a container in the local workstation is not nearly enough in terms of safety, hence the use case of docker sandboxes. I have put together a sample implementation here: https://github.com/atineoSE/ola/tree/main

Running docker with

serve

was pretty straightforward for me once I had Docker Desktop running. I've been using it on projects along with the CLI inside vscode. I know some folks are more interested in getting a standalone external server setup where they can load up OpenHands for a specific project. I've been using the cloud (https://app.all-hands.dev/) to do some vibe coding on the go but I also want to try getting my own instance running too.

Hey @hundreds-twilight-32833! We've been self-hosting OpenHands (v1.5) via Docker Compose on Linux, behind a corporate VPN that routes to an internal OpenAI-compatible LLM gateway. It's working now, but getting there was a journey. Worth noting upfront: this is our local developer workstation setup. As Adrian mentioned,

--network host

removes network isolation, which is a trade-off we accepted because our main blocker was VPN/DNS access from containers. Our dev machines are already inside the corporate network, so the risk profile is low for this use case. For our planned internal production deployment on Kubernetes, we expect most of these networking workarounds to be unnecessary since the cluster is already inside the corporate network with proper DNS and routing. Setup: Docker Compose, --network host for both the main container AND sandbox (

SANDBOX_USE_HOST_NETWORK=true

), plus a custom Python reverse proxy between OpenHands and our LLM API. Issues we hit: 1. DNS + VPN routing in containers: Bridge-mode containers can't resolve or route to internal corporate domains. We had to set our VPN DNS server in /etc/docker/daemon.json AND switch everything to --network host. This is probably the #1 blocker for anyone behind a corporate VPN. 2. host.docker.internal not resolved in host network mode: When sandbox runs in --network host, it can't resolve host.docker.internal (used for webhook/MCP communication back to the main container). We had to manually add 127.0.0.1 host.docker.internal to /etc/hosts. It would be great if OpenHands could fall back to localhost or 127.0.0.1 when in host network mode. 3. litellm parsing crash on token details: Our LLM gateway returns integer values in prompt_tokens_details and completion_tokens_details (specifically a cache_creation_token_details field). litellm chokes on these. We built a reverse proxy that intercepts responses and sanitizes those fields to null. This is really a litellm issue, but it bit us through OpenHands. 4. Orphaned sandboxes + port conflicts: In host network mode, all sandboxes share the same port namespace. If an old sandbox isn't cleaned up, port 8000 stays occupied and new sandboxes fail silently or with Address already in use. We added auto-cleanup of oh-agent-server-* containers to our start/stop scripts. 5. GUI overwrites settings.json: The OpenHands GUI sometimes strips critical LLM provider fields (provider, base_url, models) from settings.json, breaking the connection. We have to re-inject them manually. 6. Sandbox startup timeout: The hardcoded 15s timeout is tight. If the agent-server image isn't cached, the sandbox fails. Pre-pulling images before startup solved it. What made our life easier: • A Makefile wrapping everything: make setup (prerequisite checks), make init (settings template), make auth (daily token rotation), make start/stop/restart; • Pre-pull of Docker images before docker-compose up • Automatic cleanup of orphaned sandboxes on both start and stop • A dedicated reverse proxy for LLM response sanitization Feature requests that would help corporate/VPN users: • Better documentation for --network host + VPN setups • Fallback from host.docker.internal to localhost when in host network mode • Configurable sandbox startup timeout • More resilient settings.json management (GUI shouldn't strip provider fields) Happy to share our setup scripts if useful. Overall, once we figured out the networking layer, it's been solid!

I'd love to learn more about it @ambitious-microphone-55463 if you have some time to chat https://calendar.app.google/65haF3L2ndwCxF9j8 . Just let me know if nothing open fits your schedule and I can adjust. Great feedback!

Hi @hundreds-twilight-32833. I'm running OH inside the official container (make docker-run or make docker-dev) on a remote server and connecting via browser. This is the basic setup, and it doesn't work out of the box because the browser tries to connect directly to the sandbox (browser requesting http://localhost or host.docker.internal 🙂). It was working fine with V0 because requests were routed to the sandbox. This is how it should be: the browser should only connect to the same standard host and port (https://myserver.com ). I published a PR with a websocket gateway to fix this, but I didn't support all existing endpoints yet (VS Code, changes, etc). IMO, OpenHands Inc. should address the self-hosting issue. It's not true that you need to set up a complex proxy in front. A simple router like in the previous version is enough. If you want to route the services created inside a sandbox, that's another story. What a normal developer expects is an app that works on localhost or behind a simple reverse proxy. If this basic use case is not supported, it's clear that the company has other intentions. We also have a much more complex setup using BTRFS container snapshots, a complex proxy to allow the agents to publish services, support for "docker in docker in docker in docker" for testing complex platforms, etc, but I don't want to complicate things here.

Thanks for the feedback Christopher! Devin and I work for OpenHands so we're keenly interested in this type of feedback, and we are both actively reaching out to the community to understand friction points.

What a normal developer expects is an app that works on localhost or behind a simple reverse proxy. If this basic use case is not supported, it's clear that the company has other intentions.

I think our CEO addressed this concern in this post on GitHub. It's definitely a reasonable use case to support; do you have a link to that PR we can pass along to our engineers? V1 has made some breaking changes but we're open to PRs to make sure we address any gaps like this 🙂 Thanks again for all your help and contributions!

This is the PR: https://github.com/OpenHands/OpenHands/pull/13516 I added comments at the beginning.