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.Documentation Index
Fetch the complete documentation index at: https://langchain-5e9cc07a-preview-opensw-1780069467-dc8133d.mintlify.app/llms.txt
Use this file to discover all available pages before exploring further.
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
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:<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:
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:
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 thevalues.yaml file for your LangSmith Helm Chart installation. Replace tag with the version you want to use, e.g. 0.10.66 for the latest version at the time of writing.
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:7docker.io/pgvector/pgvector:pg15
values.yaml to use your mirrored images:
(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.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:
- 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.
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:SPDX SBOM attestations are not yet attached to released images and will land in a future release. This section will be updated once SBOMs are published, including the
cosign verify-attestation --type spdx command to retrieve them.Connect these docs to Claude, VSCode, and more via MCP for real-time answers.

