Mirror images for your LangSmith installation

By default, LangSmith will pull images from our public Docker registry. However, if you are running LangSmith in an environment that does not have internet access, or if you would like to use a private Docker registry, you can mirror the images to your own registry and then configure your LangSmith installation to use those images.

Requirements

Authenticated access to a Docker registry that your Kubernetes cluster/machine has access to.
Docker installed on your local machine or a machine that has access to the Docker registry.
A Kubernetes cluster where you can run LangSmith.

Mirroring the images

Fewer images from LangSmith 0.16.21 (chart 0.16.0-rc.17) onward. The platform backend, playground, host backend, and the Fleet tool and trigger servers now all run from the single langsmith-backend image, so you no longer need to mirror langsmith-go-backend, langsmith-playground, hosted-langserve-backend, agent-builder-tool-server, or agent-builder-trigger-server (or their -fips variants). The corresponding values.yaml keys: platformBackendImage, playgroundImage, hostBackendImage, fleetToolServerImage, and fleetTriggerServerImage, have been removed from the chart; any values you still set for them are ignored.If you are installing an earlier version, keep mirroring those images and setting those keys as before.

For your convenience, we have provided a script that will mirror the images for you. You can find the script in the LangSmith Helm Chart repository To use the script, you will need to run the script with the following command specifying your registry and platform:

bash mirror_langsmith_images.sh <your-registry> [<platform>]

Where <your-registry> is the URL of your Docker registry (e.g. myregistry.com) and <platform> is the platform you are using (e.g. linux/amd64, linux/arm64, etc.). If you do not specify a platform, it will default to linux/amd64. For example, if your registry is myregistry.com, your platform is linux/arm64, and you want to use the latest version of the images, you would run:

bash mirror_langsmith_images.sh --registry myregistry --platform linux/arm64 --version 0.10.66

Note that this script will assume that you have Docker installed and that you are authenticated to your registry. It will also push the images to the specified registry with the same repository/tag as the original images. Alternatively, you can pull, mirror, and push the images manually. The images that you will need to mirror are found in the values.yaml file of the LangSmith Helm Chart. These can be found here: LangSmith Helm Chart values.yaml Here is an example of how to mirror the images using Docker:

# Pull the images from the public registry
docker pull langchain/langsmith-backend:latest
docker tag langchain/langsmith-backend:latest <your-registry>/langsmith-backend:latest
docker push <your-registry>/langsmith-backend:latest

You will need to repeat this for each image that you want to mirror.

Configuration

Once the images are mirrored, you will need to configure your LangSmith installation to use the mirrored images. You can do this by modifying the values.yaml file for your LangSmith Helm Chart installation. Replace tag with the LangSmith version you want to deploy. The following example uses 0.16.21.

images:
  imagePullSecrets: [] # Add your image pull secrets here if needed
  registry: "" # Set this to your registry URL if you mirrored all images to the same registry using our script. Then you can remove the repository prefix from the images below.
  aceBackendImage:
    repository: "(your-registry)/langchain/langsmith-ace-backend"
    pullPolicy: IfNotPresent
    tag: "0.16.21"
  backendImage:
    repository: "(your-registry)/langchain/langsmith-backend"
    pullPolicy: IfNotPresent
    tag: "0.16.21"
  frontendImage:
    repository: "(your-registry)/langchain/langsmith-frontend"
    pullPolicy: IfNotPresent
    tag: "0.16.21"
  operatorImage:
    repository: "(your-registry)/langchain/langgraph-operator"
    pullPolicy: IfNotPresent
    tag: "6cc83a8"
  postgresImage:
    repository: "(your-registry)/postgres"
    pullPolicy: IfNotPresent
    tag: "14.7"
  redisImage:
    repository: "(your-registry)/redis"
    pullPolicy: IfNotPresent
    tag: "7"
  clickhouseImage:
    repository: "(your-registry)/clickhouse/clickhouse-server"
    pullPolicy: Always
    tag: "24.8"

Additional images for Sandboxes

If you enable Sandboxes, also mirror the sandbox runtime image. The sandbox runtime image is published for linux/amd64.

bash mirror_langsmith_images.sh --registry myregistry --platform linux/amd64 --version 0.16.0 --include-sandboxes

Then, configure the sandbox runtime image in your values.yaml:

images:
  sandboxHostImage:
    repository: "(your-registry)/langchain/sandbox-host"
    pullPolicy: IfNotPresent
    tag: "0.16.0"

If your mirrored registry requires authentication, configure images.imagePullSecrets. The sandbox runtime uses the same image pull secrets as the other LangSmith images. The --include-sandboxes flag mirrors the LangSmith-owned sandbox runtime image. If your cluster cannot pull public images at all, also mirror the JuiceFS images used by the sandbox storage driver:

