LangSmith uses Redis to back our queuing/caching operations. By default, LangSmith Self-Hosted will use an internal Redis instance. However, you can configure LangSmith to use an external Redis instance. By configuring an external Redis instance, you can more easily manage backups, scaling, and other operational tasks for your Redis instance.
Requirements
-
A provisioned Redis instance that your LangSmith instance will have network access to. We recommend using a managed Redis service like:
-
Note: We only officially support Redis versions >= 5.
-
We support both Standalone and Redis Cluster. See the appropriate sections for deployment instructions.
-
By default, we recommend an instance with at least 2 vCPUs and 8GB of memory. However, the actual requirements will depend on your tracing workload. We recommend monitoring your Redis instance and scaling up as needed.
Standalone Redis
Connection String
You will need to assemble the connection string for your Redis instance. This connection string should include the following information:
- Host
- Database
- Port
- URL params
This will take the form of:
An example connection string might look like:
Note: If your Standalone Redis requires authentication or TLS, include these directly in the connection URL:
- Use
rediss:// when TLS is enabled on your Redis server.
- Provide the password in the connection string.
For example:
Configuration
With your connection string in hand, you can configure your LangSmith instance to use an external Redis instance. You can do this by modifying the values file for your LangSmith Helm Chart installation or the .env file for your Docker installation.
You can also store the connection URL in an existing Kubernetes Secret and reference it in your Helm values.
Once configured, you should be able to reinstall your LangSmith instance. If everything is configured correctly, your LangSmith instance should now be using your external Redis instance.
Redis Cluster
As of LangSmith helm version 0.12.25, we officially support Redis Cluster.
Host Names
When using Redis Cluster, provide a list of node hostnames and ports. Each node URI must be in the form:
For example:
Do not include a password in these URIs, and do not use rediss here. For Redis Cluster:
- Provide the password separately via
redis.external.cluster.password or through a Secret using passwordSecretKey.
- Enable TLS separately with
redis.external.cluster.tlsEnabled: true.
Configuration
When connecting to an external Redis Cluster, configure the Helm values under redis.external.cluster. You can either:
- Provide node URIs and (optionally) a password directly in
values.yaml.
- Or reference an existing Kubernetes
Secret containing node URIs and password.
If using an existing Secret, it should contain:
TLS with Redis
Use this section to configure TLS for Redis connections. For mounting internal/public CAs so LangSmith trusts your Redis server certificate, see Configure custom TLS certificates.
Server TLS (one-way)
To validate the Redis server certificate:
- Provide a CA bundle using
config.customCa.secretName and config.customCa.secretKey.
- For Standalone Redis, use
rediss:// in the connection URL.
- For Redis Cluster, set
redis.external.cluster.tlsEnabled: true.
Mount a custom CA only when your Redis server uses an internal or private CA. Publicly trusted CAs do not require this configuration.
Mutual TLS with Client Auth (mTLS)
As of LangSmith helm chart version 0.12.28, we support mTLS for Redis clients. For server-side authentication in mTLS, use the Server TLS steps above (custom CA) in addition to the client certificate configuration below.
If your Redis server requires client certificate authentication:
- Provide a Secret with your client certificate and key.
- Reference it via
redis.external.clientCert.secretName and specify the keys with certSecretKey and keySecretKey.
- For Standalone Redis, keep using
rediss:// in the connection URL.
- For Redis Cluster, set
redis.external.cluster.tlsEnabled: true.
Pod security context for certificate volumes
The certificate volumes mounted for mTLS are protected by file access restrictions. To ensure all LangSmith pods can read the certificate files, you must set fsGroup: 1000 in the pod security context.
You can configure this in one of two ways:
Option 1: Use commonPodSecurityContext
Set the fsGroup at the top level to apply it to all pods:
Option 2: Add to individual pod security contexts
If you need more granular control, add the fsGroup to each pod’s security context individually. See the mtls configuration example for a complete reference.