LangSmith vs Langfuse

LangSmith Cloud suits teams that want a managed service with regional choice and LangChain-native workflows. Langfuse suits teams that need its core self-hosted under MIT, with enterprise keys only for specific governance features.

On this page

When LangSmith or Langfuse fits your team

Choose LangSmith Cloud when your team wants managed operations, already builds on LangChain and LangGraph, and can place its data in one of the four supplied Cloud regions: GCP US (Iowa), GCP EU (Netherlands), GCP APAC (Sydney) or AWS US (Ohio). Data stays in the region where the account signed up, while billing information stays in the US, so confirm that split with your privacy team before committing. If your renewal is driven by a need to keep everything inside your own network, LangSmith Cloud does not meet that need on its own, and self-hosted LangSmith requires the Enterprise plan, a license key and a Kubernetes cluster, as documented in the LangSmith self-hosting docs.

Choose Langfuse when you want to self-host without an enterprise contract, when your stack mixes frameworks and you need framework-neutral tracing, or when you need direct control over where traces and prompts are stored. Its core features and APIs are available in the MIT-licensed version, and self-hosted deployments use the same codebase as Langfuse Cloud. Some governance features, such as project-level RBAC roles, protected prompt labels, data retention policies, audit logs and SCIM, need an Enterprise license key, so list the controls you must have before assuming the free tier covers them. Langfuse also depends on PostgreSQL, ClickHouse, Redis or Valkey and S3-compatible storage, which your platform team will need to operate.

The decision turns on three questions. First, where data must live: a regulated workload may rule out any Cloud region that does not match your residency obligations, which points toward self-hosting. Second, which governance features are mandatory: check SSO, RBAC, retention and audit logging against each plan rather than against marketing summaries. Third, who will run the stack: LangSmith's self-hosted model shifts operations to your team under a commercial agreement, while Langfuse shifts both operations and licensing decisions to your team, so a fixed-scope implementation partner or a support retainer may be part of the answer. Confirm these points with each vendor in writing before the renewal date.

Which option fits which scenario

This table matches common team situations to the platform that fits them better, with the supplied facts behind each choice. Read each row against your own constraints: region, licensing budget, framework mix, identity requirements and cluster capacity. Where a row favors Langfuse, confirm the enterprise key needs for the features you depend on before you commit.

ScenarioBetter fitReason
Managed service with an EU or US regionLangSmith CloudLangSmith Cloud runs in GCP US (Iowa), GCP EU (Netherlands), GCP APAC (Sydney) and AWS US (Ohio), with data staying in the signup region, so a managed option is available without running a cluster. Billing information stays in the US, so confirm that against your residency policy.
Self-hosted requirement without an enterprise budgetLangfuseCore Langfuse features and APIs are in the MIT-licensed open source version without limits, while self-hosted LangSmith requires a LangChain Enterprise plan and a license key.
LangChain-only stackLangSmith Cloud (or Langfuse if self-hosting)LangSmith is built by the LangChain team, so its tracing and evaluation fit LangChain and LangGraph without extra setup. Langfuse also supports these frameworks, so the choice hinges on hosting and licensing rather than integration depth.
Mixed framework estateLangfuseLangfuse is framework-neutral and accepts OpenTelemetry traces, so teams running several agent frameworks can use one trace backend. Confirm the SDK and OpenTelemetry coverage for each framework in your estate before committing.
Need for RBAC or SCIMDepends on plan and keySelf-hosted Langfuse gates project-level RBAC roles and the org management API with SCIM behind an enterprise license key. Confirm which role model and identity features LangSmith's plan includes in your contract.
Team with no Kubernetes capacityLangSmith CloudSelf-hosted LangSmith deploys to a customer Kubernetes cluster with Helm or Terraform. Langfuse's production path also uses Kubernetes, though Docker Compose on a single VM is documented for testing without high availability.
Illustrative: a regulated team that must keep traces in-country and has a platform group running KubernetesLangfuse, self-hostedLangfuse needs PostgreSQL, ClickHouse, Redis or Valkey and S3-compatible storage inside your boundary, so the team controls where traces live. Ask your platform group to size ClickHouse memory against your ingestion volume.

Which features sit behind a license key in Langfuse and LangSmith

The first thing to settle is which controls you pay for and which you get free. In self-hosted Langfuse, the core features and APIs are MIT-licensed and available without limits, and self-hosted deployments run the same codebase as Langfuse Cloud. The features that need an Enterprise license key are project-level RBAC roles, protected prompt labels, data retention policies, audit logs, server-side data masking, UI customization, organization creators, the org management API with SCIM, and the instance management API. Those are the controls a security or compliance team usually asks for first, so they belong in the cost line from day one rather than after go-live.

