Self-hosted LangSmith vs Langfuse: which fits your environment
If you must run LLM tracing inside your own network, the choice between self-hosted LangSmith and self-hosted Langfuse comes down to licensing and support, not to where the data lives. Self-hosted LangSmith is an add-on to LangChain's Enterprise plan, requires a license key, and deploys to your Kubernetes cluster with Helm charts, with Terraform also documented in the LangSmith self-hosting docs. It fits teams that already buy LangChain Enterprise, want vendor-backed support, and build mainly on LangChain or LangGraph. Self-hosted Langfuse fits teams that want the core product under the MIT license, with no contract needed to run it.
The decision turns on three questions. First, does your governance require a license key and a vendor support agreement? If so, LangSmith's Enterprise path matches that procurement model, and Langfuse's Self-Hosted Enterprise plan is the comparable option, with a named support engineer and a support SLA on its pricing page. Second, is your team LangChain-centric? LangSmith's tracing integrations are the most direct for LangChain and LangGraph code, while Langfuse also accepts OpenTelemetry-based instrumentation. Third, must every feature work without a commercial contract? In Langfuse, features such as project-level RBAC roles, protected prompt labels, data retention policies, audit logs, server-side data masking and SCIM need an Enterprise license key, so confirm which of these your controls depend on before you commit to the open-source tier.
Both platforms run on PostgreSQL, ClickHouse, Redis or Valkey and S3-compatible storage, so your infrastructure team carries similar operating work either way. Ask LangChain for a written quote covering the license, the Kubernetes footprint and support terms, and map each Langfuse feature you need against the Langfuse license key docs before comparing totals. Hard requirements on licensing or vendor support should settle the choice early, and the cost and migration sections of this page explain what follows from it.
Which option fits which scenario
This table maps common buying conditions to the better self-hosted fit, Enterprise self-hosted LangSmith or self-hosted Langfuse. Read each row as a condition first, then check whether it applies to your environment, since the advantage only matters when that condition is true.
| Scenario | Better fit | Why it matters |
|---|---|---|
| Existing LangChain Enterprise contract | Self-hosted LangSmith | Self-hosted LangSmith is an add-on to the Enterprise plan and deploys with Helm or Terraform, so teams already under that contract avoid a second procurement and keep one vendor relationship. |
| Self-hosting without a license key | Self-hosted Langfuse | Core features and APIs are in the MIT-licensed version without limits. Self-hosted LangSmith requires a license key, so this advantage holds only if you do not need LangSmith-specific enterprise features. |
| Named engineer and support SLA | Self-hosted Langfuse (Enterprise plan) | Langfuse's custom-priced Self-Hosted Enterprise plan adds a named support engineer, solutions architect access and a support SLA. Confirm the current LangSmith support tier in writing before comparing. |
| Regulated network with strict egress limits | Self-hosted Langfuse | Langfuse runs on your PostgreSQL, ClickHouse, Redis or Valkey and blob storage with no mandatory vendor call-home. Check the LangSmith license and billing telemetry requirements with the vendor before assuming a fit. |
| Same codebase as the cloud product | Self-hosted Langfuse | Langfuse states self-hosted deployments use the same codebase as Langfuse Cloud, so behavior is easier to reproduce between environments. Confirm feature parity for your version. |
| Advanced access control and audit requirements | Depends on the key | Langfuse RBAC, audit logs, SCIM and data masking sit behind an enterprise key, as does LangSmith's enterprise tier. Compare the specific controls your assessor needs against each plan. |
| Small team, Docker Compose testing only | Self-hosted Langfuse | Compose on a single VM is documented for testing without high availability. Production needs Kubernetes with Helm or Terraform, so plan that effort before choosing. |
Where the data lives and who holds the keys
Both self-hosted options keep traces inside your own cluster and cloud account, so the data location is rarely the deciding factor. What separates them is the license key, the identity features behind it, and the evidence your team must produce for an assessment.
Data stays in your cluster
Self-hosted LangSmith deploys to your own Kubernetes cluster with Helm or Terraform, and self-hosted Langfuse runs on Kubernetes with Helm or Terraform for production. In both cases traces, prompts and evaluation records sit in databases and buckets your team operates. Confirm which backing services each deployment writes to, and where backups and logs are copied, before you sign off on residency.
License key versus MIT core
Self-hosted LangSmith is an add-on to LangChain's Enterprise plan and needs a license key under the vendor's Enterprise terms. Langfuse's core features and APIs are MIT licensed and run without a key, while only enterprise-directory code and listed advanced features require one. Ask your counsel to read both license files, since a key also governs what you may modify and redistribute.
Identity: SSO and SCIM
Single sign-on and user provisioning decide who can read production traces. Langfuse documents SSO in its authentication guide, and its org management API with SCIM sits behind an Enterprise license key. Confirm with LangChain which identity protocols, role models and provisioning paths your LangSmith plan includes, and map each role to the teams that actually need trace access.
Compliance evidence you produce
Neither product gives you audit evidence by default. Your team must document access reviews, backup restore tests, retention settings, encryption configuration and change records for the trace store. Langfuse's audit logs and data retention policies sit behind its enterprise key, so check whether you need them before you design the evidence trail.
Who supports the deployment
Support is the other licensing difference. Langfuse's free self-hosted plan has community support, while its custom-priced Self-Hosted Enterprise plan adds a named support engineer, solutions architect access and a support SLA. LangSmith support depends on your LangChain Enterprise contract. Get the response commitments in writing from each vendor before you compare their costs.
What DeployOpen prepares
DeployOpen plans, implements, hardens and documents the self-hosted stack in your own accounts, and prepares the controls and evidence your assessment will review. DeployOpen does not issue audit reports, attestations or certifications. Independent auditors and certification bodies make that determination, so agree the evidence scope with them early in the engagement.
Why the infrastructure stacks look almost identical
Both self-hosted LangSmith and self-hosted Langfuse ask the infrastructure team to run the same class of stateful services: PostgreSQL for metadata, ClickHouse for trace analytics, Redis or Valkey for queuing and caching, and S3-compatible blob storage for uploaded and exported data. The day-to-day operational work of backups, upgrades, capacity planning, network policy and monitoring therefore overlaps heavily, and the platform choice changes less of that work than the licensing comparison suggests. The practical question is which of these services your team already operates well, because that decides how much new runbook material you need.
Langfuse's self-hosting model is easy to inspect. It runs two application containers, Langfuse Web for the UI and APIs and Langfuse Worker for asynchronous event processing, on top of the four data services. Its scaling guide lists minimum resources of 2 CPU and 4 GiB for web, worker and PostgreSQL, 1 CPU and 1.5 GiB for Redis or Valkey, and 2 CPU and 8 GiB for ClickHouse, with at least 16 GiB of ClickHouse memory for larger deployments. Use these figures as a baseline for sizing your own node pools and storage classes, not as a production recommendation for your ingestion volume.
Before you compare run costs, ask LangChain for the equivalent sizing guidance for the self-hosted LangSmith chart, along with which Helm and Terraform options it supports for your Kubernetes environment. Ask how many services it deploys, which data stores are bundled and which must be provided, and what the Enterprise license key covers at runtime. Once you have both sizing sets side by side, the comparison of compute, storage and staffing becomes concrete.
Operating effort on Kubernetes, Docker Compose and in production
Langfuse documents Docker Compose on a single virtual machine as the path for testing. It brings up the same two application containers, Langfuse Web and Langfuse Worker, alongside PostgreSQL, ClickHouse, Redis or Valkey and S3-compatible blob storage, but on one host with no high availability. That makes it useful for proving integrations, reviewing the UI and validating trace shapes before committing to a production design. It is not a substitute for a production topology, and a single VM failure takes tracing offline.
- Single point of failure: the stack, its databases and its storage share one host, so host maintenance or failure stops ingestion.
- Sizing floor: the scaling guide lists minimum resources of 2 CPU and 4 GiB for web, worker and PostgreSQL, 1 CPU and 1.5 GiB for Redis or Valkey, and 2 CPU and 8 GiB for ClickHouse.
- Backups: you must schedule and test backups of PostgreSQL and ClickHouse yourself, since a trial host is often treated as disposable.
- Upgrades: minor updates within a major version apply database migrations at startup, so pin the image tag and read the release notes first.
- Promotion path: plan to rebuild on Kubernetes rather than lift the Compose file into production.
Confirm with Langfuse which Compose file and version it recommends for your trial, and how its data directories should be backed up.
For production, Langfuse documents Kubernetes with Helm, and Terraform-based deployments on AWS, Azure and GCP. Your platform team owns the cluster, ingress, TLS, secrets, backups and monitoring, while the Langfuse charts cover the application layer. The managed database and storage services you choose (or self-run databases) determine how much of the operating load you carry. LangSmith's self-hosted option also installs into the customer's Kubernetes cluster with Helm charts and Terraform, so both products place a comparable operating burden on the platform team.
- Chart and module ownership: you track chart versions, values files and Terraform state for every environment.
- Data services: decide whether PostgreSQL, ClickHouse, Redis or Valkey run as managed services or inside the cluster, since that changes backup, patching and failover work.
- Object storage: configure S3-compatible storage with lifecycle and encryption settings that match your retention policy.
- Monitoring: alert on worker backlog, ClickHouse disk use and database connections before users notice gaps in traces.
- Access and networking: plan ingress, private endpoints and egress rules for model providers and the Langfuse SDKs.
Ask Langfuse and your cloud team to confirm the supported Kubernetes versions and the HA settings in the Helm chart, and ask LangChain to confirm its equivalent guidance for the Enterprise chart.
Langfuse's scaling guide describes two main levers. The first is scaling the worker containers on CPU load, since workers process asynchronous events. The second is splitting langfuse-web into separate ingestion and user interface deployments when ingestion becomes heavy, so trace writes do not compete with dashboard queries. Scaling decisions depend on trace volume, payload size and how much ClickHouse memory and disk you provision, so they should be tested with your own traffic profile rather than copied from a default.
- Worker scaling: add worker replicas as CPU load rises, and watch the queue for lag rather than only average CPU.
- Web split: run one deployment for SDK ingestion and another for the UI and APIs, each with its own autoscaling rules.
- ClickHouse memory: the guide points to at least 16 GiB of ClickHouse memory for larger deployments, so size nodes before ingestion grows.
- Redis or Valkey: cache and queue load grows with concurrency, so set memory limits and eviction behavior deliberately.
- Load testing: replay representative traces in a staging cluster to measure headroom before a launch.
Confirm the scaling thresholds and HA recommendations for your expected volume with Langfuse, and ask LangChain to state its own scaling and high availability guidance for self-hosted LangSmith.
What each option costs to run, and what drives it
Both options are self-hosted, so the bill is mostly the infrastructure and people behind them rather than a per-seat subscription. The cards below separate the license and support lines from the data stores, retention and upkeep that recur, and list what to put in writing before you compare quotes.
LangSmith Enterprise license fee
Self-hosted LangSmith is an add-on to LangChain's Enterprise plan and needs a license key, so the license is a contract line item before any infrastructure is counted. Ask LangChain to state in writing whether the fee covers the self-hosted deployment only or also cloud usage, how it is renewed, and whether support is included. Confirm what happens to the key if you stop renewing, since the deployment depends on it.
Optional Langfuse Enterprise key and support
The open-source Langfuse self-hosted version has no license fee and includes all core features. Some features, such as RBAC roles, audit logs, data retention policies and SCIM, need an Enterprise license key, and the Self-Hosted Enterprise plan adds a named support engineer, solutions architect access and a support SLA. The pricing page lists this plan as custom-priced, so request a written quote that names the features, support hours and SLA you need.
ClickHouse, PostgreSQL and Redis hosting
Both platforms run on PostgreSQL, ClickHouse, Redis or Valkey and object storage, so the hosting bill is mostly compute and disk for these stores. Langfuse's scaling guide lists minimum resources of 2 CPU and 8 GiB for ClickHouse, with at least 16 GiB of ClickHouse memory for larger deployments. Ask your platform team to size each store separately and to confirm whether LangSmith's Helm chart sets comparable resource requests for its own dependencies.
Storage growth tied to retention
Trace storage grows with the volume of traces and the length of time you keep them, so retention is the main driver of disk spend. A hosted plan may bill extended retention separately, while in your own cluster you pay for the disk directly. Langfuse's v3 to v4 guide also advises about 3x ClickHouse disk headroom when backfilling historic data, which matters if you migrate years of traces at once. Model growth with your own trace volume and retention policy before you approve the storage budget.
One-time design and migration work
Design, initial deployment, network and identity setup, SDK instrumentation changes and the move of prompts, datasets and evaluators are one-time costs. These are usually the largest cash outlay in year one and are often sized by internal staff time or a fixed-scope implementation partner. Write down which items are in scope, who owns the evaluator rebuild, and what acceptance tests prove the migrated data is complete.
Recurring upgrades and internal staff time
Upgrades, backups, monitoring and on-call support recur for both platforms and are mostly staff time. Langfuse applies database migrations automatically at startup for updates within a major version, but major upgrades follow dedicated migration guides that take planned effort. Estimate the hours your platform engineers spend per upgrade cycle, and compare that with what a support tier or retainer would cover before you decide who carries the pager.
Upgrades, support and who answers when production breaks
Before you commit to self-hosting either platform, decide who carries the upgrade work and who you call when a release breaks tracing in production. For self-hosted Langfuse, the upgrade model is documented and split by version size. Updates within a major version are described as non-disruptive, with database migrations applied automatically at startup. Major moves, such as v3 to v4, follow dedicated migration guides. The v3 to v4 guide requires ClickHouse 25.12 or later (26.4 recommended), PostgreSQL 15 or later and Redis 7.0 or later, and moves data to an observations-first ClickHouse model. It also advises about 3x ClickHouse disk headroom when backfilling historic data, so plan that capacity before you start, and rehearse the upgrade against a copy of production data in a non-production environment.
Support is where the two models differ most. Self-hosted Langfuse is MIT licensed outside its ee directories, and the core features work without a key. Its Self-Hosted Enterprise plan is custom priced and adds a named support engineer, solutions architect access and a support SLA. Ask Langfuse which of these you would receive at your scope, what response times the SLA defines, and whether upgrade assistance is included. Your own platform team still owns the Kubernetes cluster, PostgreSQL, ClickHouse, Redis or Valkey and blob storage, so the upgrade calendar is yours either way.
For self-hosted LangSmith, the support and upgrade terms come from the Enterprise contract and the license key, not from the open documentation. Before comparing, ask LangChain in writing which versions are covered, who applies Helm chart and Terraform updates, how upgrades are tested against your data, what the escalation path is during an outage, and what happens to your deployment if the license key lapses. Once you have those answers, write them next to the Langfuse terms and compare them on the same questions. Confirm each point in writing rather than relying on a sales conversation.
What a move from self-hosted LangSmith to Langfuse involves
The sequence moves traces, prompts and evaluation workflows from a LangSmith Enterprise self-hosted deployment to a self-hosted Langfuse deployment, with both systems running side by side until the team is confident in the new one. Each step ends with a check that shows the move is ready to continue.
Inventory LangChain and LangGraph tracing usage
Engineering leads list every service that sends traces to LangSmith, including LangChain and LangGraph callbacks, direct SDK calls, environment variables such as tracing settings, and any OpenTelemetry exporters already in place. Platform and application teams own this list together, since application code usually holds the instrumentation. The step is done when every service has an owner and a documented instrumentation path, and when the team knows which projects, datasets and prompts are actually in use.
Stand up Langfuse in a non-production cluster
The platform team deploys self-hosted Langfuse in a non-production Kubernetes cluster using the Helm chart, backed by PostgreSQL, ClickHouse, Redis or Valkey, and S3-compatible storage. Langfuse documents Docker Compose for testing only, so a production-like layout is the right test target. Confirm the current component versions and sizing against the Langfuse scaling guide before you build. The step is done when the web and worker containers run, sign-in works through your identity provider, and a test trace appears in the UI.
Switch instrumentation in a staging environment
Developers point LangChain and LangGraph callbacks, or OpenTelemetry exporters, at the Langfuse endpoint in staging first, leaving LangSmith tracing enabled in parallel where possible. Keep the change in configuration and secrets so it can be rolled back without a code release. The step is done when representative workflows produce complete traces in Langfuse, including nested chains, tool calls and token and cost data, and when those traces match what LangSmith shows for the same runs.
Export or rebuild datasets and prompts
Teams decide what history to keep. LangSmith's bulk export writes trace data to an S3-compatible bucket in Parquet format, but access depends on the plan: customers who signed up after August 3, 2026 need the Enterprise plan, and earlier Plus customers keep access until February 1, 2027. Datasets and prompt versions usually need manual transfer or scripted re-creation in Langfuse, since they are not part of the trace export. Confirm your plan's export access with LangChain before relying on it. The step is done when the agreed datasets and prompt versions exist in Langfuse with labels that match production use.
Rebuild evaluators and annotation queues
Evaluation owners recreate LangSmith online evaluators, datasets and annotation queues as Langfuse LLM-as-a-judge evaluations, annotation queues and dataset experiments. Some LangSmith evaluator logic will need rewriting, and some review workflows will need new roles and permissions. Note that project-level RBAC, audit logs and data retention are Enterprise license key features in self-hosted Langfuse, so confirm which controls you need before you finalize the design. The step is done when each evaluator from the inventory runs against Langfuse traces and produces scores that the reviewers accept.
Run both systems in parallel
For a defined period agreed by the team, production traffic goes to both LangSmith and Langfuse, and the team compares trace completeness, latency overhead, evaluation scores and alert behavior. Platform engineers watch Langfuse resource use, especially ClickHouse disk and worker CPU, against the sizing guidance. The step is done when the team signs off on parity for the metrics it agreed to track and has a tested rollback path back to LangSmith.
Cut over and retire LangSmith
The team switches all production services to Langfuse, removes LangSmith keys and tracing variables from configuration, and keeps the LangSmith deployment read-only for a retention window that compliance owners set. Before decommissioning, export any records that must be kept under your own retention policy. The step is done when no service sends traces to LangSmith, the archive and access decisions are documented, and the self-hosted LangSmith deployment and its license are formally retired.
Questions buyers ask before choosing a self-hosted LLM tracing platform
Does self-hosted LangSmith need an Enterprise license key?
Yes. Self-hosted LangSmith is an add-on to LangChain's Enterprise plan and needs a license key before it runs in your cluster. It deploys to your own Kubernetes cluster with Helm charts, and Terraform is also documented, so the infrastructure stays yours while the commercial relationship stays with LangChain. Confirm the current terms, the license scope and any usage reporting with LangChain in writing before you plan around them, because the key determines whether the deployment is available to you at all. Self-hosted LangSmith documentation sets out the deployment model.
What drives the cost of self-hosting each option?
The license is only one line. With either platform you pay for the Kubernetes or VM capacity, the managed or self-run PostgreSQL, ClickHouse, Redis or Valkey and object storage, backups, monitoring, upgrades and the engineers who run them. For self-hosted Langfuse, the Enterprise key is optional and adds support and governance features, and its pricing page lists a custom-priced Self-Hosted Enterprise plan. For self-hosted LangSmith, the Enterprise plan is a prerequisite. Trace volume and retention drive storage growth in ClickHouse, so ask each vendor for its license terms and a sizing estimate based on your expected trace volume and retention period.
How long does a migration take, and what determines it?
The duration depends on your trace volume, the number of LangChain and LangGraph integrations, how many datasets, prompts and evaluators must be rebuilt, and how much historical data you need to carry over. LangSmith's bulk export writes trace data to an S3-compatible bucket as Parquet, and plan eligibility affects whether that export is available to you, so check your account's plan first. Historical import into Langfuse adds ClickHouse capacity requirements. No duration is fixed here; confirm your estimate in a written scope that lists each integration, data set and cutover step.
Can our team deploy self-hosted Langfuse without outside help?
Many teams with an experienced platform group can, provided they are comfortable running several stateful services. Langfuse documents Docker Compose on a single VM for testing, without high availability, and Kubernetes with Helm or Terraform for production on AWS, Azure and GCP. A production deployment runs Langfuse Web, Langfuse Worker, PostgreSQL, ClickHouse, Redis or Valkey and S3-compatible storage, so someone must own backups, upgrades and capacity. Teams that want an independent implementation partner can scope that work in writing. Ask DeployOpen or any partner for a fixed-scope plan that names who operates what after handover.
What skills and infrastructure does the team need?
Plan for Kubernetes or container operations, PostgreSQL administration, ClickHouse operations, Redis or Valkey, object storage, TLS and secrets handling, and observability for the platform itself. The Langfuse scaling guide lists minimum resources of 2 CPU and 4 GiB for web, worker and PostgreSQL, 1 CPU and 1.5 GiB for Redis or Valkey, and 2 CPU and 8 GiB for ClickHouse, with at least 16 GiB of ClickHouse memory for larger deployments. Major upgrades require ClickHouse 25.12 or later, PostgreSQL 15 or later and Redis 7.0 or later for the v3 to v4 path. Check these against your own environment and your data growth plans.
Can we avoid Langfuse Enterprise features and still run it safely?
Yes, for many teams. Langfuse states that all core features and APIs are available in the MIT-licensed open source version without limits, and self-hosted deployments run the same codebase as Langfuse Cloud. Features that need an Enterprise license key include project-level RBAC roles, protected prompt labels, data retention policies, audit logs, server-side data masking, SCIM provisioning and the instance management API. If your controls require any of these, budget for the key or implement compensating controls, and confirm with your auditors which controls you need. Review the Langfuse license key documentation before you decide.
How do license terms affect compliance and data control?
Licensing determines what you may run and who must be paid, while the deployment determines where data sits. Self-hosting either platform keeps traces and prompts in your infrastructure, but the Enterprise key may require contact with the vendor and, for LangSmith, a license check is part of the deployment. Ask each vendor whether its license requires outbound connections, usage reporting or telemetry, and document the answers for your security review. DeployOpen prepares systems, controls and evidence for compliance assessments, but independent auditors issue any audit reports or attestations.
How DeployOpen helps evaluate, implement and migrate
DeployOpen is a Chainscore Labs company that plans, implements, hardens, backs up, upgrades and documents self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For a Langfuse decision, that means the work covers the actual components: the Langfuse Web and Langfuse Worker containers, PostgreSQL, ClickHouse, Redis or Valkey, and S3-compatible blob storage. We can also help you decide whether the Enterprise license key is needed for the controls you require, such as project-level RBAC roles, audit logs, data retention policies or SCIM provisioning, and we document which of those you would be paying for before you buy anything.
Most engagements start with a fixed-scope evaluation against written requirements. Before work begins, we agree the scope, deliverables and timeline in writing. A typical evaluation covers a test deployment of the Docker Compose or Kubernetes Helm setup, sizing against the minimum resources in the Langfuse scaling guide, and a review of how LangSmith's Parquet bulk export, LangChain and LangGraph callbacks and your prompts and datasets would map into a Langfuse project. Migration and implementation follow the same written pattern, and the handover includes hardening, backup and restore testing, and runbooks your team can keep using. Ongoing upgrades, including the v3 to v4 move with its ClickHouse version and backfill requirements, and continuous security testing can be covered by optional retainers. We do not publish prices. A quote follows from the agreed written scope, so ask for the cost of each component (infrastructure, your staff time, license key, and DeployOpen work) to be listed separately.
