> ## Documentation Index
> Fetch the complete documentation index at: https://langwatch.ai/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Langy Assistant

> Run LangWatch's in-product AI assistant on your own cluster

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

| Requirement                                    | Why                                                       |
| ---------------------------------------------- | --------------------------------------------------------- |
| The `langyagent` pod                           | Runs one isolated OpenCode worker per conversation        |
| A model provider                               | Langy talks to a model like every other LangWatch feature |
| A sandboxed runtime, or an explicit acceptance | The workers execute model-written shell                   |

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

```yaml theme={null}
langyagent:
  chartManaged: true
```

```bash theme={null}
helm upgrade langwatch langwatch/langwatch -n langwatch -f values.yaml
```

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](/docs/platform/model-providers) for the project, then
open the assistant from any page.

<Note>
  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](#staged-rollout).
</Note>

## Clusters without a sandboxed runtime

Langy's workers run shell written by a language model, so the chart asks for a
sandboxed runtime, [gVisor](https://gvisor.dev/docs/user_guide/install/), 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:

```yaml theme={null}
langyagent:
  chartManaged: true
  runtimeClassName: ""
  acceptUnsandboxedRuntime: true
```

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:

```yaml theme={null}
langyagent:
  networkPolicy:
    allowExternalHttps: true
```

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:

```bash theme={null}
read -rsp "Mirror project API key: " KEY
kubectl -n langwatch create secret generic langwatch-langyagent-mirror \
  --from-env-file=/dev/stdin <<< "LANGY_MIRROR_TRACE_KEY=$KEY"
unset KEY
```

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.

```yaml theme={null}
langyagent:
  mirror:
    existingSecretName: langwatch-langyagent-mirror
```

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:

```yaml theme={null}
langyagent:
  chartManaged: true
  enableForAllUsers: false
```

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:

```bash theme={null}
kubectl -n langwatch patch secret langwatch-app-secrets \
  -p "{\"stringData\":{\"LANGY_INTERNAL_SECRET\":\"$(openssl rand -hex 32)\"}}"
```

The install checks for the key and stops with a message naming it, rather than
leaving three pods in `CreateContainerConfigError`.

## Turning it off

```yaml theme={null}
langyagent:
  chartManaged: false
```

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