Self-hosted LangSmith follows a different model. It is an add-on to LangChain's Enterprise plan, it needs a license key, and it deploys to your Kubernetes cluster with Helm charts, with Terraform also documented. Nothing in the self-hosted LangSmith path is available as a free open-source tier, so the decision is whether you need an Enterprise contract at all. For Langfuse, the question is narrower: which of the listed controls your policy requires, and whether you can run without them while you build the rest of the program.

Before you decide, confirm current SSO and RBAC availability by plan with each vendor in writing. Ask Langfuse which SSO methods and role settings sit in the open-source release and which require the enterprise key, and check the Langfuse license key documentation for the current list. Ask LangChain which SSO, RBAC and retention controls are included in the Enterprise add-on, in each cloud region, and in self-hosted deployments. Ask for the answers as contract language so the commitment does not depend on a sales call.

Capabilities compared: tracing, evaluation, prompts and governance

This table compares LangSmith Cloud and self-hosted Langfuse on the capabilities teams usually weigh first. Where a cell says to confirm, check the current plan documentation with the vendor before you decide, because packaging changes between releases. The main takeaway is that Langfuse's core features are open source, while several governance controls depend on an enterprise license key.

CapabilityLangSmith (commercial)Langfuse (open source core)
Tracing and OpenTelemetry supportTracing is part of the platform. Confirm current OpenTelemetry ingestion support with LangChain before relying on it.Supports OpenTelemetry ingestion through its documented OpenTelemetry integration, with core tracing in the MIT-licensed version.
LangChain and LangGraph integrationNative integration maintained by LangChain. Confirm coverage for your LangGraph version.Callback-based integration with LangChain and LangGraph. Confirm the handler version against your framework release.
LLM-as-a-judge and datasetsDatasets, experiments and online evaluators are part of the product. Confirm feature parity for your evaluator types.Core features, including LLM-as-a-judge, dataset experiments and annotation queues, are in the MIT-licensed version. Confirm which evaluators you need.
Annotation queuesAvailable in the hosted product. Confirm queue behavior and reviewer roles on your plan.Available in the open source version. Confirm reviewer workflows and export options in your deployment.
Prompt management and deployment labelsPrompt hub and playground are part of the product. Confirm versioning and label behavior.Prompt versions and labels with SDK-side caching are in the open source version. Protected prompt labels require an enterprise license key.
Role-based access controlRole controls depend on plan. Confirm which roles are available on your contract.Organization-level roles are open source. Project-level RBAC roles require an enterprise license key.
SSO and SCIMConfirm SSO and SCIM availability on your plan with LangChain.SSO is documented in the self-hosting authentication guide. The org management API with SCIM requires an enterprise license key.
Audit logs and data maskingConfirm audit log scope and export options with the vendor.Audit logs and server-side data masking require an enterprise license key.
Retention controlRetention depends on plan and paid extension. Confirm the default period and extension pricing with LangChain.Retention is set by your own ClickHouse and storage configuration. Data retention policies are an enterprise license key feature.
Regional hostingCloud regions include GCP US, GCP EU, GCP APAC and AWS US. Data stays in the signup region while billing information stays in the US.Hosting region is wherever you deploy the stack, on your own cloud accounts or data centers.
Bulk data exportScheduled Parquet export to an S3-compatible bucket. For accounts signed up after August 3, 2026, it requires the Enterprise plan.Data lives in your own PostgreSQL, ClickHouse and blob storage, so export is a matter of querying your own stores. Confirm the export tooling you need.

Where data lives and who controls the stack

LangSmith and Langfuse differ most in where trace data sits and who operates the control plane. The four cards below cover LangSmith Cloud regions, self-hosted LangSmith on Kubernetes, self-hosted Langfuse, and the compliance evidence each choice produces.

LangSmith Cloud regions

LangSmith Cloud runs in GCP US (Iowa), GCP EU (Netherlands), GCP APAC (Sydney) and AWS US (Ohio). Trace data stays in the region where the account signed up, but billing information stays in the US. If you have an EU or APAC data residency requirement, confirm the signup region with LangChain before you send production traces, and ask in writing where any support access and billing records are held.

Self-hosted LangSmith on Kubernetes

