Enable LangSmith Deployment, Fleet, Insights, Chat, Sandboxes, and Engine

In addition to the base LangSmith platform, you can enable the following features:

LangSmith Deployment adds a control plane and data plane that let you deploy, scale, and manage agents and applications directly through the LangSmith UI.
If you don’t need the full UI-based setup, see standalone servers for a lightweight alternative.
Fleet allows you to create, deploy, and manage AI agents directly within LangSmith with no code.
Insights provides AI-powered analysis of your traces and application data within LangSmith.
Chat provides an in-workspace chat experience to help you analyze traces, threads, prompts, and experiment results.
Sandboxes let users run code, expose temporary services, and create memory snapshots from LangSmith.
Engine finds recurring issues in a tracing project, diagnoses them against your source code, and proposes fixes. Engine requires Sandboxes.

These features require an Enterprise plan. Get a demo to learn more.

Prerequisites

Install the base LangSmith platform

Follow the Kubernetes installation guide to install the base LangSmith platform before continuing.

Install KEDA

Run the following commands to install KEDA on your cluster:

helm repo add kedacore https://kedacore.github.io/charts
helm upgrade --install keda kedacore/keda --namespace keda --create-namespace

KEDA automatically scales the deployment system based on queue size.

Configure an ingress

Configure an ingress, gateway, or Istio for your LangSmith instance. All agents will be deployed as Kubernetes services behind this ingress. See Set up an ingress. You must provide a hostname in your langsmith_config.yaml.

Verify cluster capacity

Ensure your cluster has available capacity for multiple deployments. A cluster autoscaler is recommended.

Verify storage

Ensure a valid dynamic PV provisioner or PVs are available on your cluster.

kubectl get storageclass

At least one StorageClass should have a PROVISIONER value (not kubernetes.io/no-provisioner) and be marked (default), or you must configure one before proceeding.

Verify egress

Ensure egress to https://beacon.langchain.com is available. See the egress documentation.

Enable LangSmith Deployment

Components

Enabling LangSmith Deployment provisions the following resources in your cluster:

listener: Listens to the control plane for changes to your deployments and creates or updates downstream CRDs.
LangGraphPlatform CRD: Manages instances of LangSmith Deployment.
operator: Handles changes to your LangSmith CRDs.
host-backend: The control plane.

Enable the feature

To enable LangSmith Deployment, update your langsmith_config.yaml:

Enable deployment in your config

In your langsmith_config.yaml, enable the deployment option. You must also have a valid ingress configured.

config:
  deployment:
    enabled: true

As of v0.12.0, the langgraphPlatform option is deprecated. Use config.deployment for any version after v0.12.0.

(Optional) Configure image mirroring

If you need to mirror images to a private registry, configure the hostBackendImage and operatorImage options in your langsmith_config.yaml. Use the image tags specified in the latest LangSmith Helm chart release.

hostBackendImage:
  repository: "docker.io/langchain/hosted-langserve-backend"
  pullPolicy: IfNotPresent
operatorImage:
  repository: "docker.io/langchain/langgraph-operator"
  pullPolicy: IfNotPresent

(Optional) Configure base agent templates

Override the base agent templates in values.yaml if you need to customize how the operator creates agent Kubernetes resources. The most common use case is adding imagePullSecrets to authenticate with a private container registry. See Configure authentication for private registries for details.

Apply the changes

Run the following command to apply the changes. This command is used throughout this guide whenever you are asked to apply changes. Replace <version> and <namespace> with your values:

helm upgrade -i langsmith langchain/langsmith --values langsmith_config.yaml --version <version> -n <namespace> --wait --debug

Verify that the new pods are running before continuing:

kubectl get pods -n <namespace>

Your instance is now ready to create deployments.

Enable Fleet, Insights, and Chat

Fleet requires LangSmith Self-Hosted v0.13 or later. The standalone deployment model described below requires v0.15 or later.

Each feature requires a Fernet encryption key. You can enable all three features in a single Helm configuration.

Components

Enabling these features provisions the following components in your cluster for each feature (Fleet, Insights, Chat):

api-server: The main API server that handles requests for the feature.
queue: Background task processing queue.
postgres: Dedicated PostgreSQL instance for the feature’s data. Can be replaced with an external PostgreSQL instance.
redis: Dedicated Redis instance for the feature’s caching and pub/sub. Can be replaced with an external Redis instance.

Fleet additionally provisions:

toolServer: Provides MCP tool execution for agents.
triggerServer: Handles webhooks and scheduled triggers.

As of chart 0.16.0, Insights runs on langsmith-insights-engine, a combined image that serves both the insights and engine graphs, and the chart uses it by default. The previous Insights-only image, langsmith-clio, is retired.If your values pin images.engineInsightsAgentImage.repository to langsmith-clio, remove or update that pin before upgrading. The chart rejects it. If you mirror images to a private registry, mirror langsmith-insights-engine and point the repository at your copy. See Mirroring images.

Generate encryption keys

Each feature uses its own Fernet encryption key to encrypt feature-specific secrets such as credentials and tokens. Separate keys allow independent rotation and limit exposure if a key is compromised. Generate one key per feature using Python:

python -c "from cryptography.fernet import Fernet; print(Fernet.generate_key().decode())"

We recommend storing each key in a predefined Kubernetes secret rather than setting them directly in your config file. See Use an existing secret for the relevant parameters: agent_builder_encryption_key, insights_encryption_key, and polly_encryption_key.

Enable features

Add the configuration to your langsmith_config.yaml

Using Kubernetes secrets (recommended)
Using inline values

Reference your existing secret by name. The chart reads agent_builder_encryption_key, insights_encryption_key, and polly_encryption_key from it automatically.

config:
  existingSecretName: "<your-secret-name>"

fleet:
  enabled: true

insights:
  enabled: true

# Chat (formerly Polly)
polly:
  enabled: true

fleetToolServer:
  enabled: true

fleetTriggerServer:
  enabled: true

Set the encryption keys directly in your config file. Avoid committing this file to version control.

fleet:
  enabled: true
  encryptionKey: "<fleet-encryption-key>"

insights:
  enabled: true
  encryptionKey: "<insights-encryption-key>"

polly:
  enabled: true
  encryptionKey: "<chat-encryption-key>"

fleetToolServer:
  enabled: true

fleetTriggerServer:
  enabled: true

If you are migrating from the legacy agentBootstrap deployment model, disable backend.agentBootstrap and the old config.agentBuilder, config.insights, and config.polly flags. These are the flags under the config section, not the top-level fleet, insights, and polly flags shown above.You must also manually delete the existing Fleet, Insights, and Chat deployments through the LangSmith Deployments UI. If you did not use an external PostgreSQL database for Fleet with the legacy agentBootstrap model and want to preserve existing Fleet agents, contact technical support via the Support Portal before applying this configuration.

