LangSmith components and Helm charts

What runs in a LangSmith install is determined by which Helm chart you deploy and which optional features you enable, not by the topology. The topology decides where these pieces run (LangChain SaaS, your cloud, on-premises, air-gapped) and which trust boundary sits between them; the component set itself does not change.

Helm charts

Chart	What it deploys	Use when
langsmith	The full platform: the base LangSmith app and trace pipeline, plus optionally LangSmith Deployment (control plane + data plane) and the Fleet / Insights / Chat capability stacks.	Full self-hosted platform.
langgraph-cloud	A standalone Agent Server (the LangGraph runtime) with your own PostgreSQL and Redis. It has no control plane and no managed UI.	Standalone Agent Server: embed the runtime in existing infrastructure, or run a lightweight / air-gapped deployment.
langsmith-auth-proxy	The LLM Auth Proxy egress component. Optional, installed separately.	Centralized LLM credential management and per-workspace egress control.
langgraph-dataplane	A split data plane (operator + listener + agent servers) that pairs with a remote control plane.	Existing hybrid / remote data planes. For new deployments, the recommended path is standalone Agent Servers that trace back to LangSmith.

The langsmith chart (full platform)

The langsmith chart is the complete platform. The base install is always present; LangSmith Deployment and the capability stacks are opt-in features on top of it, all delivered by this one chart. Service names below are from the chart and a live single-cluster install.

Base LangSmith platform (always present)

The app, auth, and the entire trace pipeline. This is what a base install gives you with no optional features enabled.

Service	Role	Notes
frontend	Web UI	The React app (smith.langchain.com or your self-hosted host). Also serves the Studio debugger, which connects out to an Agent Server to step through graph executions.
platform-backend	Platform API	Orgs, workspaces, members, API keys, SSO/SCIM, billing, retention. Issues short-lived tokens for data-plane requests.
backend	Trace ingest + query API	Accepts HTTP multipart trace uploads from the SDK and Agent Servers; serves run, dataset, feedback, and evaluation queries.
ingest-queue	Async trace writer (asynq)	Pulls buffered trace events from Redis and writes them to ClickHouse and blob storage.
queue	Background-job worker	Dataset processing, evaluation runs, exports, retention sweeps.
playground	Prompt playground backend	Executes ad-hoc prompt/model runs from the Playground UI.
ace-backend	Agent/playground execution	Backend that runs the in-app agent and playground experience.

LangSmith Deployment (optional)

Enable it with config.deployment (on chart v0.12 and later; the older langgraphPlatform flag still works but is superseded). This is what lets you deploy and manage Agent Servers through the LangSmith UI: it adds the control plane (CP) services that own deployment state and the data plane (DP) runtime that executes agents. The operator creates one runtime per deployment.

Service	Role	Notes
host-backend	Control plane	Backs the Deployments UI and control-plane APIs (served at /host): manages Agent Server deployments, stores deployment state, issues listener IDs, and routes Studio traffic. The listener polls it over outbound HTTPS; the control plane never connects to the data plane directly.
operator	LangSmith operator	Watches the LangGraphPlatform custom resource definition (CRD; a legacy name) and reconciles per-deployment Agent Server runtimes. The CRD is cluster-scoped, so chart upgrades must be version-locked across all data planes in the cluster.
LangGraphPlatform CRD	Deployment custom resource	One per Agent Server deployment; the operator reconciles each into a runtime.
listener	Data-plane control loop	One per data plane. Pulls deployment changes from host-backend over outbound HTTPS and applies them locally. This is what makes hybrid deployments work: you never have to open an inbound connection from the control plane into your network.
per-deployment Agent Server	Agent runtime	Operator-spawned per deployed graph: an lg-<deployment-id> StatefulSet (the Agent Server), its app Deployment/Service, and a -queue worker pool. Your application code runs here.
per-deployment PostgreSQL	LangGraph state	Assistants, threads, checkpoints, runs, and long-term memory for the deployment. By default the control plane provisions one per deployment in-cluster (suitable for dev and small-scale testing). For production, point deployments at an external PostgreSQL with POSTGRES_URI_CUSTOM; deployments can share one instance, each using its own database.
per-deployment Redis	Worker coordination + streaming	Runs execute on background workers, not in the HTTP request. Redis is the pub/sub channel that streams each run's output back to any open /stream request as it happens, wakes workers when a run is created, and relays cancellations. No run data is stored in Redis. Provisioned in-cluster per deployment by default, or external via REDIS_URI_CUSTOM (deployments can share one instance using separate database numbers); external is preferred for production.