Self-hosted LangSmith is an add-on to LangChain's Enterprise plan. It needs a license key and deploys to your own Kubernetes cluster with Helm charts, with Terraform also documented. Your team then owns the cluster, storage, upgrades and backups. Before you commit, confirm the license terms, the license check traffic and which infrastructure services LangChain expects you to provide.

Self-hosted Langfuse in your cloud

Self-hosted Langfuse runs on your own AWS, Azure, GCP or data center infrastructure. The core features are MIT licensed, and the self-hosted version uses the same codebase as Langfuse Cloud. Production runs on Kubernetes with Helm or Terraform, backed by PostgreSQL, ClickHouse, Redis or Valkey, and S3-compatible storage. Your team controls where every trace and prompt is stored and who can reach it.

Identity, audit and compliance evidence

Several governance controls sit behind an enterprise license key in self-hosted Langfuse, including project-level RBAC, data retention policies, audit logs and SCIM provisioning. Confirm which of these your assessment requires before you choose a deployment. DeployOpen can prepare the configuration, access records and evidence for your compliance assessment, but independent auditors issue any audit report or certification.

What each option costs to run, by component

With LangSmith Cloud, the recurring bill is set by the commercial plan you choose, and the cost drivers are the ones LangSmith meters: seats, trace volume and how long traces are kept. Your engineers still build and maintain the instrumentation in your applications, so that effort is internal rather than invoiced. No vendor price is stated here, so take the figures from LangSmith's current pricing and contract terms.

  • Per-seat charges: Each user who needs access to the workspace typically adds a recurring line item, so the count of reviewers, prompt editors and annotators drives the bill.
  • Per-trace charges: Trace volume scales with traffic, agent steps and evaluation runs, so high-volume workloads and verbose agent graphs raise the recurring cost.
  • Extended retention: Keeping traces longer than the base retention is a paid component, so retention policy is a direct cost lever.
  • Region and data handling: Choosing a region is a plan decision, and billing information stays in the US even for EU or APAC data, so confirm this against your residency requirements.
  • Internal effort: Instrumentation, evaluator upkeep and integration with your identity provider remain your team's work, with no one-time vendor setup fee included.

Ask the vendor for a written quote that separates seats, trace units, retention tiers and any enterprise add-ons, and model it against your expected monthly trace count.

What moving from LangSmith to Langfuse involves

The sequence moves traces, datasets and prompts out of LangSmith and into a self-hosted Langfuse project you control, with each phase closing on a check that the data and instrumentation match before you cut over.

  1. Inventory traces, datasets and prompts

    Your engineering lead and an analyst list what LangSmith holds for you: projects, trace volumes by project, datasets, prompt versions, online evaluators, annotation queues and the users who have access. Mark which items must move, which can be archived and which were only experiments. Confirm your LangSmith plan and whether your account falls under the bulk export rules for customers who signed up after August 3, 2026 (Enterprise only) or earlier Plus customers who keep access until February 1, 2027. Done when you have a written inventory signed off by the team that owns LLM features and by whoever owns data retention.

  2. Export trace data through bulk export

    An administrator with LangSmith access configures bulk export to an S3-compatible bucket, which writes trace data in Parquet format. Confirm with LangChain which export options your plan includes and whether long-running exports can time out on your volumes, and run a small test window first. Store the files in a bucket with access controls and retention you set. Done when a test export has landed, row counts for a sample window match the LangSmith UI, and someone other than the exporter has opened a file to check the columns. The Parquet files are your historical archive; the dedicated export sibling page covers mapping them onto a Langfuse project.

  3. Deploy self-hosted Langfuse and size ClickHouse

    Your platform team deploys Langfuse on infrastructure you control. Langfuse documents Docker Compose on a single VM for testing only, without high availability, and Kubernetes with Helm or Terraform for production. A production deployment runs Langfuse Web, Langfuse Worker, PostgreSQL, ClickHouse, Redis or Valkey, and S3-compatible storage. Size ClickHouse from your expected trace volume and retention, using Langfuse's scaling guidance for minimum resources, and plan disk headroom before any historical backfill. Done when the stack passes health checks, a test trace from a dev environment is visible in the UI, and the sizing decision is recorded with the volume assumptions behind it.

  4. Switch LangChain and LangGraph instrumentation

    Your developers change how applications send traces. Teams using LangChain or LangGraph typically replace LangSmith tracing environment settings and callbacks with Langfuse callbacks or an OpenTelemetry pipeline, depending on the Langfuse integration your stack supports. Keep one configuration switch per environment so you can route traces to either system during the overlap. Confirm the exact integration steps against the current Langfuse documentation for your framework versions. Done when staging traces show the same chain, tool and model spans as before, token and cost fields populate, and secrets for the Langfuse keys sit in your secrets store rather than in code.

  5. Rebuild evaluators, datasets and annotation queues

    Evaluation work does not come across automatically. Your ML or QA team recreates each LangSmith evaluator as a Langfuse LLM-as-a-judge evaluator, rebuilds datasets from the exported Parquet data or from curated examples, and sets up annotation queues for reviewers. Decide which judge models you will run, and confirm that any judge calls go to models you have approved for your data. Done when each evaluator that gated a release has an equivalent in Langfuse, the reference dataset scores match the LangSmith results on a sample of past runs, and the reviewers have logged into the annotation queue at least once. Where behavior differs, record the gap so it does not surprise anyone later.

  6. Move prompts and link versions to traces

    Prompt owners recreate prompt versions in Langfuse and assign deployment labels that match how your applications fetch them. Update the SDK calls so the application reads prompts from Langfuse and attaches the prompt version to each trace. Protected prompt labels and some governance features need an Enterprise license key, so decide before cutover which of those you need. Done when each production prompt resolves from Langfuse in staging, a trace shows the linked prompt version, and a rollback to a prior label has been tested.

  7. Run both systems in parallel

    For a defined period agreed by the project owner, applications send traces to both LangSmith and Langfuse. Compare volumes, latency added by instrumentation, error rates and evaluator scores on the same traffic, and check that dashboards and alerts built on the new data work. Track how many traces each system stores for the same requests. Done when the owners of tracing, evaluation and cost reporting have signed off that the Langfuse data is complete and the differences are explained.

  8. Cut over and set retention

    Switch production traffic to Langfuse, stop sending to LangSmith, and tell the teams who rely on the old UI where the new one lives. Set data retention in Langfuse to match your policy, since retention policies are an Enterprise license key feature in self-hosted Langfuse, and confirm that the LangSmith data you still need is archived in your bucket. Review access with SSO and roles according to your identity setup. Done when production traces appear only in Langfuse, retention settings are documented and tested, LangSmith access is reduced or removed on a schedule your security team approved, and the migration record is filed for audit evidence.