fleetToolServer and fleetTriggerServer are required for Fleet. These replaced the deprecated agentBuilderToolServer and agentBuilderTriggerServer keys as of v15 of the Helm chart.

Each feature deploys its own dedicated PostgreSQL and Redis instances by default. To use external databases instead, configure the postgres.external and redis.external sections under each feature. For example:

fleet:
  enabled: true
  encryptionKey: "<fleet-encryption-key>"
  postgres:
    external:
      enabled: true
      connectionUrl: "<fleet-postgres-connection-url>"
  redis:
    external:
      enabled: true
      connectionUrl: "<fleet-redis-connection-url>"

Apply the changes

helm upgrade -i langsmith langchain/langsmith --values langsmith_config.yaml --version <version> -n <namespace> --wait --debug

Verify the Fleet, Insights, and Chat pods are running:

kubectl get pods -n <namespace>

(Optional) Enable OAuth tools and triggers for Fleet

To enable OAuth-based tools such as Gmail, Slack, or Linear in Fleet, configure the providerOrgId and add provider IDs for each integration you want to use. You can enable any combination of providers.

Available providers

Provider	Tools enabled	Trigger enabled
`googleOAuthProvider` setup guide	Gmail, Google Calendar, Google Sheets, BigQuery	Gmail
`linearOAuthProvider` setup guide	Linear	-
`linkedinOAuthProvider` setup guide	LinkedIn	-
`microsoftOAuthProvider` setup guide	Outlook, Calendar, Teams, SharePoint, Word, Excel, PowerPoint	Outlook
`salesforceOAuthProvider` setup guide	Salesforce	-
`slackOAuthProvider` setup guide	Slack	Slack

General configuration

Add the following to your langsmith_config.yaml. Include only the providers you need.

fleet:
  oauth:
    # Organization ID where OAuth providers are configured
    providerOrgId: "<your-org-id>"
    # Add provider IDs for integrations you want to enable.
    slackOAuthProvider: "<provider-id>"
    googleOAuthProvider: "<provider-id>"
    linkedinOAuthProvider: "<provider-id>"
    linearOAuthProvider: "<provider-id>"
    microsoftOAuthProvider: "<provider-id>"
    salesforceOAuthProvider: "<provider-id>"

The provider ID must be unique and cannot end with -agent-builder or -oauth-provider.

Provider setup guides

Google OAuth provider

To enable Google OAuth for Fleet, create an OAuth client in GCP and configure it with the required URLs and credentials.

Create OAuth client in GCP

Create a new OAuth client app (Web application) in Google Cloud Console.

Add URLs to GCP

Add the following URLs to your OAuth client, replacing <hostname> with your LangSmith hostname and <provider-id> with the provider ID you’ll use (for example, google):Authorized JavaScript origins:

https://<hostname>

Authorized redirect URIs:

https://<hostname>/api-host/v2/auth/callback/<provider-id>
https://<hostname>/host-oauth-callback/<provider-id>

Copy credentials

Copy the Client ID and Client Secret from the GCP OAuth app.

Configure OAuth provider in LangSmith

In LangSmith, go to Settings > OAuth Providers and add a new provider:

Client ID: from GCP
Client Secret: from GCP
Authorization URL: https://accounts.google.com/o/oauth2/auth
Token URL: https://oauth2.googleapis.com/token
Provider ID: Unique string, for example: google

Apply the changes

Add the LangSmith OAuth provider ID to your langsmith_config.yaml and deploy:

fleet:
  oauth:
    providerOrgId: "<your-org-id>"
    googleOAuthProvider: "<provider-id>"

helm upgrade -i langsmith langchain/langsmith --values langsmith_config.yaml --version <version> -n <namespace> --wait --debug

Microsoft OAuth provider

To enable Microsoft OAuth for Fleet, create an Azure app registration, add the required Microsoft Graph delegated permissions, and configure a Microsoft OAuth provider in LangSmith.

Create an Azure app registration

In the Microsoft Entra admin center, go to Applications > App registrations and create a new registration.

Choose supported account types

Select the account type that matches your deployment. If you need users from multiple Microsoft Entra tenants to authenticate, choose a multi-tenant option. If your deployment is limited to one tenant, you can use a single-tenant app registration.

Add the redirect URI

Add the following web redirect URI, replacing <hostname> with your LangSmith hostname and <provider-id> with your provider ID:

https://<hostname>/host-oauth-callback/<provider-id>

Create a client secret

In Certificates & secrets, create a new client secret. Copy the Application (client) ID and the generated client secret value.

Add Microsoft Graph delegated permissions

In API permissions, add the following Microsoft Graph delegated permissions:

Mail.ReadWrite
Mail.Send
Calendars.ReadWrite
Team.ReadBasic.All
Channel.ReadBasic.All
Channel.Create
ChannelMessage.Send
ChannelMessage.Read.All
Chat.Create
Chat.ReadWrite
User.ReadBasic.All
Files.ReadWrite.All
Sites.ReadWrite.All

LangSmith automatically requests offline_access for Microsoft providers so users can receive refresh tokens.

Grant tenant consent

Grant admin consent for the tenant if your Microsoft 365 policies require it for these delegated permissions.

Configure OAuth provider in LangSmith

In LangSmith, go to Settings > OAuth Providers and add a new provider:

Name: For example, Microsoft
Provider ID: Unique string, for example: microsoft-oauth-provider
Client ID: Application (client) ID from Azure
Client Secret: Client secret value from Azure
Authorization URL: https://login.microsoftonline.com/common/oauth2/v2.0/authorize
Token URL: https://login.microsoftonline.com/common/oauth2/v2.0/token
Provider Type: microsoft
Token endpoint auth method: client_secret_post

If you created a single-tenant app registration, replace common in the authorization and token URLs with your tenant ID.

Apply the changes

Add the following to your langsmith_config.yaml and deploy:

fleet:
  oauth:
    providerOrgId: "<your-org-id>"
    microsoftOAuthProvider: "<provider-id>"

helm upgrade -i langsmith langchain/langsmith --values langsmith_config.yaml --version <version> -n <namespace> --wait --debug

Linear OAuth provider

To enable Linear OAuth for Fleet, create a Linear OAuth app and configure it with the required credentials.

Create a Linear OAuth app

Go to Linear Settings > API > Applications and create a new OAuth application.

Add callback URL

