LangSmith Self-Hosting: When to Run It On-Premise

Every team that gets serious about LLM observability eventually hits the same question. LangSmith cloud works beautifully for tracing your chains and agents, but every trace you send it contains prompts, retrieved documents, and model outputs — which means it contains your data. For a healthcare company, a bank, a defense contractor, or any enterprise with a strict data residency policy, that is the moment someone from security asks: "Can we run this ourselves?" The answer is yes. LangSmith ships a self-hosted edition that you can run inside your own VPC, your own data center, or even a fully air-gapped network. But "can" and "should" are very different questions. Self-hosting LangSmith means operating a multi-service platform with two databases, a queue, blob storage, and an ingestion pipeline that must keep up with every LLM call your applications make. This guide walks through what LangSmith self-hosting actually involves, the architecture you inherit, how a deployment looks in practice, and a clear-eyed framework for deciding whether on-premise is the right call for your team.

What LangSmith Self-Hosting Actually Means

LangSmith is LangChain's observability and evaluation platform. It ingests traces from your LLM applications — every chain step, tool call, retriever hit, prompt, and completion — and gives you dashboards, debugging views, datasets, evaluation runs, prompt management, and human feedback collection on top of that data.

The self-hosted edition is the same platform, packaged so that you deploy and operate it on infrastructure you control. Instead of your SDK sending traces to LangChain's cloud endpoint, it sends them to a URL inside your own network. Nothing about your traces ever leaves your environment: not the prompts, not the completions, not the retrieved context, not the user inputs embedded inside them.

A few things are important to understand up front.

• Self-hosted LangSmith is a commercial offering. It requires a license key issued by LangChain under an enterprise agreement. You do not get it by cloning a repository; you get it by talking to their sales team. Budget for that conversation before you budget for infrastructure.
• It is distributed as container images with official deployment tooling — a Helm chart for Kubernetes and a Docker Compose option for smaller or evaluation setups. Kubernetes is the recommended path for anything production-grade.
• You inherit the full operational surface. Upgrades, backups, scaling, certificate management, authentication integration, and capacity planning all become your responsibility.
• The trade you are making is explicit: full control over data and network boundaries, in exchange for owning the operations of a real distributed system.

If your organization already runs self-hosted GitLab, Artifactory, or Grafana, this will feel familiar. If your team has never operated a stateful platform, the honest advice is to pause and read the day-two operations section below twice.

The Architecture You Are Signing Up to Run

Before deciding anything, you should know what is inside the box. Self-hosted LangSmith is not a single container. It is a set of cooperating services, and each one has operational implications.

The core application services include:

• Frontend — the web UI you interact with, served behind whatever ingress or load balancer you put in front of it.
• Backend API — the primary service handling reads and writes from both the UI and the SDKs.
• Platform backend — supporting APIs for authentication, tenancy, and platform-level operations.
• Queue workers — asynchronous consumers that process incoming trace ingestion. This is the component that absorbs bursts when your applications suddenly generate ten times the usual trace volume.
• Playground service — powers the prompt playground, proxying requests to whichever model providers you configure.

The stateful dependencies are where the operational weight lives:

• PostgreSQL stores transactional and relational data: organizations, workspaces, users, API keys, datasets, annotations, prompt versions, and configuration.
• ClickHouse stores the traces themselves — runs, spans, feedback, and the token-level metadata that powers filtering and analytics. ClickHouse is a columnar OLAP database, chosen because trace workloads are write-heavy and query patterns are analytical. It is also the component that will dominate your disk usage and the one most teams have the least experience operating.
• Redis handles queuing and caching between the API layer and the workers.
• Blob storage (S3, GCS, Azure Blob, or an S3-compatible store like MinIO) can be configured to hold large trace payloads — long prompts, big completions, multimodal inputs — keeping ClickHouse rows lean. For air-gapped deployments, MinIO inside the cluster is the common pattern.

You can run PostgreSQL, ClickHouse, and Redis as in-cluster workloads from the Helm chart, or point LangSmith at externally managed instances. For production, externalizing PostgreSQL and Redis to managed services (RDS, Cloud SQL, ElastiCache, or your internal DBA-managed equivalents) is usually the right move: it offloads backups and failover to systems your organization already trusts. ClickHouse is the harder decision — managed ClickHouse keeps traces off your cluster's disks but reintroduces an external data flow you may be self-hosting specifically to avoid.

Map this against your platform team's capacity honestly. The architecture is not exotic, but it is real infrastructure with real failure modes: a ClickHouse disk filling up, a Redis eviction storm under burst load, queue workers falling behind and delaying trace visibility during the exact incident you needed traces for.

When Self-Hosting Is the Right Call

There are situations where self-hosting is not just defensible but clearly correct.

Regulatory and compliance requirements. If you operate under HIPAA, PCI DSS, FedRAMP-adjacent constraints, or sector-specific rules in banking and insurance, sending raw prompts and completions to a third-party SaaS may be a non-starter regardless of the vendor's certifications. Traces are not sanitized telemetry — they are your application's actual inputs and outputs. If a patient's symptoms or a customer's account details flow through your LLM app, they flow through your traces too.