Questions buyers ask before choosing or hiring help

What does it cost to self-host Langfuse, and which components drive that cost?

Langfuse's core features and APIs are available in the MIT-licensed open source version without limits, so the software itself has no license fee. The recurring cost is infrastructure: two application containers, Langfuse Web and Langfuse Worker, plus PostgreSQL, ClickHouse, Redis or Valkey, and S3-compatible blob storage. The largest line item is usually ClickHouse, because its memory, disk and storage growth track trace volume and retention. Langfuse's scaling guide lists minimum resources of 2 CPU and 8 GiB for ClickHouse, with at least 16 GiB of memory for larger deployments. Ask any partner for a written quote that separates one-time setup, cloud hosting by component, storage growth at your retention period, upgrade effort and support. A paid Langfuse Enterprise key is optional and is priced by Langfuse, so request that figure from them directly.

How long does a self-hosted Langfuse rollout take?

The timeline depends on scope, not on the software. The main variables are how many applications you instrument, how many environments you need (test, staging and production), whether you need high availability, and which cloud or data center platform you run on. 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, so a production deployment has more moving parts than a trial. Migrating existing traces, datasets and prompts adds work that scales with data volume. Your team and a partner should agree on a timeline in writing as part of a fixed scope before work starts.

What does the work need from our platform and data teams?

Expect your platform team to own the Kubernetes or VM target, ingress, TLS, secrets, backups and monitoring of the stack, and your data team to own retention rules, data classification and access reviews. Langfuse depends on PostgreSQL, ClickHouse, Redis or Valkey and S3 or blob storage, so someone must operate or approve each of those services. Application teams must change tracing code to send data to the Langfuse endpoint. Identity integration (SSO, and SCIM where the Enterprise key applies) needs your identity team. Confirm these owners and their availability before the work starts, because most delays come from unassigned responsibilities rather than from the software.

Can an internal team run self-hosted Langfuse without a partner?

Yes, a capable platform team can deploy and run Langfuse without an outside partner, because the MIT-licensed core is the same codebase used by Langfuse Cloud and its documentation covers Docker Compose and Kubernetes paths. The harder question is whether that team has the capacity and skills for ClickHouse operations, backups, scaling worker containers on CPU load, and planned major upgrades. A partner can be useful for fixed-scope work such as the initial build, hardening, backup and restore testing, documentation and handover, or for a retainer that covers upgrades and support. DeployOpen plans, implements, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure. Weigh the decision against your team's current workload.