Set the callback URL, replacing <hostname> with your LangSmith hostname and <provider-id> with your provider ID:

https://<hostname>/host-oauth-callback/<provider-id>

Copy credentials

After creating the app, copy the Client ID and Client Secret.

Configure OAuth provider in LangSmith

In LangSmith, go to Settings > OAuth Providers and add a new provider:

Client ID: from Linear app
Client Secret: from Linear app
Authorization URL: https://linear.app/oauth/authorize
Token URL: https://api.linear.app/oauth/token
Provider ID: Unique string, for example: linear

Apply the changes

Add the following to your langsmith_config.yaml and deploy:

fleet:
  oauth:
    providerOrgId: "<your-org-id>"
    linearOAuthProvider: "<provider-id>"

helm upgrade -i langsmith langchain/langsmith --values langsmith_config.yaml --version <version> -n <namespace> --wait --debug

LinkedIn OAuth provider

To enable LinkedIn OAuth for Fleet, create a LinkedIn OAuth app and configure it with the required credentials.

Create a LinkedIn OAuth app

Go to linkedin.com/developers/apps and create a new app.

Add redirect URI

In your app settings, go to the Auth tab. Add the following redirect URI, replacing <hostname> with your LangSmith hostname and <provider-id> with your provider ID:

https://<hostname>/host-oauth-callback/<provider-id>

Copy credentials

Copy the Client ID and Client Secret from the Auth tab.

Configure OAuth provider in LangSmith

In LangSmith, go to Settings > OAuth Providers and add a new provider:

Client ID: from LinkedIn app
Client Secret: from LinkedIn app
Authorization URL: https://www.linkedin.com/oauth/v2/authorization
Token URL: https://www.linkedin.com/oauth/v2/accessToken
Provider ID: Unique string, for example: linkedin

Apply the changes

Add the following to your langsmith_config.yaml and deploy:

fleet:
  oauth:
    providerOrgId: "<your-org-id>"
    linkedinOAuthProvider: "<provider-id>"

helm upgrade -i langsmith langchain/langsmith --values langsmith_config.yaml --version <version> -n <namespace> --wait --debug

Salesforce OAuth provider

To enable Salesforce OAuth for Fleet, create a Salesforce External Client App, configure its OAuth settings and policies, retrieve its credentials, then configure a Salesforce OAuth provider in LangSmith.

Create an External Client App

In Salesforce Setup, use Quick Find to open External Client App Manager, then click New External Client App.Under Basic Information, set:

External Client App Name: for example, LangSmith Fleet
Contact Email: an admin email address
Distribution State: Local

External Client Apps are the current framework Salesforce uses for OAuth integrations. If New External Client App is unavailable, confirm that app creation is enabled for your org under Setup > External Client App Settings.

Enable OAuth and configure the OAuth settings

Expand API (Enable OAuth Settings) and select Enable OAuth. Then configure:

Callback URL, replacing <hostname> with your LangSmith hostname and <provider-id> with your provider ID:

https://<hostname>/host-oauth-callback/<provider-id>

Selected OAuth Scopes: add Manage user data via APIs (api) and Perform requests at any time (refresh_token, offline_access).
Keep Require Secret for the Web Server Flow selected.
Leave Enable Authorization Code and Credentials Flow and Enable Client Credentials Flow unselected. Fleet uses the standard web server (authorization code) flow.

Click Create.

Set the OAuth policies

Open the app, select the Policies tab, and click Edit:

Refresh Token Policy: select Refresh token is valid until revoked.
Permitted Users: leave All users may self-authorize. If you choose Admin approved users are pre-authorized instead, you must first assign the app to a permission set or profile, or authorization fails.

Click Save.

An External Client App is configured in two places: Settings (the OAuth definition from the previous step) and Policies (this step). Both must be saved.

Copy the credentials

On the Settings tab, under OAuth Settings, select Consumer Key and Secret. The Consumer Key is your Client ID and the Consumer Secret is your Client Secret.

After you create the app, allow up to 30 minutes for it to propagate before the first connection attempt.

Configure OAuth provider in LangSmith

In LangSmith, go to Settings > OAuth Providers, click OAuth Provider, and fill in:

Provider ID: Unique string, for example: salesforce-oauth-provider. Use this same value for salesforceOAuthProvider in the next step.
Display Name: For example, Salesforce
Client ID: Consumer Key from Salesforce
Client Secret: Consumer Secret from Salesforce
Authorization URL: https://<MyDomain>.my.salesforce.com/services/oauth2/authorize
Token URL: https://<MyDomain>.my.salesforce.com/services/oauth2/token

LangSmith recognizes Salesforce automatically from the Token URL, so there is no provider-type or token-auth-method field to set. Leave Enable PKCE off to match the web server flow configured above.

Replace <MyDomain> with your org’s My Domain, found under Setup > My Domain. For a sandbox, use https://<MyDomain>--<SandboxName>.sandbox.my.salesforce.com/services/oauth2/authorize and the matching token URL.

Apply the changes

Add the following to your langsmith_config.yaml and deploy:

fleet:
  oauth:
    providerOrgId: "<your-langsmith-org-id>"
    salesforceOAuthProvider: "<provider-id>"

helm upgrade -i langsmith langchain/langsmith --values langsmith_config.yaml --version <version> -n <namespace> --wait --debug

If sign-in fails: confirm the Callback URL in Salesforce exactly matches https://<hostname>/host-oauth-callback/<provider-id> (HTTPS, no trailing slash); if you selected Admin approved users are pre-authorized, assign the app via a permission set; and if your org enforces login IP ranges, allowlist your Fleet server’s egress IPs on the user’s profile or set IP Relaxation to Relax IP restrictions in the app’s policies.

Slack OAuth provider

One Slack OAuth provider powers both Slack tools and the Slack apps you add to individual agents, so Slack setup lives with the rest of the Slack integration.For the full walkthrough, see Set up Slack on Self-hosted. It covers creating the Slack app, adding bot scopes, registering the provider, setting the redirect URI, and configuring Helm values.

(Optional) Enable GitHub App for Fleet

Fleet integrates with GitHub through a dedicated GitHub App (not an OAuth app). The GitHub App provides repository access for Fleet’s GitHub tools and supports the user authorization flow required for private repository access. Setup involves creating a GitHub App, gathering its credentials, storing them as Kubernetes secrets, and referencing them from your langsmith_config.yaml.

Create a GitHub App

Go to GitHub Settings > Developer settings > GitHub Apps and click New GitHub App.

You can create the app under a personal account or an organization. If multiple people will manage the integration, an organization-owned app is recommended.

Fill in basic details