docker.io/juicedata/juicefs-csi-driver:v0.31.4
registry.k8s.io/sig-storage/csi-node-driver-registrar:v2.9.0
docker.io/juicedata/mount:ce-v1.3.1 for JuiceFS mount pods

Then, configure the corresponding image overrides:

images:
  juicefsCSIImage:
    repository: "(your-registry)/juicedata/juicefs-csi-driver"
    tag: "v0.31.4"
  juicefsCSINodeDriverRegistrarImage:
    repository: "(your-registry)/sig-storage/csi-node-driver-registrar"
    tag: "v2.9.0"
  juicefsMountImage:
    repository: "(your-registry)/juicedata/mount"
    tag: "ce-v1.3.1"

The chart does not set images.juicefsMountImage by default. When it is unset, the JuiceFS CSI driver uses the JUICEFS_CE_MOUNT_IMAGE fallback baked into the CSI driver image. For the chart’s current docker.io/juicedata/juicefs-csi-driver:v0.31.4 default, that fallback is juicedata/mount:ce-v1.3.1. In private-registry or air-gapped environments, set both images.juicefsMountImage.repository and images.juicefsMountImage.tag so mount pods pull from your mirrored registry instead of the public default.

Additional images for Fleet and Insights

If you are using Fleet or Insights, the LangGraph operator dynamically creates Redis and PostgreSQL (pgvector) pods for each deployment. These pods use images defined in operator templates that require separate configuration. You must mirror these additional images:

docker.io/redis:7
docker.io/pgvector/pgvector:pg15

Then override the operator templates in your values.yaml to use your mirrored images:

operator:
  templates:
    redis: |
      apiVersion: apps/v1
      kind: Deployment
      metadata:
        name: ${service_name}
        namespace: ${namespace}
      spec:
        replicas: 1
        selector:
          matchLabels:
            app: ${service_name}
        template:
          metadata:
            labels:
              app: ${service_name}
          spec:
            enableServiceLinks: false
            containers:
            - name: redis
              image: (your-registry)/redis:7
              ports:
              - containerPort: 6379
                name: redis
              livenessProbe:
                exec:
                  command:
                  - redis-cli
                  - ping
                initialDelaySeconds: 30
                periodSeconds: 10
              readinessProbe:
                tcpSocket:
                  port: 6379
                initialDelaySeconds: 10
                periodSeconds: 5
    db: |
      apiVersion: apps/v1
      kind: StatefulSet
      metadata:
        name: ${service_name}
      spec:
        serviceName: ${service_name}
        selector:
          matchLabels:
            app: ${service_name}
        persistentVolumeClaimRetentionPolicy:
          whenDeleted: Delete
          whenScaled: Retain
        template:
          metadata:
            labels:
              app: ${service_name}
          spec:
            containers:
            - name: postgres
              image: (your-registry)/pgvector/pgvector:pg15
              ports:
              - containerPort: 5432
              command: ["docker-entrypoint.sh"]
              args:
                - postgres
                - -c
                - max_connections=${max_connections}
              env:
              - name: PGDATA
                value: /var/lib/postgresql/data/pgdata
              volumeMounts:
              - name: postgres-data
                mountPath: /var/lib/postgresql/data
            enableServiceLinks: false
        volumeClaimTemplates:
        - metadata:
            name: postgres-data
          spec:
            accessModes: ["ReadWriteOnce"]
            resources:
              requests:
                storage: "${storage_gi}Gi"

Replace (your-registry) with your registry URL. The template variables (${service_name}, ${namespace}, ${max_connections}, ${storage_gi}) are replaced by the operator at runtime and must be kept as-is. Once configured, you will need to update your LangSmith installation. You can follow our upgrade guide here: Upgrading LangSmith. If your upgrade is successful, your LangSmith instance should now be using the mirrored images from your Docker registry.

Verifying image signatures

Image signatures are available starting with v15 (LangSmith app version 0.15.x and later). Earlier releases on the v14-stable and older channels are not signed and cannot be verified with the steps below.

