Skip to main content
Self-hosted Engine requires LangSmith Helm chart 0.16.0 or later and a license that includes the Engine entitlement. It is not available on earlier chart versions. Contact your account team to have the entitlement added to your order.
LangSmith Engine is an agent within LangSmith that monitors your production traces, clusters them into issues, diagnoses each issue against your source code, proposes a fix as a PR, and identifies ground truth evals to add to your datasets. For a product overview, see Engine. This page explains how Engine runs in a self-hosted deployment, what it depends on outside your environment, and what that means for your data. To install it, see Enable Engine. Engine works with three kinds of data:
  • Code (optional): your agent’s source, which Engine reads to diagnose issues and propose fixes.
  • Traces: runtime data from your agents, which can include user messages, tool outputs, and PII.
  • Model: the LLM calls Engine makes to run diagnosis, generate fixes, and write evaluators.
In a self-hosted deployment, Engine’s orchestration runs inside your VPC as part of LangSmith: reading traces, reading code, and running its detect, fix, and verify loop. It cannot run entirely there, however. Engine depends on LangSmith Intelligence (LSI), a LangChain-managed zero data retention (ZDR) service hosted in AWS, and sends LSI the content it needs to do its work.

Availability by cloud and region

Engine depends on LSI coverage. That coverage is expanding, so availability varies by cloud and region: Contact your account team to confirm coverage for your region and for current timing. The GCP and Azure sections below describe future availability, not deployments you can enable today.

How it works

LSI is the LangChain-managed service that powers Engine. The flow:
  • Your self-hosted Engine sends an HTTPS request to https://beacon.aws.langchain.com/intelligence.
  • Engine authenticates with a short-lived license JWT obtained during LangSmith license verification. You do not provide separate model-provider credentials.
  • LSI validates the JWT and routes the request to AWS Bedrock through private AWS networking in LangChain’s environment.
  • LSI returns the response to your self-hosted Engine.
Each request carries the trace content, code, and intermediate outputs Engine needs to do its work. LSI and AWS Bedrock process that content to serve the request. LSI does not persist prompt or completion bodies. Your cluster must allow outbound HTTPS to beacon.aws.langchain.com. This documentation does not assume that the connection from your environment to LSI uses AWS PrivateLink. If your security policy requires private connectivity, contact your account team to confirm availability and setup before enabling Engine. If the connection to LSI is unavailable, Engine fails closed. There is no in-cluster model and no secondary provider to fall back on, so the affected run ends with an error rather than degrading to lower-quality output. The rest of your LangSmith deployment is unaffected, and Engine tries again on its next scheduled scan.

What LangSmith Intelligence retains

LSI does not persist prompt or completion bodies. It retains the following metadata for usage attribution and billing:
  • Account, workspace, and project identifiers used to attribute usage.
  • Model and token-usage metadata used for billing.
For model-provider retention and training commitments, see Engine security.

AWS (available in US)

Self-hosted Engine sends its requests through the LSI gateway. LSI routes them to AWS Bedrock in LangChain’s AWS environment.

AWS: LangSmith and Engine run in your VPC; LSI and Bedrock run in LangChain's AWS environment.

GCP (coming soon)

Self-hosted Engine support on GCP is coming soon. Contact your account team for current timing. The diagram below shows the intended architecture.

GCP (intended): LangSmith and Engine run in your project; LSI and Vertex run in LangChain's GCP environment.

Azure (planned)

Self-hosted Engine support on Azure is planned. Contact your account team for current timing. The diagram below shows the intended architecture.

Azure (intended): LangSmith and Engine run in your environment; LSI and Foundry run in LangChain's Azure environment.

Model selection and quality

Model selection drives much of what makes Engine effective. Engine uses different models, tuned differently, for each step of its work: clustering issues, diagnosing root cause against your code, generating a fix, and writing the evaluator that verifies it. LangChain tunes these models for both quality and token efficiency, and upgrades them as better models ship. Managed inference makes that possible. Because Engine always runs the model LangChain has tuned for each step, behavior stays consistent and improves as those models are upgraded. A bring-your-own-key setup would instead tie Engine to the models you have configured, so tuning and token efficiency would vary from request to request.

What this means for your data

In a self-hosted deployment, Engine separates data handling between your environment and LangChain’s AWS environment:
  • Your environment: Engine orchestration and LangSmith-stored traces remain in your self-hosted deployment.
  • LangChain’s AWS environment: Content Engine sends is processed by LSI and AWS Bedrock. LSI retains the billing metadata listed above, but it does not persist prompt or completion bodies.
Engine’s deployment-independent data handling, including zero data retention with every model provider and no use of customer data to train or fine-tune models, is described in Engine security.

See also