GitHub App name: Any unique name, for example acme-langsmith-fleet. Make a note of the slug GitHub generates (the lowercased, hyphenated form of the name), as this is the value you’ll use for FLEET_GITHUB_APP_SLUG.
Homepage URL: Your LangSmith hostname, for example https://langsmith.acme.com.
Deselect Active under Webhook for now. You’ll enable it in a later step after generating a webhook secret.

Set callback URLs

Under Identifying and authorizing users, add the following Callback URL, replacing <hostname> with your LangSmith hostname:

https://<hostname>/v1/platform/fleet/providers/github-app/auth/callback

Select Redirect on update.Under Post installation, add the following Setup URL:

https://<hostname>/v1/platform/fleet/providers/github-app/callback

Select Redirect on update.

Set webhook URL and generate a webhook secret

Generate a random webhook secret:

python3 -c "import secrets; print(secrets.token_urlsafe(48))"

Under Webhook:

Select Active.

Set the Webhook URL to:

https://<hostname>/v1/platform/fleet/providers/github-app/webhooks

Paste the generated value into Webhook secret. Save it, as you’ll need the same value when creating the Kubernetes secret in a later step.

Set repository permissions

Under Permissions > Repository permissions, grant the following:

Contents: Read and write
Issues: Read and write
Pull requests: Read and write
Metadata: Read-only (automatically selected)

Under Permissions > Account permissions, grant Email addresses: Read-only.

These are the minimum permissions required for Fleet’s built-in GitHub tools (issue management, pull request creation, repository content access). Adjust if you need additional tool capabilities.

Choose install visibility

Under Where can this GitHub App be installed?, select the option that matches your distribution needs. For most self-hosted deployments, Only on this account is correct.

Create the app

Click Create GitHub App. On the app settings page, note the following values:

Value	Where to find it	Environment variable
App ID	Numeric, at the top of the page	`FLEET_GITHUB_APP_ID`
Public link	For example, `https://github.com/apps/acme-langsmith-fleet`	`FLEET_GITHUB_APP_PUBLIC_LINK`
App slug	Last path segment of the public link	`FLEET_GITHUB_APP_SLUG`
Client ID	Under About	`FLEET_GITHUB_APP_CLIENT_ID`

Generate a client secret

Under Client secrets, click Generate a new client secret and copy the value. This is FLEET_GITHUB_APP_CLIENT_SECRET. GitHub only shows it once.

Generate a private key

Scroll to Private keys and click Generate a private key. GitHub downloads a .pem file. Keep this file secure, as it grants full access to the GitHub App. The PEM contents are FLEET_GITHUB_APP_PRIVATE_KEY.

Generate a state JWT secret

LangSmith signs short-lived OAuth state tokens with an HMAC key. Generate one:

python3 -c "import secrets; print(secrets.token_urlsafe(48))"

This is FLEET_GITHUB_APP_STATE_JWT_SECRET.

Create a Kubernetes secret

Store the sensitive values in a Kubernetes secret:

kubectl create secret generic fleet-github-app \
  --namespace <your-langsmith-namespace> \
  --from-literal=client_secret="<client-secret>" \
  --from-literal=webhook_secret="<webhook-secret>" \
  --from-literal=state_jwt_secret="<state-jwt-secret>" \
  --from-file=private_key=/path/to/fleet-app.private-key.pem

For production deployments, manage this secret through your existing secrets workflow (for example, Sealed Secrets or External Secrets Operator). See Use an existing secret for more.

Add the configuration to your langsmith_config.yaml

Add the following, replacing the placeholder values with the non-sensitive values gathered above:

commonEnv:
  - name: FLEET_GITHUB_APP_ID
    value: "<app-id>"
  - name: FLEET_GITHUB_APP_SLUG
    value: "<app-slug>"
  - name: FLEET_GITHUB_APP_PUBLIC_LINK
    value: "https://github.com/apps/<app-slug>"
  - name: FLEET_GITHUB_APP_CLIENT_ID
    value: "<client-id>"
  - name: FLEET_GITHUB_APP_CLIENT_SECRET
    valueFrom:
      secretKeyRef:
        name: fleet-github-app
        key: client_secret
  - name: FLEET_GITHUB_APP_PRIVATE_KEY
    valueFrom:
      secretKeyRef:
        name: fleet-github-app
        key: private_key
  - name: FLEET_GITHUB_APP_WEBHOOK_SECRET
    valueFrom:
      secretKeyRef:
        name: fleet-github-app
        key: webhook_secret
  - name: FLEET_GITHUB_APP_STATE_JWT_SECRET
    valueFrom:
      secretKeyRef:
        name: fleet-github-app
        key: state_jwt_secret

fleetToolServer:
  deployment:
    extraEnv:
      - name: FLEET_GITHUB_APP_ENABLED
        value: "true"

FLEET_GITHUB_APP_ENABLED must be set on the tool server so the GitHub tools are registered. The remaining FLEET_GITHUB_APP_* variables are consumed by the platform backend and live under commonEnv.

Deploy and install the app on repositories

Run the following command to apply the changes:

helm upgrade -i langsmith langchain/langsmith --values langsmith_config.yaml --version <version> -n <namespace> --wait --debug

Once pods are healthy:

In LangSmith, open a Fleet agent and go to the GitHub integration in the agent editor.
Click Connect GitHub to install the app on the repositories Fleet should access.
For private repositories, you must explicitly select each repository during installation.

Each user must also authorize the GitHub App against their own GitHub account using the re-auth flow in LangSmith. This allows Fleet to resolve per-user tokens for tools that act on behalf of a user.

Disable features

To disable any combination of Fleet, Insights, and Chat, set the corresponding flags to false in your langsmith_config.yaml:

fleet:
  enabled: false

insights:
  enabled: false

polly:
  enabled: false

Enable Sandboxes

Self-hosted Sandboxes require LangSmith Helm chart 0.16.0 or later.

Sandboxes are disabled by default. After installation, see LangSmith Sandboxes for user workflows in the LangSmith UI and APIs.

Supported platforms

Self-hosted Sandboxes are supported on:

Amazon Elastic Kubernetes Service (EKS)
Google Kubernetes Engine (GKE)

Azure Kubernetes Service (AKS) is supported by the base LangSmith chart, but self-hosted Sandboxes are not supported on AKS.

Components

Enabling Sandboxes provisions the following resources:

Sandbox runtime pods that run sandbox workloads on KVM-capable nodes.
The JuiceFS CSI driver and a JuiceFS-backed volume for sandbox files and snapshots.
A JuiceFS metadata store backed by Redis and object storage backed by S3 or GCS.
Optional wildcard ingress for services exposed from inside Sandboxes.

