.png&w=640&q=75){kind=small}
Context
This guide provides clear answers to common operational questions when deploying the self-hosted LangSmith and LangGraph Platform on a Kubernetes cluster.
Questions
1) Are there any specific Kubernetes versions recommended for LangSmith and LangGraph?
2) Does LangSmith require stateful components (databases, caches, object storage)? If yes, what are the recommended persistent volume sizes
3) Can LangGraph and LangSmith share the same namespace in Kubernetes, or should they be deployed in isolated namespaces?
4) Does LangSmith require ingress controllers or specific service types (LoadBalancer vs ClusterIP) for access?
5) What are the port and network requirements?
6) What is the recommended strategy for upgrades?
Answers
1) While there are no strict requirements for a generic Kubernetes distribution, the platform is officially validated against specific versions of OpenShift. We recommend using OpenShift 4.14 or newer, which is built on Kubernetes 1.27. Therefore, running on a Kubernetes cluster version 1.27 or higher is the best practice to ensure compatibility and stability. Please refer to our official documentation.
2) Yes, a self-hosted LangSmith deployment is inherently stateful and relies on several core services that require persistent storage to function correctly. The primary stateful components in the architecture are:
* PostgreSQL: The main relational database for storing trace data, datasets, and metadata.
* Redis: Used as a high-performance cache and for managing background job queues.
* ClickHouse: An OLAP database used for analytics and monitoring features.
Each of these components requires a Persistent Volume (PV) to persist its data. For detailed guidance on sizing these volumes based on your expected usage and scale, please refer to the official Self-Hosting at Scale documentation.
3) For a cohesive and correctly configured deployment, both LangSmith and LangGraph Platform should be deployed into the same Kubernetes namespace. This unified approach simplifies service discovery, network policies, and overall management of the platform components, as they are designed to work closely together.
4) Yes, the LangSmith frontend service must be exposed to your users. This is typically achieved in one of two ways: by configuring a Kubernetes Ingress controller or by setting the frontend service type to LoadBalancer.
Using an Ingress controller is the recommended approach, as it provides more flexible routing, TLS termination, and host-based access. Furthermore, properly configuring an Ingress is a prerequisite for deploying the LangGraph Platform, as it allows your deployed LangGraph applications to be served securely under the same Ingress point.
5) The platform's components communicate internally across a set of specific network ports. Key internal ports include:
* PostgreSQL: 5432 TCP
* Redis: 6379 TCP
* ClickHouse: 8123 TCP (HTTP) and 9000 TCP (native)
* LangSmith Backend: 1984 TCP
* LangSmith Frontend: 80/443 (via Ingress/LoadBalancer)
For external connectivity, it is critical to allow egress traffic to https://beacon.langchain.com on port 443. This connection is required for license verification and essential usage reporting.
6) Upgrades for the entire platform should be managed using Helm. The standard procedure is to use the helm upgrade command. To ensure a safe and predictable rollout, it is highly recommended to include the --wait and --debug flags:
helm upgrade <release-name> <chart-name> --wait --debug* The --wait flag ensures that Helm waits until all the Kubernetes resources are in a ready state before marking the release as successful.
* The --debug flag provides verbose output, which is invaluable for troubleshooting if an issue arises during the upgrade.
Importantly, any necessary database migrations are automatically handled as part of the Helm upgrade process, simplifying the maintenance lifecycle.
References
LangSmith Architectural Overview