How do Langfuse upgrades work, and what does v3 to v4 require?

Updates within a major version are non-disruptive and apply database migrations automatically at startup. Major upgrades, such as v1 to v2, v2 to v3 or v3 to v4, follow dedicated migration guides and should be planned as projects. The v3 to v4 guide requires ClickHouse 25.12 or later, with 26.4 recommended, PostgreSQL 15 or later and Redis 7.0 or later. It moves to an observations-first ClickHouse data model, and it advises about 3x ClickHouse disk headroom when backfilling historic data, so check disk capacity before you start. Test the upgrade in a non-production environment with a copy of your data, and confirm the current version requirements in the upgrade guide, because they change.

Does self-hosting Langfuse remove the need for an enterprise contract?

For core tracing, evaluation and prompt management, yes. Langfuse states that all core features and APIs are available in the MIT-licensed open source version without limits, and self-hosted deployments use the same codebase as Langfuse Cloud. An enterprise license key is needed only for certain features in the ee directories, including project-level RBAC roles, protected prompt labels, data retention policies, audit logs, server-side data masking, UI customization, and the org management API with SCIM. If you need those controls, a key is required, and Langfuse's self-hosted pricing page lists a custom-priced Self-Hosted Enterprise plan with support. Check your RBAC, retention and SSO needs against the license key documentation before you assume the free tier covers them.

What should we ask a partner to confirm before signing?

Ask for a written scope listing the components, environments, integrations, migration of existing data and the acceptance tests that define done. Request a list of deliverables, such as deployment code, runbooks, backup and restore evidence, and handover sessions. Ask which upgrade and support arrangements are fixed-scope and which are retainers, and what response commitments, if any, are written into the contract. Confirm who holds the cloud accounts and keys, and that the deployment stays in your own infrastructure. For any compliance-related work, confirm that the partner prepares evidence for your auditor, because auditors and certification bodies issue the reports, not the partner.

Which Langfuse features do we need to check against our security policy?

Start with how users authenticate. Langfuse's authentication and SSO documentation describes the supported single sign-on options, and some identity controls sit behind the enterprise license key. Next, check data location, since a self-hosted deployment keeps traces in the PostgreSQL, ClickHouse and blob storage you choose. Then check retention, masking of sensitive fields and audit logging against your data classification. Confirm each control in the current documentation for your Langfuse version, and test it in a non-production environment before you rely on it.

How DeployOpen helps you choose, deploy and migrate

DeployOpen is a Chainscore Labs company that plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For LangSmith vs Langfuse, we help you decide whether Langfuse fits your requirements, then deploy and migrate it under a written scope.

How we scope

  • We start with your requirements for regions, retention, SSO, RBAC and whether an enterprise license key is acceptable.
  • We document which LangSmith features you use today, including tracing, datasets, evaluators and prompt management.
  • Engagements are fixed-scope, with deliverables and timelines agreed in writing before any work starts.
  • We confirm current plan terms and license conditions with each vendor and record the answers in the scope.

How we build

  • We deploy self-hosted Langfuse on Kubernetes with Helm or Terraform in your chosen cloud or data center.
  • We size PostgreSQL, ClickHouse, Redis or Valkey and S3-compatible storage against your expected trace volume.
  • We wire LangChain and LangGraph callbacks or OpenTelemetry instrumentation into your applications and test the traces.
  • We configure SSO, access roles and data retention settings, and test them against your access policies.

How we hand over

  • We deliver architecture diagrams, runbooks, configuration records and upgrade procedures for your own team.
  • For migrations, we document how exported LangSmith data maps onto your Langfuse projects and where gaps remain.
  • We walk your engineers through rebuilding evaluators, datasets and prompt labels, with a record of what changed.
  • We provide evidence and control documentation for your compliance team, while auditors and certification bodies issue any formal opinion.

How we support

  • Ongoing support, upgrades and continuous testing are available as retainers after handover.
  • Upgrades between major versions follow the vendor's migration guides, and we plan them into a written scope.
  • Security testing of your LLM applications and their tracing pipeline can be scoped separately.
  • Ask us to confirm which support tier, including any vendor enterprise plan, your team needs before signing.

Sources and further reading

Talk to our team.

Tell us what you're working on, whether it's a deployment, an audit, a security test or a cyber range. You'll speak with an engineer who can help you scope it.

  • 30-minute call: free, with no obligation.
  • NDA on request: we can sign before you share details.
  • Clear next steps: a scope and plan after the call.