Prerequisites

Install the base LangSmith platform

Install LangSmith on Kubernetes before enabling Sandboxes. See Self-host LangSmith on Kubernetes.Sandboxes run in the same Kubernetes cluster and namespace as the LangSmith release.

Add KVM-capable nodes

Your cluster must include dedicated nodes that can run nested workloads with Linux KVM available at /dev/kvm.These can be bare-metal machines or supported cloud instances with nested virtualization enabled. On AWS and GCP, use x86_64 Linux instances that expose /dev/kvm to the sandbox runtime.

On EKS, the VPC CNI addon must be v1.21 or later. v1.20.0 crashes on 8th-generation Intel instances (for example m8i): aws-node enters CrashLoopBackOff, the node reports cni plugin not initialized, and the managed node group eventually fails with NodeCreationFailure: Unhealthy nodes in the kubernetes cluster.

The default Helm scheduling values expect these nodes to have the following label and taint:

label:
  sandbox.langsmith.com/host: "true"
taint:
  key: sandbox.langsmith.com/host
  value: "true"
  effect: NoSchedule

If your nodes use different labels or taints, override sandboxes.sandboxHost.deployment.nodeSelector and sandboxes.sandboxHost.deployment.tolerations.

Configure JuiceFS storage

Sandboxes require JuiceFS-backed shared storage. You must provide:

A Redis-compatible metadata store.
An object storage bucket or bucket root.
A JuiceFS CSI configuration Secret, or enough Helm values for the chart to create one.

Enabling Sandboxes installs the JuiceFS CSI driver. The CSI driver includes cluster-scoped Kubernetes resources. Only one sandbox-enabled LangSmith release should manage the JuiceFS CSI driver in a cluster unless you have verified resource ownership.

Supported object storage backends:

Platform	`sandboxes.juicefs.storage`	`sandboxes.juicefs.bucket` format
AWS	`s3`	Region-explicit HTTPS S3 endpoint, such as `https://bucket-name.s3.us-west-2.amazonaws.com`
GCP	`gs`	GCS URL, such as `gs://bucket-name`

Do not use object-store subpaths in sandboxes.juicefs.name. Use a flat name, such as sandbox-juicefs. JuiceFS stores objects under that name inside the configured bucket.

For the Redis metadata store, we recommend setting maxmemory-policy to noeviction. This avoids evicting JuiceFS metadata under memory pressure. Monitor Redis capacity and scale it before it reaches memory limits.With noeviction, Redis writes can fail when the instance reaches max memory, so keep enough memory headroom for sandbox metadata growth.

Configure sandbox secrets

Sandboxes need additional secret material for service-to-service authentication and callback signing.

Using Kubernetes secrets (recommended)
Using inline values

If you use config.existingSecretName, add the sandbox keys to the same LangSmith app Secret. Do not set the secret values directly in Helm.

stringData:
  sandbox_callback_signing_jwk: '<ed25519-private-jwk>'
  # Optional, only during service-auth secret rotation:

If the Helm chart manages your LangSmith app Secret, set the sandbox secret values directly in your config file. Avoid committing this file to version control.

config:
  sandboxes:
    callbackSigningJwk: '<ed25519-private-jwk>'

The callback signing value must be an Ed25519 private JWK. Keep it stable across upgrades.

Choose a proxy CA mode

The chart supports two proxy CA modes:

Mode	Use when
`generatedSecret`	You want Helm to create a self-signed CA Secret. This is the default.
`existingSecret`	You manage the CA Secret outside the LangSmith chart. The Secret can be created manually, by cert-manager, or by another external process.

In GitOps workflows that render manifests without live cluster access, prefer existingSecret. The generatedSecret mode uses Helm’s live lookup behavior to reuse the generated Secret on upgrades; pure render workflows cannot read the live Secret and may produce new cert material on each render.

Enable with Helm

Add the following values to your langsmith_config.yaml, along with the sandbox secret values described in the Prerequisites. Replace placeholders with your deployment-specific values.

images:
  sandboxHostImage:
    tag: "<same-release-tag-as-your-langsmith-images>"

sandboxes:
  enabled: true
  juicefs:
    name: "sandbox-juicefs"
    storage: "s3"
    bucket: "https://bucket-name.s3.us-west-2.amazonaws.com"
    redis:
      metaURL: "redis://redis-host:6379/1"
  proxyCa:
    mode: "generatedSecret"

If you create the JuiceFS CSI config Secret yourself, set sandboxes.juicefs.csi.existingSecretName and omit sandboxes.juicefs.name, storage, bucket, and redis.metaURL from the Helm values:

sandboxes:
  enabled: true
  juicefs:
    csi:
      existingSecretName: "juicefs-csi-config"

The existing Secret must be in the LangSmith release namespace and contain these keys:

stringData:
  name: "sandbox-juicefs"
  metaurl: "redis://redis-host:6379/1"
  storage: "s3"
  bucket: "https://bucket-name.s3.us-west-2.amazonaws.com"

Apply the updated chart:

helm upgrade -i langsmith langchain/langsmith \
  --values langsmith_config.yaml \
  --version <version> \
  --namespace <namespace> \
  --wait

Enable with Terraform

The LangSmith Terraform modules can provision the required AWS and GCP infrastructure and generate the corresponding Helm values.

AWS

In modules/aws/infra/terraform.tfvars, enable Sandboxes and configure the sandbox node capacity:

enable_sandboxes = true
redis_source     = "external"

sandbox_juicefs_redis_instance_type             = "cache.m6g.large"
sandbox_juicefs_redis_snapshot_retention_limit  = 7

sandbox_host_node_count               = 1
sandbox_host_instance_types           = ["m5d.metal"]
sandbox_host_configure_instance_store = true

sandbox_host_image_tag = "<same-release-tag-as-your-langsmith-images>"

AWS Sandboxes require redis_source = "external". The Terraform module:

Creates a dedicated ElastiCache Redis instance for JuiceFS sandbox metadata.
Configures that dedicated instance with the recommended noeviction policy.
Reuses the LangSmith S3 bucket for sandbox object storage.
Creates the JuiceFS CSI config Secret.
Adds the expected node label and taint.

The AWS setup script generates the sandbox service-auth secret, callback signing JWK, and dedicated JuiceFS Redis auth token through the normal SSM-backed setup flow. Run the infra setup script before applying Terraform if those values do not exist yet. If you deploy the Helm release with the Terraform app module, set the sandbox app values in modules/aws/app/terraform.tfvars as well:

enable_sandboxes      = true
chart_version          = "~0.16.0"
sandbox_host_image_tag = "<same-release-tag-as-your-langsmith-images>"

When enable_sandboxes = true, the Terraform app module requires an explicit LangSmith Helm chart version 0.16.0 or later and a sandbox runtime image tag. Run the normal AWS flow:

make apply
make init-values
CHART_VERSION="~0.16.0" make deploy

GCP

In modules/gcp/infra/terraform.tfvars, enable Sandboxes and configure a Standard GKE node pool:

enable_sandboxes = true
redis_source     = "external"

gke_use_autopilot     = false
enable_gcp_iam_module = true

sandbox_juicefs_redis_memory_size       = 5
sandbox_juicefs_redis_high_availability = true

sandbox_host_node_count     = 1
sandbox_host_min_node_count = 1
sandbox_host_max_node_count = 5
sandbox_host_machine_type   = "n2-standard-8"

sandbox_host_image_tag = "<same-release-tag-as-your-langsmith-images>"

GCP Sandboxes require redis_source = "external". The Terraform module:

Creates a dedicated Memorystore Redis instance for JuiceFS sandbox metadata.
Configures that dedicated instance with the recommended noeviction policy.
Reuses the LangSmith GCS bucket for sandbox object storage.
Creates the JuiceFS CSI config Secret.
Adds the expected node label and taint.

The GCP setup script generates the sandbox service-auth secret and callback signing JWK through the normal Secret Manager setup flow. Run the infra setup script before applying Terraform if those values do not exist yet. If you deploy the Helm release with the Terraform app module, set the sandbox app values in modules/gcp/app/terraform.tfvars as well:

enable_sandboxes      = true
chart_version          = "~0.16.0"
sandbox_host_image_tag = "<same-release-tag-as-your-langsmith-images>"

When enable_sandboxes = true, the Terraform app module requires an explicit LangSmith Helm chart version 0.16.0 or later and a sandbox runtime image tag. Run the normal GCP flow:

make apply
make init-values
CHART_VERSION="~0.16.0" make deploy

Optional: enable service URLs

Set sandboxes.serviceUrlBaseUrl when users need browser or programmatic access to HTTP services running inside Sandboxes.

sandboxes:
  serviceUrlBaseUrl: "https://sandbox-services.example.com"

This requires wildcard DNS and TLS for *.sandbox-services.example.com. When ingress.enabled is true, the chart also adds a wildcard ingress rule that routes these service URLs to the LangSmith platform backend.

Verify the installation

After the upgrade completes, verify that the sandbox runtime pods and JuiceFS volumes are ready:

kubectl rollout status deployment/sandbox-host -n <namespace>
kubectl get pods,pvc -n <namespace>

Then run a sandbox smoke test:

Create a sandbox from a public image, such as a Python image.
Start a Python HTTP server inside the sandbox.
Snapshot the sandbox with memory enabled.
Create a new sandbox from the snapshot.
Verify that the HTTP server is still running in the restored sandbox.

Upgrade notes

Sandbox runtime image changes roll out through the sandbox-host Kubernetes Deployment. The chart uses a no-surge rolling update strategy by default, so hosts are replaced one at a time. During a normal Helm upgrade, a terminating host stops accepting new Sandboxes, attempts to save each running Sandbox’s VM memory to JuiceFS, and then stops those VMs before the pod exits. This shutdown is bounded by the sandbox-host pod termination grace period, which defaults to 300 seconds. This is not live migration: Sandboxes on that host are interrupted during the restart. Sandboxes are not proactively restarted. They start again when a user or API action starts the Sandbox, or when a request path wakes it. LangSmith then places the Sandbox on an available host and restores from the saved memory image if the shutdown capture completed. If the memory image is absent or incomplete, the Sandbox starts from the saved root filesystem.

Enable Engine

Self-hosted Engine requires LangSmith Helm chart 0.16.0 or later and a license that includes the Engine entitlement. Contact your account team to have it added to your order.

Engine watches a tracing project, clusters recurring failures into issues, diagnoses each one, and proposes a fix. Engine is disabled by default. Engine requires Sandboxes and shares a runtime with Insights:

Sandboxes: Every Engine run executes in one. Enable Sandboxes first. The chart refuses to render when engine.enabled is set without them.
Insights: Engine and Insights are served by the same image and share one deployment. Insights is not an Engine prerequisite. On an install that already runs Insights, enabling Engine adds configuration rather than new pods.

Unlike the other features on this page, Engine cannot run entirely inside your cluster. It depends on LangSmith Intelligence, a LangChain-managed zero data retention service, and authenticates with a short-lived license JWT obtained during LangSmith license verification. See Engine on self-hosted for the data flow and retained billing metadata.

Components

Enabling Engine provisions or reuses:

standalone-insights-api-server: serves both the engine and insights graphs.
standalone-insights-queue: background run processing for Engine and Insights.
A dedicated PostgreSQL and Redis instance for the shared deployment, each replaceable with an external instance.
The sandbox components described under Enable Sandboxes.

Engine also adds configuration to platform-backend and ingest-queue, which dispatch and schedule its runs.

Prerequisites

Enable Sandboxes

Complete Enable Sandboxes first, including the KVM-capable node pool and JuiceFS storage.Engine’s sandboxes are owned by a single workspace. By default LangSmith resolves the install’s own workspace, which works when there is exactly one non-personal organization; with more than one it declines rather than guess, and you must set engine.sandboxTenantId.

Prefer a workspace reserved for Engine. Engine’s sandboxes are not billed on the Sandboxes product because Engine meters its own usage in LCUs. They do count against that workspace’s concurrent sandbox, CPU, and memory quotas. A workspace already near its cap can push an Engine run into a quota error, and Engine’s own sandboxes can crowd out interactive ones.Those sandboxes are also listed in that workspace and can be stopped by anyone with access to it. Each one runs agent-generated code. Repository credentials are held by the sandbox auth proxy and are not readable inside the sandbox.

Confirm the license entitlement

Engine is licensed separately, in the same way as Sandboxes. Your license must carry the Engine entitlement. LangSmith validates your license key against https://beacon.langchain.com at startup and periodically thereafter, so the entitlement takes effect without you changing any configuration once it is added to your order.

Allow egress to LangSmith Intelligence

Allow outbound HTTPS from the cluster to the LangSmith Intelligence gateway for your cloud. This is the host in engine.intelligenceBaseUrl below.

Cloud	Gateway host
AWS	`beacon.aws.langchain.com`
GCP	`beacon.langchain.com`

On GCP that is the same host LangSmith already uses for license verification and billing telemetry, so Engine adds a path rather than a new egress destination.