Stable-channel LangSmith images on docker.io/langchain/* are signed at release time using keyless Sigstore/Cosign from the release workflow. The signing identity is bound to a specific GitHub Actions workflow, run, and commit, so the signature attests not just that the image is authentic but that it was produced by the stable-branch release pipeline running in langchain-ai/langchainplus. You can verify a signature before pulling or mirroring an image, and again after mirroring to confirm the digest you mirrored matches what we signed. Install cosign (installation guide), then verify any tag:

cosign verify \
  --certificate-oidc-issuer https://token.actions.githubusercontent.com \
  --certificate-identity-regexp 'https://github\.com/langchain-ai/langchainplus/\.github/workflows/release_self_hosted_on_version_bump\.yaml@refs/heads/v[0-9]+-stable' \
  docker.io/langchain/langsmith-backend:<tag>

A successful verification confirms:

The cosign claims on the signature are valid.
The certificate chains to the Sigstore root and is logged in the Rekor transparency log.
The signing certificate was issued to the stable-branch release workflow via GitHub Actions OIDC.

The same command works against any of the released images by substituting the repository (langsmith-frontend, langsmith-go-backend, agent-builder-deep-agent, langsmith-clio, langsmith-polly, agent-builder-tool-server, agent-builder-trigger-server, hosted-langserve-backend, langsmith-playground, langsmith-ace-backend, plus their *-fips variants).

Pinning to a specific release

For stricter verification — for example, pinning to a single stable branch or a specific commit — drop the regex and supply the exact certificate identity. Each signature’s certificate also carries the workflow run ID and commit SHA as Subject Alternative Name extensions, so you can constrain to a specific release:

cosign verify \
  --certificate-oidc-issuer https://token.actions.githubusercontent.com \
  --certificate-identity 'https://github.com/langchain-ai/langchainplus/.github/workflows/release_self_hosted_on_version_bump.yaml@refs/heads/v15-stable' \
  docker.io/langchain/langsmith-backend:0.15.9

To inspect the certificate’s claims (workflow run, commit, runner), download the attestation and decode the embedded certificate:

cosign download attestation docker.io/langchain/langsmith-backend:<tag>

Verifying SBOM attestations

Released images also carry signed CycloneDX software bill of materials (SBOM) attestations, one per architecture in the image index. The per-architecture SBOMs are also attached to the multi-architecture index digest, so you can verify against a bare tag directly:

cosign verify-attestation \
  --type cyclonedx \
  --certificate-oidc-issuer https://token.actions.githubusercontent.com \
  --certificate-identity-regexp 'https://github\.com/langchain-ai/langchainplus/\.github/workflows/release_self_hosted_on_version_bump\.yaml@refs/heads/v[0-9]+-stable' \
  docker.io/langchain/langsmith-backend:<tag>

The command returns one verified statement per architecture. A successful verification gives the same guarantees as the image signature: the attestation was produced by the stable-branch release workflow, and its claims are logged in the Rekor transparency log.

Fetching SBOMs

To feed an SBOM into a vulnerability scanner or SBOM management tool, extract the verified CycloneDX document to a file. Because the index carries one statement per architecture, resolve a single architecture’s child digest first so you get one CycloneDX document rather than one per architecture. List the per-architecture digests for a tag:

docker buildx imagetools inspect --raw docker.io/langchain/langsmith-backend:<tag> \
  | jq -r '.manifests[] | select(.platform.os == "linux") | .digest + "  " + .platform.architecture'

Then verify that digest and save the decoded predicate — a standard CycloneDX document listing every package in the image — to a file:

cosign verify-attestation \
  --type cyclonedx \
  --certificate-oidc-issuer https://token.actions.githubusercontent.com \
  --certificate-identity-regexp 'https://github\.com/langchain-ai/langchainplus/\.github/workflows/release_self_hosted_on_version_bump\.yaml@refs/heads/v[0-9]+-stable' \
  docker.io/langchain/langsmith-backend@<digest> \
  | jq -r '.payload' | base64 -d | jq '.predicate' > langsmith-backend.cdx.json

You can pass the resulting langsmith-backend.cdx.json directly to scanners such as Grype (grype sbom:langsmith-backend.cdx.json) or Trivy (trivy sbom langsmith-backend.cdx.json).

Extracting the SBOM through cosign verify-attestation, rather than cosign download attestation, ensures you only ever consume an SBOM whose signature and signing identity have been verified.

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

Edit this page on GitHub or file an issue.

Get started by cloud provider

Deploy with Terraform

Setup guides

Configuration

Connect external services

Platform auth & access control

Self-hosted observability

Hybrid

Scripts

Reference

Mirror images for your LangSmith installation

Requirements

Mirroring the images

Configuration

Additional images for Sandboxes

Additional images for Fleet and Insights

Verifying image signatures

Pinning to a specific release

Verifying SBOM attestations

Fetching SBOMs

​Requirements

​Mirroring the images

​Configuration

​Additional images for Sandboxes

​Additional images for Fleet and Insights

​Verifying image signatures

​Pinning to a specific release

​Verifying SBOM attestations

​Fetching SBOMs

Requirements

Mirroring the images

Configuration

Additional images for Sandboxes

Additional images for Fleet and Insights

Verifying image signatures

Pinning to a specific release

Verifying SBOM attestations

Fetching SBOMs