Data residency and sovereignty. Some jurisdictions and some contracts require that data never leave a specific country or a specific network. LangSmith does offer an EU cloud region, which solves residency for many European teams — check that before assuming you must self-host. But if your requirement is "data never leaves our AWS account" or "data never leaves this building," self-hosting is the only answer.

Air-gapped and restricted networks. Defense, critical infrastructure, and some research environments run networks with no outbound internet access at all. Self-hosted LangSmith supports this: you mirror the container images into an internal registry, run MinIO for blob storage, and operate entirely offline. No cloud product can serve this environment by definition.

Contractual obligations to your own customers. If you sell to enterprises and your MSAs promise that customer data is processed only within your infrastructure, third-party trace ingestion can silently violate those promises. Legal teams increasingly ask specifically about LLM observability tooling during vendor review, because they have learned that traces contain everything.

Network proximity and egress control. If your LLM workloads run in a private VPC with locked-down egress, keeping the observability plane inside the same boundary simplifies your security story: one less egress rule, one less vendor in the data flow diagram, one less DPA to negotiate.

Notice what is not on this list: cost savings. Teams sometimes assume self-hosting will be cheaper than SaaS pricing at scale. Once you account for the enterprise license, the compute and storage for ClickHouse and friends, and the fraction of a platform engineer's time it takes to operate and upgrade the system, self-hosting is rarely the budget play. Choose it for control, not for savings.

When You Should Stay on Cloud

The mirror image matters just as much, because a self-hosted deployment that nobody maintains becomes a liability within months.

• You are a small team without platform engineering capacity. If nobody on the team has run Kubernetes workloads with stateful dependencies before, LangSmith should not be your training ground. A neglected observability stack fails at the worst time — during an incident, when you need traces most.
• Your data is not actually sensitive. Plenty of LLM applications operate on public documentation, product catalogs, or synthetic data. If a trace leaking would embarrass no one, the compliance argument evaporates.
• Residency is your only concern. The EU region of LangSmith cloud may satisfy GDPR-driven requirements without you operating anything.
• You want the newest features on day one. Cloud gets improvements continuously. Self-hosted releases follow their own cadence, and you apply them on your own schedule — which in practice means you are always somewhat behind.
• Your trace volume is spiky and growing unpredictably. On cloud, that is the vendor's capacity problem. On-premise, it is your ClickHouse cluster's problem, and it will page you.

A useful middle path exists as well: keep sensitive fields out of traces. The LangSmith SDK supports hiding or anonymizing inputs and outputs before they are sent, so some teams satisfy their security review by scrubbing PII client-side while staying on cloud. It weakens debugging (you cannot inspect what you redacted), but it is dramatically cheaper than operating the platform yourself. Evaluate this option seriously before committing to on-premise.

Deploying LangSmith on Kubernetes with Helm

Here is what a real deployment looks like in practice. The supported production path is the official Helm chart, configured through a values file. The exact keys evolve between chart versions, so treat this as a structural illustration of the decisions you will make rather than a copy-paste artifact — but every section below corresponds to a real decision.

# langsmith-values.yaml — structural example
config:
  # License key from your LangChain enterprise agreement
  langsmithLicenseKey: "<your-license-key>"
  # Authentication: wire into your identity provider
  oauth:
    enabled: true
    oauthClientId: "<oidc-client-id>"
    oauthIssuerUrl: "https://sso.yourcompany.com/realms/main"

frontend:
  service:
    type: ClusterIP   # expose via your ingress controller

# Externalize stateful services for production
postgres:
  external:
    enabled: true
    host: "langsmith-pg.internal.yourcompany.com"
    port: 5432
    database: "langsmith"
    existingSecretName: "langsmith-pg-credentials"

redis:
  external:
    enabled: true
    connectionUrl: "redis://langsmith-redis.internal:6379"

clickhouse:
  # In-cluster ClickHouse: plan disk capacity deliberately
  statefulSet:
    persistence:
      size: 500Gi
      storageClassName: "fast-ssd"

# Offload large trace payloads to object storage
blobStorage:
  enabled: true
  bucketName: "langsmith-traces"
  apiURL: "https://s3.us-east-1.amazonaws.com"

# Scale ingestion workers to match trace volume
queue:
  replicas: 3

Installation itself is the easy part:

helm repo add langchain https://langchain-ai.github.io/helm/
helm repo update
helm upgrade --install langsmith langchain/langsmith \
  --namespace langsmith --create-namespace \
  -f langsmith-values.yaml

The work that surrounds those two commands is where the effort actually goes: provisioning the PostgreSQL instance and its backup policy, creating the object storage bucket with correct IAM scoping, registering the OIDC client in your identity provider, issuing TLS certificates for the ingress, sizing ClickHouse disks against your expected trace retention, and mirroring images into a private registry if your cluster cannot pull from public ones. For an evaluation, the Docker Compose route collapses all of this onto one VM — genuinely useful for a proof of concept, and genuinely unsuitable for production.

Pointing Your Applications at Your Own Instance