Engine is currently available for self-hosted deployments in AWS US and GCP US. AWS EU and Azure are planned. Check Availability by cloud and region and confirm coverage with your account team before planning a rollout.

Add the gateway as a specific allowlist entry rather than opening general egress. Requests use a short-lived license JWT obtained during LangSmith license verification. Engine’s traffic is separate from the billing and operational telemetry described in Configure egress, even where it shares a host.

Offline (air-gapped) installs cannot run Engine. There is no in-cluster model for it to fall back on.

Verify your hostname is externally reachable

Engine’s sandboxes call your LangSmith install using the langsmith CLI, so config.hostname must be reachable from the sandbox network. The chart rejects localhost and in-cluster *.svc addresses.Serve that hostname through your ingress with TLS, as described in Set up an ingress. Engine does not require you to expose anything beyond the address your own users already reach. Sandbox egress is allowlisted to your LangSmith hostname, github.com, api.github.com, and the Python package registries. Per-run credentials are injected by a proxy outside the sandbox rather than being readable inside it.

Generate the Engine encryption key

Engine uses its own Fernet key to encrypt the run payloads LangSmith passes to it, which carry short-lived credentials. Generate one:

python -c "from cryptography.fernet import Fernet; print(Fernet.generate_key().decode())"

Store it in your predefined Kubernetes Secret as engine_encryption_key rather than in your config file. See Use an existing secret.To rotate the key later, copy the current value to engine_encryption_key_previous and set the new key as engine_encryption_key. The previous key is accepted for decryption only, so runs encrypted just before the swap still complete.

Enable with Helm

Add the following to your langsmith_config.yaml, alongside the Sandboxes values from Enable Sandboxes:

Using Kubernetes secrets (recommended)
Using inline values

Reference your existing Secret by name. The chart reads engine_encryption_key from it automatically.

config:
  existingSecretName: "<your-secret-name>"
  # Must be reachable from the sandbox network.
  hostname: "https://langsmith.example.com"

engine:
  enabled: true
  # AWS; on GCP use https://beacon.langchain.com/intelligence
  intelligenceBaseUrl: "https://beacon.aws.langchain.com/intelligence"

sandboxes:
  enabled: true

Set the encryption key directly in your config file.

This puts a live credential in your config file. Do not commit it to version control; prefer the Kubernetes Secret above.

config:
  hostname: "https://langsmith.example.com"

engine:
  enabled: true
  # AWS; on GCP use https://beacon.langchain.com/intelligence
  intelligenceBaseUrl: "https://beacon.aws.langchain.com/intelligence"
  encryptionKey: "<engine-encryption-key>"

sandboxes:
  enabled: true

Engine runs on langsmith-insights-engine, the combined image serving both the engine and insights graphs. The chart uses it by default, so a new install needs no image configuration. If you are upgrading an install whose values pin images.engineInsightsAgentImage.repository to the retired langsmith-clio image, remove or update that pin. langsmith-clio serves Insights only, and the chart rejects it.

If your install has more than one non-personal organization, also set the workspace that owns Engine’s sandboxes:

engine:
  sandboxTenantId: "<workspace-id>"

Apply the updated chart:

helm upgrade -i langsmith langchain/langsmith \
  --values langsmith_config.yaml \
  --version <version> \
  --namespace <namespace> \
  --wait

The chart validates the Engine configuration at render time and fails with a message naming the missing value, so helm template catches a misconfiguration before it reaches your cluster.

Verify the installation

Confirm the shared Engine and Insights deployment is running:

kubectl get pods -n <namespace> | grep standalone-insights

Both the API server and queue pods should be Running. Then confirm platform-backend is healthy, since it dispatches Engine runs:

kubectl rollout status deployment/langsmith-platform-backend -n <namespace>

If Engine does not appear in the LangSmith UI after this, the most common causes are a license without the Engine entitlement and the organization-level toggle described below. After completing the in-product setup, start an Engine analysis and confirm that results appear for the tracing project. This verifies the complete path through Engine, Sandboxes, and LangSmith Intelligence. Running pods alone does not verify that path.

Turn on Engine in LangSmith

Enabling Engine in Helm makes the feature available; it does not start any scans. Two in-product steps remain, both covered in Find and fix issues:

An Organization Admin turns Engine on for the organization under Settings > Engine enablement.
Any user sets Engine up for a tracing project from the project’s Engine tab.

Connecting a GitHub repository is optional and improves Engine’s diagnosis and fixes. Without one, Engine still detects and diagnoses issues and proposes prompt fixes, but it cannot read your source code or open pull requests. Repository connection depends on a GitHub App registered against host-backend, which the chart does not yet expose as Helm values. Contact technical support through the Support Portal to set it up.

Disable Engine

Set engine.enabled to false and re-apply:

engine:
  enabled: false

Engine stops dispatching runs. Existing issues remain in the database and reappear if you re-enable it. Because Insights shares the same deployment, the standalone-insights pods keep running when insights.enabled is true.

Optional configuration

Configure additional data planes

Not recommended; deprecation planned. Configuring additional data planes through the control plane is not a recommended approach and will be deprecated in a future release. Instead, deploy standalone Agent Servers and configure them to trace to your self-hosted LangSmith instance.

In addition to the data plane created above, you can create more data planes in different Kubernetes clusters or in the same cluster under a different namespace. There are different ways to achieve this, so implement the solution that works best for your use case.

Prerequisites

Review cluster organization

Read through the cluster organization guide in the hybrid (legacy) documentation to understand how to organize this for your use case.

Verify hybrid prerequisites

Verify the prerequisites in the hybrid section for the new cluster. In step 5 of the prerequisites, configure egress to your self-hosted LangSmith instance instead of https://api.host.langchain.com and https://api.smith.langchain.com.

Enable the feature in Postgres

Run the following against your LangSmith Postgres instance to enable this feature. Note the workspace ID for later steps.

update organizations set config = config || '{"enable_lgp_listeners_page": true}' where id = '<org id here>';
update tenants set config = config || '{"langgraph_remote_reconciler_enabled": true}' where id = '<workspace id here>';

Deploy to a different cluster

Follow the hybrid setup guide

Follow steps 2 to 6 in the hybrid setup guide. Set config.langsmithWorkspaceId to the workspace ID from the previous step.

(Optional) Add more data planes to the same cluster

To add more than one data plane to the same cluster, follow the instructions for configuring additional data planes in the same cluster.

Deploy to a different namespace in the same cluster

Update your config

In your langsmith_config.yaml, make the following modifications:

Set operator.watchNamespaces to the current namespace your self-hosted LangSmith instance is running in. This prevents conflicts with the operator added by the new data plane.
Use the Gateway API or an Istio Gateway. Adjust your langsmith_config.yaml accordingly.

Apply the changes

helm upgrade -i langsmith langchain/langsmith --values langsmith_config.yaml --version <version> -n <namespace> --wait --debug

Follow the hybrid setup guide

Follow steps 2 to 6 in the hybrid setup guide. Set config.langsmithWorkspaceId to the workspace ID from the previous step. Set config.watchNamespaces to a different namespace than the one used by the existing data plane.

(Optional) Configure log access

Configure access for the control plane to read Agent Server deployment logs from the new namespace. See Read Agent Server logs from other namespaces.

Configure authentication for private registries

If your Agent Server deployments will use images from private container registries (for example, AWS ECR, Azure ACR, or GCP Artifact Registry), configure image pull secrets. This configuration applies to all deployments automatically, allowing them to authenticate with your private registry.

Create a Kubernetes image pull secret

kubectl create secret docker-registry langsmith-registry-secret \
    --docker-server=myregistry.com \
    --docker-username=your-username \
    --docker-password=your-password \
    --docker-email=your-email@example.com \
    -n langsmith

Replace the values with your registry credentials:

myregistry.com: Your registry URL
your-username: Your registry username
your-password: Your registry password or access token
langsmith: The Kubernetes namespace where LangSmith is installed

Configure the deployment template in your langsmith_config.yaml

To enable agent server deployments to use the private registry secret, add imagePullSecrets to the operator’s deployment template:

operator:
  templates:
    deployment: |
      apiVersion: apps/v1
      kind: Deployment
      metadata:
        name: ${name}
        namespace: ${namespace}
      spec:
        replicas: ${replicas}
        revisionHistoryLimit: 10
        selector:
          matchLabels:
            app: ${name}
        template:
          metadata:
            labels:
              app: ${name}
          spec:
            enableServiceLinks: false
            imagePullSecrets:
            - name: langsmith-registry-secret
            containers:
            - name: api-server
              image: ${image}
              ports:
              - name: api-server
                containerPort: 8000
                protocol: TCP
              livenessProbe:
                httpGet:
                  path: /ok
                  port: 8000
                periodSeconds: 15
                timeoutSeconds: 5
                failureThreshold: 6
              readinessProbe:
                httpGet:
                  path: /ok
                  port: 8000
                periodSeconds: 15
                timeoutSeconds: 5
                failureThreshold: 6

Apply the changes

helm upgrade -i langsmith langchain/langsmith --values langsmith_config.yaml --version <version> -n <namespace> --wait --debug

All user deployments created through the LangSmith UI will inherit these registry credentials.

For registry-specific authentication methods, refer to the Kubernetes documentation on pulling images from private registries.

Read Agent Server logs from other namespaces

Retrieving server logs is not supported for self-hosted deployments where the control plane (host-backend) and data plane (listener) are deployed in different Kubernetes clusters.

For deployments where the control plane and data plane are in the same cluster, ensure the control plane Kubernetes deployment (host-backend) has permission to get, list, and watch Kubernetes deployments, pods, replicasets, and logs from the namespace where the Agent Server deployment exists. There are different ways to achieve this. The following example uses Kubernetes RBAC, but use the approach that best fits your use case:

Create a Role with the required permissions

Create a Role in the Agent Server namespace. Replace <data_plane_namespace>:

kubectl apply -n <data_plane_namespace> -f - <<EOF
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: read-agent-server-logs-role
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get","list","watch"]
- apiGroups: [""]
  resources: ["pods/log"]
  verbs: ["get","watch"]
- apiGroups: ["apps"]
  resources: ["deployments"]
  verbs: ["get","list","watch"]
- apiGroups: ["apps"]
  resources: ["replicasets"]
  verbs: ["get","list","watch"]
EOF

Get the control plane ServiceAccount

Replace <control_plane_namespace>:

kubectl get serviceaccounts -n <control_plane_namespace> | grep host-backend

Bind the Role to the control plane ServiceAccount

Replace <data_plane_namespace>, <control_plane_namespace>, and <control_plane_service_account>:

kubectl apply -n <data_plane_namespace> -f - <<EOF
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-agent-server-logs-role-binding
subjects:
- kind: ServiceAccount
  name: <control_plane_service_account>
  namespace: <control_plane_namespace>
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: read-agent-server-logs-role
EOF

In this example, the Role and RoleBinding are defined in the same Kubernetes namespace as the Agent Server deployment. You can assign any name to the Role and RoleBinding and customize them as needed.

Next steps

Once LangSmith Deployment is enabled, see Deploy with control plane to build and deploy your applications via the LangSmith UI.

Connect these docs to Claude, VSCode, and more via MCP for real-time answers.

Edit this page on GitHub or file an issue.

​Prerequisites

​Enable LangSmith Deployment

​Components

​Enable the feature

​Enable Fleet, Insights, and Chat

​Components

​Generate encryption keys

​Enable features

​(Optional) Enable OAuth tools and triggers for Fleet

​Available providers

​General configuration

​Provider setup guides

​(Optional) Enable GitHub App for Fleet

​Disable features

​Enable Sandboxes

​Supported platforms

​Components

​Prerequisites

​Enable with Helm

​Enable with Terraform

​AWS

​GCP

​Optional: enable service URLs

​Verify the installation

​Upgrade notes

​Enable Engine

​Components

​Prerequisites

​Enable with Helm

​Verify the installation

​Turn on Engine in LangSmith

​Disable Engine

​Optional configuration

​Configure additional data planes

​Prerequisites

​Deploy to a different cluster

​Deploy to a different namespace in the same cluster

​Configure authentication for private registries

​Read Agent Server logs from other namespaces

​Next steps

Prerequisites

Enable LangSmith Deployment

Components

Enable the feature

Enable Fleet, Insights, and Chat

Components

Generate encryption keys

Enable features

(Optional) Enable OAuth tools and triggers for Fleet

Available providers

General configuration

Provider setup guides

(Optional) Enable GitHub App for Fleet

Disable features

Enable Sandboxes

Supported platforms

Components

Prerequisites

Enable with Helm

Enable with Terraform

AWS

GCP

Optional: enable service URLs

Verify the installation

Upgrade notes

Enable Engine

Components

Prerequisites

Enable with Helm

Verify the installation

Turn on Engine in LangSmith

Disable Engine

Optional configuration

Configure additional data planes

Prerequisites

Deploy to a different cluster

Deploy to a different namespace in the same cluster

Configure authentication for private registries

Read Agent Server logs from other namespaces

Next steps