> ## Documentation Index > Fetch the complete documentation index at: https://langchain-5e9cc07a-preview-fjmorr-1786082951-7fc5d1b.mintlify.site/llms.txt > Use this file to discover all available pages before exploring further. # LangSmith Engine on self-hosted > How LangSmith Engine runs in a self-hosted deployment, what it depends on outside your environment, and how it handles your data. 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](https://www.langchain.com/contact-sales) 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](/langsmith/engine-overview). 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](/langsmith/deploy-self-hosted-full-platform#enable-engine). To connect it to your source code, create and configure your own GitHub App as described in [Connect Engine to GitHub](/langsmith/engine-github). 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, 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: | Cloud | Region | Status | | ----- | ------ | --------- | | AWS | US | Available | | GCP | US | Available | | AWS | EU | Planned | | Azure | US | Planned | Contact your account team to confirm coverage for your region and for current timing. The Azure section below describes future availability, not a deployment 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 the LSI gateway for its cloud, listed in the per-cloud sections below. * 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 the model provider over private networking inside 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 the model provider process that content to serve the request. LSI does not persist prompt or completion bodies. Your cluster must allow outbound HTTPS to that gateway. 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](/langsmith/engine-security). ### AWS (available in US) The gateway host is `beacon.aws.langchain.com`. LSI routes requests to AWS Bedrock in LangChain's AWS environment. Architecture diagram. Your VPC contains the LangSmith UI, an NLB, an EKS cluster running LangSmith services, and storage on S3, RDS, and ElastiCache. LangChain's cloud contains billing, a monitoring stack, and LangSmith Intelligence, which sends model inference requests to Bedrock. The two environments are connected by a private link. ### GCP (available in US) The gateway host is `beacon.langchain.com`. LSI routes requests to Vertex in LangChain's GCP environment. That is the same host self-hosted LangSmith already uses for license verification and billing telemetry, so a GCP deployment adds a path rather than a new egress destination. See [Configure egress](/langsmith/self-host-egress). Architecture diagram showing a self-hosted LangSmith deployment in your GCP project connecting to LangSmith Intelligence in LangChain's cloud, which sends model inference requests to Vertex ### Azure (planned) Self-hosted Engine support on Azure is planned. Contact your account team for current timing. The diagram below shows the intended architecture. Architecture diagram showing a self-hosted LangSmith deployment in your Azure environment connecting to LangSmith Intelligence in LangChain's cloud, which sends model inference requests to Foundry ## 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: * **Your environment:** Engine orchestration and LangSmith-stored traces remain in your self-hosted deployment. * **LangChain's environment:** Content Engine sends is processed by LSI and the model provider. 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](/langsmith/engine-security). ## See also * [Enable Engine on self-hosted](/langsmith/deploy-self-hosted-full-platform#enable-engine) * [Connect Engine to GitHub](/langsmith/engine-github) * [Engine](/langsmith/engine-overview) * [Configure Engine](/langsmith/engine) * [Engine security](/langsmith/engine-security) * [Engine webhooks](/langsmith/engine-webhooks) ***
[Connect these docs](/use-these-docs) to Claude, VSCode, and more via MCP for real-time answers. [Edit this page on GitHub](https://github.com/langchain-ai/docs/edit/main/src/langsmith/engine-self-hosted.mdx) or [file an issue](https://github.com/langchain-ai/docs/issues/new/choose).