One of the best things about LangSmith's design is that the application side barely changes. The SDKs and LangChain's automatic tracing are driven by environment variables, so switching from cloud to your self-hosted instance is a configuration change, not a code change:

export LANGSMITH_TRACING=true
export LANGSMITH_ENDPOINT="https://langsmith.internal.yourcompany.com/api/v1"
export LANGSMITH_API_KEY="<api-key-created-in-your-instance>"
export LANGSMITH_PROJECT="checkout-agent-prod"

Everything you have written against LangSmith continues to work: @traceable decorators, evaluate() runs, dataset uploads, the Python and TypeScript clients, prompt pulling. If you instrument through the client object directly, the same idea applies:

from langsmith import Client

client = Client(
    api_url="https://langsmith.internal.yourcompany.com/api/v1",
    api_key="<api-key-created-in-your-instance>",
)

This symmetry has a strategic benefit that is easy to miss: you can prototype against LangSmith cloud on non-sensitive data, validate that the platform earns its place in your stack, and only then commit to the self-hosted migration. Your instrumentation code carries over unchanged. Teams that skip this and start with a self-hosted rollout are making an infrastructure investment before proving product fit.

Day-Two Operations: The Part Nobody Budgets For

Getting LangSmith installed is a week of work. Keeping it healthy is the ongoing cost, and it concentrates in a few predictable places.

Storage growth and retention. Traces accumulate fast. Every LLM call in every environment writes rows to ClickHouse and, if configured, objects to blob storage. Decide retention policies early — how long do production traces live, do staging traces live shorter, what happens to traces attached to datasets — and enforce them with TTLs rather than manual cleanup. The most common self-hosted incident is the least glamorous one: a full disk.

Upgrades. LangSmith is an actively developed product, and self-hosted releases include database migrations across both PostgreSQL and ClickHouse. Read the release notes for every version, never skip reading migration notes, snapshot before upgrading, and rehearse the upgrade in a staging installation first. Falling many versions behind makes each eventual upgrade riskier, so schedule them regularly instead of deferring until something forces your hand.

Backup and recovery. Your backup story has three parts: PostgreSQL (small, critical — it holds your datasets, prompt versions, and configuration), ClickHouse (large, and you must decide whether traces are precious or reproducible), and blob storage. Write down your recovery point objective for each, and actually test a restore. An untested backup is a hypothesis.

Ingestion capacity. Queue workers decouple your applications from ClickHouse writes, which means trace delivery degrades gracefully under load — but it also means lag is possible. Monitor queue depth and worker throughput. If traces appear minutes late during your traffic peaks, scale the workers before your engineers conclude the platform "loses data."

Monitoring the monitor. LangSmith observes your LLM applications; something must observe LangSmith. Wire its components into your existing Prometheus/Grafana or equivalent stack, alert on disk, queue depth, and error rates, and make sure the on-call rotation knows this system exists.

Rule of thumb: assume a meaningful, recurring slice of a platform engineer's attention for the lifetime of the deployment. If that allocation is not realistic in your organization, that fact alone answers the self-hosting question.

A Decision Framework You Can Defend

Pull it together into a sequence of questions you can walk through with your security and platform teams.

1. Do traces contain regulated or contractually protected data? If no — stay on cloud, and revisit if the application's scope changes.
2. Would client-side redaction of sensitive fields satisfy your security review? If yes — stay on cloud with scrubbing enabled, and document what you redact.
3. Does the EU cloud region satisfy your residency requirement? If yes — use it and skip the infrastructure entirely.
4. Is the requirement air-gapped or "never leaves our network"? If yes — self-host; nothing else qualifies.
5. Do you have platform engineering capacity to operate ClickHouse, PostgreSQL, Redis, and a Helm-managed application, including upgrades and backups? If no — fix this first, either by growing the capability or renegotiating the requirement, because a badly operated deployment is worse than either alternative.
6. Is there enterprise budget for the license plus infrastructure plus operations time? Self-hosting is a control decision, not a cost-saving one — make sure the people approving it understand that.

If you reach the end of that list with "self-host" still standing, proceed with confidence: run a Docker Compose evaluation on realistic (but non-sensitive) data, size ClickHouse from the trace volumes you observe, then build the production Helm deployment with externalized PostgreSQL and Redis, OIDC against your identity provider, and retention TTLs configured from day one. Teams that follow that sequence end up with an observability platform their security team actually likes — full trace visibility into every prompt, retrieval, and completion, with the data never crossing their network boundary.

Keep Learning

Self-hosting is only one chapter of the LangSmith story. Whichever side of the on-premise decision you land on, the skills that matter day to day are the same: instrumenting chains and agents so traces are actually readable, building evaluation datasets from production failures, running LLM-as-judge experiments, wiring feedback loops, and managing prompts as versioned assets. If you want to build those skills hands-on — from your first @traceable decorator through production-grade evaluation pipelines — the LangSmith Tutorial course on teachyou.ai walks through the entire platform step by step, with real projects instead of toy examples. Master the workflow first, and the infrastructure decision covered in this article becomes a straightforward engineering choice rather than a leap of faith.