Skip to main content
Each conversation runs as a separate opencode worker process inside a single agent pod. gVisor is a user-space kernel that sits between the worker and the host kernel, so a worker that runs arbitrary shell (Langy workers spawn git, gh, and npm) has a much smaller pod-to-host escape surface than a normal container. On LangWatch Cloud the pod always runs under gVisor. Self-hosted, the chart pins the pod to a gvisor RuntimeClass by default; on a cluster without one the pod waits rather than silently dropping to the node’s runtime. Any sandboxed RuntimeClass works (a Kata class on AKS, for example). Running unsandboxed takes an explicit pair, runtimeClassName: "" plus acceptUnsandboxedRuntime: true; the chart’s render-time fail guard refuses the first value alone. You then lose the pod-to-host boundary and keep only the in-pod walls below.

​
Isolation layers

Langy is isolated at several layers, from the pod boundary down to the walls between two conversations sharing one pod. Weakest to strongest: The manager process runs as root in the container, which is load-bearing: assigning a distinct UID per worker needs CAP_SETUID, CAP_SETGID, and CAP_CHOWN. To keep the blast radius small, the container drops all capabilities and adds back only five: CHOWN, DAC_OVERRIDE, FOWNER, SETUID, and SETGID. It also sets allowPrivilegeEscalation: false and readOnlyRootFilesystem: true. It omits fsGroup, since sharing it would reopen the cross-worker file boundary, and sets automountServiceAccountToken: false because the manager makes no Kubernetes API calls.

​
Why egress is enforced at L7, not with iptables

gVisor’s kernel implements no netfilter. iptables and nftables fail in every mode under gVisor, so the usual way to control a container’s outbound traffic (an iptables OWNER-match DROP or a REDIRECT to a local proxy) is not available here. That is why Langy enforces egress at the application layer instead: a per-worker CONNECT proxy (ADR-043) that the worker’s HTTPS_PROXY points at. It checks TLS, checks the destination against the allow-list, and cross-checks the TLS SNI against the CONNECT authority to block domain fronting. The earlier iptables-based rule and its NET_ADMIN capability were removed because they are dead under gVisor.
Isolation limits (state these to a regulated buyer).Today the per-worker Unix accounts are a sibling-process boundary, not a full per-tenant boundary. Multiple workers still share one gVisor sandbox and one network namespace (ADR-053, Proposed). The file and control-port walls above stop one worker from reading another worker’s secrets or driving another worker’s control server, but they do not give each conversation its own kernel or its own network stack.The stock L7 egress adapter is cooperative, not mandatory. It enforces the allow-list only for traffic that goes through the proxy. A prompt-injected worker that ignores HTTPS_PROXY and dials an external IP directly on :443 is monitored, not blocked, in the stock pod.The mandatory-enforcement end states (a Cilium toFQDNs policy, or a per-worker network namespace that needs CAP_SYS_ADMIN) are designed, not shipped. Do not read this page as a claim of hard tenant isolation by default.
The defence-in-depth mitigations that are shipped today:
  • CGNAT egress deny. The 100.64.0.0/10 range is blocked at L3/L4, so a worker cannot reach the node-local link addresses that some managed Kubernetes networking uses.
  • Dropped default service-account token. automountServiceAccountToken: false; a worker that reached the Kubernetes API would have no token to present.
  • Public-subnet node placement (opt-in). You can schedule the agent pod on a node group that has no route to your private data tier, so a full escape lands somewhere with no path to your databases.
For a self-hosted install, egress is denied by default: networkPolicy.allowExternalHttps is false, so Langy cannot reach the internet at all until you enable it. Turning it on for GitHub is covered in Networking and egress and the GitHub App setup.

​
What the sandbox can and cannot reach

  • Can reach (when configured): the LangWatch API (through the per-session langwatch CLI credentials), the LangWatch AI Gateway for LLM traffic, and github.com / api.github.com / codeload.github.com when external HTTPS is enabled.
  • Cannot reach: RFC 1918 private ranges, CGNAT, and the cloud metadata endpoint. These are blocked at L3/L4 to prevent SSRF and IMDS credential theft, so the block holds regardless of what the worker attempts.
  • Reaches only through the adapter, by cooperation: any other external host goes through the L7 egress adapter, which enforces the project allow-list and the operator floor. In the stock pod that path is cooperative, not mandatory: a worker that ignores HTTPS_PROXY and dials a public address on :443 directly is monitored rather than blocked, per the limits above.
  • Does not keep at rest: nothing durable lives worker-side. The manager wipes the sessions root on boot, and the idle reaper deletes a worker’s home once it has been idle for 10 minutes, so clones and injected credentials do not survive.
Also check: Data flow and privacy, What Langy can do in your GitHub, Self-hosting: networking and egress.

​
Reference