Skip to main content
Langy is the assistant inside LangWatch: it answers questions about your traces, runs LangWatch’s own CLI on your behalf, and can open pull requests against your repositories. On a self-hosted install it runs as one extra pod, alongside the app, and it is off until you turn it on.

​
What it needs

Everything else is handled by the chart: the secret the app and the agent use to authenticate to each other, and the in-cluster addresses they use to reach the gateway and to send answers back.

​
Turning it on

That deploys the agent, wires the app and the workers to it, and makes the assistant available to everyone in your install. Give it a model to talk to by configuring a model provider for the project, then open the assistant from any page.
Langy is single-tenant by nature here: every person with access to your LangWatch install can use it, and it runs with the permissions of whoever is asking. To roll it out gradually instead, see Staged rollout.

​
Clusters without a sandboxed runtime

Langy’s workers run shell written by a language model, so the chart asks for a sandboxed runtime, gVisor, and refuses to install without one rather than dropping the sandbox quietly. Managed offerings like GKE Sandbox provide it; most self-managed clusters do not. If yours cannot, say so explicitly and the install proceeds:
What you keep either way: each conversation’s worker runs under its own UID with its own credentials, workers cannot read each other’s, and a NetworkPolicy bounds what any of them can reach. What the sandbox adds on top is protection of the node itself from a worker that escapes its container. An install whose users are all colleagues carries a very different risk here than one exposed to untrusted users, and that judgement is yours to make.

​
Letting Langy reach the internet

Langy’s tools shell out to git, gh, and package managers. Egress to the internet is off by default, because these workers hold the requesting user’s API key and GitHub token:
Private address ranges and the cloud metadata endpoint stay blocked either way, so a worker cannot use this to reach your internal services. Without it, Langy still answers questions about your data; what stops working is anything that talks to GitHub or installs a package.

​
Watching Langy work

Langy’s own turns can be traced into one of your own LangWatch projects, so you can see the model calls it made, the tools it ran, and what each one cost. Create an API key in the project you want to mirror into, then:
Reading the key rather than passing it as an argument keeps it out of your shell history and out of the process list on the machine you run this from.
The endpoint resolves to your own install automatically. Set langyagent.mirror.traceEndpoint only to mirror into a different LangWatch deployment.

​
Staged rollout

To open Langy to a few projects before everyone, keep the rollout flag authoritative:
Langy then stays dark until you enable release_langy_enabled, or add targeting rules for specific projects and organizations, from /ops/feature-flags in your install.

​
Bringing your own secrets

With autogen.enabled: false you supply the app Secret yourself. Add a LANGY_INTERNAL_SECRET key to it, which the app, the workers, and the agent all read to authenticate to each other:
The install checks for the key and stops with a message naming it, rather than leaving three pods in CreateContainerConfigError.

​
Turning it off

The agent pod and every reference to it are removed on the next upgrade. Nothing else in your install changes.