OpenHands

OpenHands Self-Hosting: Run Issue-to-PR Agents in Your Own Sandbox When Compliance Blocks Hosted Coding Agents

Sahil Kathpal

• 4 min read

Hosted coding agents are convenient until legal, security, or customer commitments say your source code cannot leave controlled infrastructure. OpenHands is interesting for those teams because it offers open-source local usage and an enterprise self-hosted model where agents run in your environment.

This article outlines how to think about self-hosting OpenHands for issue-to-PR workflows without weakening compliance controls.

The short version

  • Self-hosting is about control: code location, runtime isolation, identity, logs, and LLM routing.
  • OpenHands Enterprise documentation describes self-hosted/private-cloud deployment, SSO/SAML, RBAC, source control integrations, and containerized sandbox runtimes.
  • Treat each agent run as untrusted code execution in a sandbox.
  • Keep the PR workflow: agents propose changes; branch protection and human review decide merges.
  • Compliance requires operational controls, not just "runs on our servers."

Why hosted agents get blocked

Security teams usually object to hosted coding agents for specific reasons:

  • source code leaves the network boundary;
  • prompts and tool outputs may contain secrets;
  • agent runtimes execute untrusted commands;
  • logs are stored by a third party;
  • identity and access do not map to enterprise policy;
  • the vendor cannot meet data residency or audit requirements.

Self-hosting can address these, but only if the deployment is designed as a controlled system. Running an agent container on a random VM is not enough.

Target architecture

A compliant issue-to-PR deployment needs clear boundaries:

Issue tracker / Git provider
        |
        v
Agent orchestrator
        |
        +--> ephemeral sandbox container
        |       - cloned repo
        |       - limited credentials
        |       - no production network by default
        |
        +--> LLM gateway
        |       - approved providers
        |       - logging/redaction policy
        |
        +--> audit store
                - prompts metadata
                - tool calls
                - commits and PR links

OpenHands' enterprise docs describe self-hosted or private-cloud deployment, bring-your-own-key LLM provider configuration, identity integrations, source control integrations, and isolated containerized sandboxes. Those are the primitives. Your job is to wire them into your controls.

Sandbox every run

A coding agent is an automated developer that can execute commands. Assume the repository may contain malicious scripts, compromised dependencies, or test commands that try to access the environment.

Minimum sandbox rules:

  • one ephemeral container or VM per task;
  • checkout only the target repository and branch;
  • mount credentials read-only and scoped;
  • no access to production databases;
  • default-deny network egress, with explicit allowlists;
  • CPU, memory, disk, and wall-clock limits;
  • artifact collection for logs and diffs;
  • destroy the environment after the run.

If tests require services, provide disposable test services. Do not point agents at shared staging systems unless the risk is understood.

Route LLM traffic deliberately

Self-hosting the agent does not necessarily mean self-hosting the model. OpenHands Enterprise documentation lists the ability to connect to providers such as Anthropic, OpenAI, AWS Bedrock, Azure OpenAI, Google Vertex AI, or other providers.

Make the routing explicit:

llm_policy:
  default_provider: azure-openai-prod
  allowed_providers:
    - azure-openai-prod
    - bedrock-prod
  disallowed:
    - personal-api-keys
    - unmanaged-proxies
  logging:
    prompt_content: redacted
    metadata: retained_180_days

For regulated codebases, put an internal LLM gateway in front of providers. It can enforce model allowlists, redact known secret patterns, attach request IDs, and centralize audit logs.

Integrate with Git, do not bypass it

Issue-to-PR agents should create branches and pull requests, not push to protected branches.

Recommended workflow:

  1. Human labels or assigns an issue to the agent.
  2. Orchestrator creates a sandbox and checks out the repo.
  3. Agent implements the change and runs required tests.
  4. Agent pushes a branch with scoped credentials.
  5. Agent opens a draft PR linked to the issue.
  6. CI, CODEOWNERS, branch protection, and human review decide merge.

This keeps your existing software delivery controls intact.

Access control and auditability

Map agent actions to human intent. If Alice assigns an issue to the agent, the resulting run should record:

  • who requested it;
  • which issue and repository were used;
  • which model/provider was used;
  • what credentials were granted;
  • which commands were executed;
  • which files changed;
  • where the PR was opened;
  • why the run stopped.

For enterprise deployments, use SSO/SAML and RBAC rather than shared admin tokens. Separate permissions for "request an agent run," "approve privileged tools," "view logs," and "configure providers."

Compliance checklist

Before moving beyond a pilot, answer these questions:

  • Where are prompts, logs, embeddings, and artifacts stored?
  • Are secrets redacted before model calls and logs?
  • Which networks can sandboxes reach?
  • Can an agent access other repositories by default?
  • Are dependencies installed from approved registries?
  • Is every run tied to a human requester?
  • Can security revoke credentials immediately?
  • Are PRs subject to the same branch protections as human PRs?
  • Is there a retention policy for agent logs?

If any answer is vague, the deployment is not compliance-ready.

Gotchas

Self-hosting increases operational responsibility. You own upgrades, runtime hardening, incident response, and capacity.

Container isolation is not magic. For high-risk code, consider stronger VM isolation or hardened Kubernetes policies.

LLM provider terms still matter. If prompts go to a third-party model, review data processing terms even when the agent orchestrator is self-hosted.

Agents amplify bad tests. A self-hosted agent with weak CI can still produce unsafe PRs quickly.

We're building Grass for teams that want agent work to happen in isolated sandboxes with a clear handoff back to humans. Even when your deployment model differs, the core idea is the same: keep agents contained, make the output reviewable, and preserve the decision point. You can try Grass at https://codeongrass.com.

Conclusion

OpenHands self-hosting is a practical path when hosted coding agents are blocked by compliance requirements. The key is to treat the deployment as a controlled engineering system: isolated sandboxes, explicit LLM routing, enterprise identity, scoped credentials, audit logs, and PR-based delivery. Keep humans and branch protection in the merge path, and let agents accelerate drafts inside your boundary.

Sources

  • OpenHands Enterprise documentation
  • OpenHands GitHub repository and SDK workflow documentation
  • OpenHands documentation on sandboxed runtime patterns