Capability stacks (optional)

Fleet, Insights, and LangSmith Chat are independent features on the base platform; they do not run on LangSmith Deployment. Each is enabled with its own flag and deploys its own api-server and queue, plus a dedicated PostgreSQL and Redis by default (point at external databases via each feature's postgres.external / redis.external).

Feature	Services	Notes
Fleet (fleet.enabled)	api-server, queue, tool-server, trigger-server	No-code agent platform (Agent Builder is now LangSmith Fleet). tool-server runs MCP tools; trigger-server handles webhooks and schedules. fleetToolServer / fleetTriggerServer replaced the agentBuilder* keys as of chart v15. Requires Self-Hosted v0.13+.
Insights (insights.enabled)	api-server, queue	AI analysis of trace usage patterns and failure modes.
LangSmith Chat (polly.enabled)	api-server, queue	In-workspace context-aware chat over projects, traces, threads, prompts, and datasets (formerly Polly).

Managed Deep Agents is a separate hosted runtime (private beta, LangSmith Cloud US only), not part of this chart. A Managed Deep Agent is not a LangSmith Deployment and not a Fleet surface.

The standalone service model above (v0.15+) is the current approach. An earlier model ran Fleet, Insights, and Chat as deployed agents on LangSmith Deployment (lg-* runtimes); you may still see that on older installs.

Backing services

Each stateful dependency can run in-cluster (bundled with the chart as a StatefulSet) for dev and small-scale testing, or be externalized to a managed service, which is preferred for production. This applies to the platform services below as well as the per-deployment PostgreSQL and Redis above.

Service	Purpose	Notes
PostgreSQL	Platform metadata: orgs, workspaces, members, API keys, datasets, prompts. Each capability stack (Fleet / Insights / Chat) also gets its own.	Required. In-cluster (dev) or external (production).
Redis	Trace ingest queue (asynq) and background-job queue.	Required. Sized for trace volume, not just sessions. In-cluster (dev) or external (production).
ClickHouse	Trace and feedback storage.	Required. Use managed ClickHouse for production; in-cluster is for dev and proof-of-concept only.
Object storage (S3 / GCS / Blob)	Trace payloads and large artifacts.	Required. Payloads must not go into ClickHouse.

Whether a dependency runs in-cluster or external is mostly a function of scale; see Configure LangSmith for scale for sizing by read/write pattern. PostgreSQL and Redis are externalized in every production-scale reference configuration. ClickHouse is the most load-sensitive component: give it more CPU and memory as write volume grows, and move to a replicated cluster for high read volume (start with 3 nodes; the scale guide recommends staying under 5, beyond which coordination overhead outweighs the read gains). In-cluster single-instance Postgres, Redis, and ClickHouse are for dev and small-scale testing only. The per-deployment PostgreSQL and Redis default to in-cluster provisioning unless pointed at external instances.

How traces flow

Knowing the trace path matters because it determines where ClickHouse and object storage sit, which is the most important factor in trace residency (where your trace data physically lives):

Agent Server  →  HTTP multipart  →  backend  →  Redis  →  ingest-queue (asynq)  →  ClickHouse + Blob

The Agent Server only emits HTTP requests. Every storage component for traces (the ingest API, the queue, the asynq worker, ClickHouse, and object storage) is part of the base platform. This is why "where the base platform runs" determines "where trace payloads land," not "where the agent runs." In hybrid, agents execute in your cloud but traces flow back over HTTPS to the SaaS platform and land in LangChain's ClickHouse and object storage. In self-hosted, everything stays in your cluster.

Standalone Agent Server (langgraph-cloud)

The lightest option: just the Agent Server runtime, with no control plane and no UI. Clients call the Agent Server API directly. Deployed with the langgraph-cloud chart (or Docker / Docker Compose for development).

Component	Role	Notes
Agent Server	Agent runtime	API plus queue workers. Built from your graph with the LangGraph CLI (langgraph build).
PostgreSQL	Persistence	Assistants, threads, runs, long-term memory, and the background task queue. Set via DATABASE_URI.
Redis	Pub/sub	Streaming of real-time output from background runs. Set via REDIS_URI.
MongoDB (optional)	Checkpointer	Alternative checkpoint store (mongo.enabled, chart v0.2.6+). PostgreSQL is still required for everything else.

Licensing uses LANGGRAPH_CLOUD_LICENSE_KEY: the server performs a one-time license check against beacon.langchain.com at startup (skipped when running air-gapped). Tracing is optional: set LANGSMITH_API_KEY and LANGSMITH_ENDPOINT to send traces to a self-hosted LangSmith instance or to Cloud. With tracing off, no trace data leaves the cluster.

LLM Auth Proxy (langsmith-auth-proxy)

An optional egress component that sits between the data plane and external LLM providers. Centralizes API-key management, applies per-workspace allowlists and rate limits, and produces an auditable record of every model call. Useful when data-plane workloads should never hold raw provider credentials, or when policy requires per-workspace egress controls. Installed via the dedicated langsmith-auth-proxy chart, not bundled with langsmith. Toggle "Show LLM Auth Proxy in diagram" on the picker to see how it sits in any topology.

How topology changes where this runs

The component set above is the same across topologies. What changes is where each piece runs and who operates it:

• Where the base platform runs sets trace residency. SaaS puts the base platform (including ClickHouse and object storage) in LangChain infrastructure; self-hosted puts it in your cluster or attached managed services; hybrid keeps the base platform in SaaS while agents run in your cloud.
• Where the data plane runs. Co-located with the control plane (single cluster), in separate per-env or per-namespace data planes, or in a different environment entirely (hybrid, on-premises).
• Air-gapped adds image-mirror infrastructure (a registry such as Harbor or Artifactory plus a sync tool like Skopeo, crane, or regclient) and an on-premises LLM gateway. The LangSmith services running in the cluster are the same set.

Split control plane and data plane (legacy)

When the control plane and data plane run in different clusters or environments (hybrid, remote data planes), the data plane is deployed with the separate langgraph-dataplane chart against a langsmith control plane.

For new deployments, the recommended approach is standalone Agent Servers (langgraph-cloud) that trace back to your LangSmith instance; adding data planes through the control plane is no longer recommended. The configuration below is retained for existing split deployments.

DP side: langgraph-dataplane chart

Tells the listener and agent servers where the control plane lives and how to authenticate to it. Defaults point at LangChain SaaS (api.host.langchain.com / api.smith.langchain.com); override these for a self-hosted or BYOC (bring-your-own-cloud) control plane.

• config.hostBackendUrl: URL of the CP host-backend. The listener calls this to pull deployment config and validate tokens. Default https://api.host.langchain.com.
• config.smithBackendUrl: URL of the CP LangSmith backend (the trace-ingest endpoint). Trace payloads are POSTed here. Default https://api.smith.langchain.com.
• config.langsmithApiKey: API key the listener uses to authenticate to the CP. Set via existingSecretName in production, not in plaintext.
• config.langsmithWorkspaceId: workspace this DP belongs to. Required.
• config.langgraphListenerId: unique ID for this listener. Required when multiple DPs share a CP.
• config.hostQueue: SAQ queue name (default host). Set a unique value per install when multiple langgraph-dataplane releases share a Redis instance, or the queues collide.
• config.existingSecretName: K8s Secret holding the above, wired via External Secrets Operator from the cloud secret store (SSM / Key Vault / Secret Manager).
• ingress.* / gateway.* / istioGateway.*: pick one for how agent traffic enters the cluster (plain Ingress, Gateway API HTTPRoute, or Istio VirtualService).

CP side: langsmith chart

Holds the JWT secret, license, and platform config. The DP-side langsmithApiKey must be issued from this CP and the JWT secret must match.

• config.langsmithLicenseKey: required for a self-hosted / BYOC CP.
• config.basicAuth.jwtSecret: must match the value the DP-side listener uses (via API key issuance). Mismatch is the most common cause of "auth works locally but the DP cannot reach the CP."
• config.authType: typically mixed for self-hosted (basic auth + OIDC); oauth for OAuth-with-PKCE.
• config.deployment.enabled: set true to install LangSmith Deployment support on the control-plane side. Required for the control plane to issue listener IDs and route Studio traffic to data-plane agent servers.
• config.existingSecretName: same ESO pattern as the DP side; points at the K8s Secret holding license, JWT secret, basic-auth password, etc.

Related

• Deployment topologies: pick a topology by constraints.
• Full topology reference: catalog of all topologies.
• Per-cloud architecture and the full secret/Helm wiring: AWS, Azure, GCP, OCP.