Langfuse vs LangSmith: when to choose each
Choose Langfuse when your team must keep prompts, traces and evaluation data inside its own network and wants to run the tool without buying a commercial tier first. Langfuse is open core: code outside its ee directories is MIT licensed, and the self-hosting documentation describes a web and worker container backed by PostgreSQL, ClickHouse, Redis or Valkey and S3-compatible blob storage. Choose LangSmith when your organization already plans to buy LangChain's Enterprise plan, because LangChain documents self-hosted LangSmith as an add-on to that plan, running in your Kubernetes cluster with ClickHouse, PostgreSQL and Redis. The decision turns on four questions: the license terms your legal team will accept, whether Enterprise pricing is already in budget, which residency rules apply to trace content, and whether your staff can operate ClickHouse and PostgreSQL.
Start with licensing, because it decides whether a self-hosted deployment is possible at all. For Langfuse, confirm which features in your plan need a license key, since the self-hosting documentation says some add-on features require one. For LangSmith, ask LangChain in writing what the Enterprise add-on includes, what it costs, and how the self-hosted build is updated. Residency rules are the second filter: if prompts or outputs contain personal or regulated data, map where traces are stored in each option and who can read them, including support access. Keep in mind that DeployOpen prepares these controls and evidence for your assessors but does not issue the attestations themselves.
The third filter is operating skill. Both designs depend on ClickHouse for trace data and PostgreSQL for transactional records, so the team that carries the pager needs backup, restore, upgrade and capacity routines for both databases. If that skill sits in your platform group, a self-hosted Langfuse deployment is a realistic option to pilot in a non-production environment first. If it does not, ask whether a fixed-scope implementation with documented runbooks and a retainer for upgrades would close the gap, and get the scope, deliverables and timeline in writing before you compare costs.
Which team should pick Langfuse or LangSmith
This table maps common team situations to the platform that fits them better, along with the condition that makes each choice hold. Read each row against who will operate ClickHouse and PostgreSQL, because that operating model often decides the answer more than features do.
| Scenario | Better fit | Condition that makes it so |
|---|---|---|
| Regulated team with strict residency rules and no appetite for a commercial add-on | Langfuse | Self-hosted Langfuse is open core, with code outside its ee directories under MIT, so you can run the core stack in your own infrastructure without buying an Enterprise add-on. Confirm which features you need sit outside the commercial license and whether any require a license key. |
| Team already standardized on LangChain that wants a vendor-supported path | LangSmith | Self-hosted LangSmith is documented as an add-on to the Enterprise plan, running in your Kubernetes cluster. This fits when your team values vendor support and an integrated LangChain workflow enough to accept a commercial contract. Confirm the support terms and cost in writing. |
| Platform team wanting one observability layer across several model gateways | Langfuse | Langfuse is a standalone observability service that you run once and point at multiple gateways. Confirm that your gateways and frameworks send traces in a supported way, since the value depends on integration effort, not on the product alone. |
| Small team that wants to self-host without a procurement cycle | Langfuse | The MIT-licensed core lets a small team start without a commercial agreement. The trade-off is that you own the upgrades and the ClickHouse and PostgreSQL operations, so this holds only if someone on the team can run those services. |
| Organization where no one has run ClickHouse in production | LangSmith | Self-hosted LangSmith is delivered as a commercial package that the vendor documents, which can reduce design work for the first deployment. Ask the vendor who maintains ClickHouse, backups and upgrades after go-live, because that effort does not go away. |
| Team with an existing PostgreSQL platform team and limited ClickHouse skills | Depends on the operating model | Langfuse needs ClickHouse, PostgreSQL, Redis or Valkey and S3-compatible storage, and LangSmith uses ClickHouse, PostgreSQL and Redis. Both place ClickHouse on your side, so the choice rests on licensing and support, not on avoiding that dependency. |
| Organization that must document every third-party component and its license | Langfuse | The license split is defined in the repository's LICENSE file, which gives assessors a concrete text to review. Confirm with counsel which directories your deployment uses and whether any commercial feature is in scope. |
What a self-hosted Langfuse stack runs and what LangSmith adds
A self-hosted Langfuse deployment is a small set of stateful services you run yourself, while self-hosted LangSmith is a Kubernetes deployment inside your cluster as an Enterprise add-on. The cards below cover each component, what it holds, and what it means for backups, upgrades and on-call work.
Langfuse web and worker containers
Langfuse runs as a web container that serves the UI and API and a worker container that processes background jobs. Both must be deployed, scaled and upgraded together, so a version mismatch between them is an operational risk. Ask the vendor or your own tests which upgrade order the release notes require. Plan on-call coverage for both containers, since a healthy web tier does not prove that trace ingestion is being processed.
PostgreSQL for transactional data
PostgreSQL holds the transactional records that Langfuse needs for projects, users and configuration. It is the component most teams already know how to back up and restore, which makes it the easiest part of the stack to fold into existing database operations. Confirm whether your standard database backup covers it, and test a restore alongside the ClickHouse restore so both stores return to a consistent point.
ClickHouse for trace volume
ClickHouse is the analytical store for high-volume trace and observation data. Its footprint grows with the number of traces you keep, so retention settings and capacity planning drive most of the storage decisions. Treat it as a separate service with its own backup, upgrade and monitoring plan, and ask your team whether it has operators who can own it before go-live.
Redis or Valkey for queues
Redis or Valkey handles queueing and caching between the web and worker tiers. Its data is usually transient, so the main operational question is availability rather than backup. Confirm how a queue outage affects trace ingestion and whether your platform team already runs a supported instance you can point the stack at.
S3-compatible blob storage
Object storage holds the blob data that Langfuse writes outside the databases. Because it sits outside the databases, it needs its own retention, lifecycle and access policy, and it must be included in disaster recovery scope. Confirm which bucket policies, encryption settings and residency controls your storage provider offers, since these decide whether data stays inside the region your rules require.
LangSmith self-hosted in your cluster
Self-hosted LangSmith runs in your Kubernetes cluster as an add-on to the Enterprise plan, using ClickHouse for traces, PostgreSQL for transactional data and Redis for queues and caching. The same stores appear, but the licensing path is commercial, so the add-on terms and your residency rules must be settled before you design around it. Ask LangChain to confirm the exact supported versions, upgrade path and support model in writing.
Langfuse vs LangSmith on the features that matter in production
This table compares how each platform is licensed, where it can run, which data stores it needs and how its add-on features are gated. Read the rows as a checklist: where a row shows a confirmed fact, use it, and where it says to confirm, put that question to the vendor before you choose.
| Capability | Langfuse | LangSmith |
|---|---|---|
| License model | Open core: code outside its ee directories is MIT, code inside them is under a commercial license | Commercial LangChain product; the self-hosted option is an add-on to the Enterprise plan |
| Self-hosting availability | Self-hosted deployment is documented and does not require an Enterprise contract for the core stack | Self-hosted LangSmith is documented as an add-on to the Enterprise plan, so confirm the contract scope first |
| Required data stores | Web and worker containers backed by PostgreSQL, ClickHouse, Redis or Valkey, and S3-compatible blob storage | ClickHouse for traces, PostgreSQL for transactional data and Redis for queues and caching |
| Add-on features gated by a license key | Some add-on features require a license key, so check which features your use case depends on | Confirm with LangChain which features sit inside the Enterprise add-on and which are included elsewhere |
| Deployment target | Runs in infrastructure you operate, so the target depends on your own cluster or host setup | Runs in the customer's Kubernetes cluster |
| Release cadence visible in facts | Latest tagged release v4.63.0 published October 16, 2026 on GitHub | Confirm the release cadence and version policy for self-hosted builds with LangChain |
| Data residency fit | Data stays in the stores you provision, so residency depends on where you place them | Data stays in your cluster, but confirm the residency terms and support access model in the contract |
Langfuse vs LangSmith licensing and editions
Langfuse is open core. Code outside its ee directories is licensed under the MIT License, and code inside those directories sits under a separate commercial license. The Langfuse LICENSE file is the document to read for the exact boundary, and it should be checked path by path because the split follows directories.
- Core license: the MIT portion covers the broad base of the product, which your team can use, modify and redistribute under MIT terms.
- Commercial directories: code inside the ee directories requires the commercial license, so any feature you enable from those paths needs a separate grant.
- License keys: the self-hosting documentation states that some add-on features require a license key, so confirm which features you plan to use before assuming the MIT core covers them.
- Infrastructure you pay for: you run the web and worker containers, PostgreSQL, ClickHouse, Redis or Valkey and S3-compatible blob storage, so those costs sit with your infrastructure budget.
Ask Langfuse what each license key covers, whether it is billed annually or per deployment, and what support and upgrade rights are included, all in writing.
LangSmith is a commercial LangChain product. LangChain documents self-hosted LangSmith as an add-on to its Enterprise plan, so access to the self-hosted build comes through the commercial contract and not through an open-source license. The LangSmith self-hosted documentation describes the deployment model, which runs inside your Kubernetes cluster.
- Commercial terms: the platform is governed by LangChain's commercial terms, and the public documentation does not describe an open-source license for the platform itself.
- Enterprise entitlement: self-hosting is an add-on, so the order form and contract should name it explicitly and state the versions you may run.
- Deployed components: the cluster runs ClickHouse for traces, PostgreSQL for transactional data and Redis for queues and caching, and your team operates all three.
- Paid components: the Enterprise plan, the self-hosted add-on, vendor support and the infrastructure you run. Ask whether pricing is based on seats, deployments, trace volume or a flat fee.
- Upgrades and lapse terms: ask how upgrades are delivered, whether they are included, and what happens to a running deployment if the contract ends.
Request the order form and the self-hosted terms in writing before any evaluation turns into a purchase.
With either product self-hosted, traces and prompts are stored in databases you operate, so residency depends mainly on where you run the clusters and storage. License terms then decide what your staff and partners may copy, modify and share. This matters most for regulated teams that must show where data lives and who can change the software that handles it.
- Data location: confirm whether either deployment needs outbound connectivity for license validation, entitlement checks or telemetry, and how renewals work on a network with no internet access.
- Internal copies: MIT lets you copy and modify the Langfuse core inside the organization, while LangSmith copies and modifications are governed by the contract.
- Implementation partners: if an implementation partner such as DeployOpen installs, customizes or operates the stack, check whether the license and contract allow that party to access and change the code on your behalf.
- Evidence for assessors: keep the license files, contract, order form and version records in your compliance file, since assessors will ask what you run and under which terms.
- Ownership of changes: agree in writing who owns patches made to the commercial directories or contract components, and whether those changes survive upgrades.
Confirm current license and contract terms with each vendor in writing before purchase, because terms change and this section does not replace the vendor's documents or your legal review.
What drives the running cost of Langfuse and LangSmith
The running cost of self-hosted Langfuse is mostly infrastructure and operator time, while the running cost of self-hosted LangSmith adds a commercial Enterprise plan on top of the same kind of infrastructure. Langfuse runs a web and a worker container backed by PostgreSQL, ClickHouse, Redis or Valkey and S3-compatible blob storage, according to the Langfuse self-hosting documentation. You pay your cloud provider or data center for those components, and you pay your own staff to size, patch and back them up. LangSmith's self-hosted option runs in your Kubernetes cluster and uses ClickHouse, PostgreSQL and Redis, so you carry the same data stores plus cluster capacity, and you also pay LangChain for the Enterprise plan that the add-on requires. Confirm in writing whether the add-on fee is annual, usage-based or both, and whether it covers upgrades and support.
Setup costs are one-time and recurring costs are not. Setup covers sizing ClickHouse and PostgreSQL, wiring object storage and secrets, and proving backup and restore for each store. Recurring costs include storage growth for traces, compute for the worker and query paths, version upgrades that touch several stores at once, and on-call coverage. Trace volume, retention windows, the number of environments and the frequency of upgrades are the main drivers in both products. For Langfuse, add-on features that need a license key are a cost line of their own, so confirm which features your team needs before you size the deployment. Skills matter as much as hardware: a team that already runs ClickHouse and Kubernetes will carry less risk than one learning both on a production trace store. Ask DeployOpen or any integrator to scope that learning curve explicitly.
Ask for the same line items from every bidder so the comparison is fair. A written quote should list infrastructure by component (ClickHouse, PostgreSQL, Redis or Valkey, blob storage, Kubernetes nodes where relevant), the license or Enterprise plan fee and its renewal terms, the support tier and response commitments, the upgrade and patching responsibilities, backup and restore testing, and the handover of runbooks. Ask LangChain to state in writing what its Enterprise plan covers for the self-hosted add-on and whether data residency commitments change the price. Ask DeployOpen to state what is fixed in scope, what is a retainer and what triggers a change order, since most engagements are fixed-scope and agreed in writing before work starts. No figure in this section is a quote, so treat every number you receive as something to verify.
Switching between Langfuse and LangSmith later
This sequence moves trace history, prompts, datasets and dashboards from one platform to the other while keeping both running during cutover and keeping trace data in the region your rules require. The result is a documented migration with a validated residency position at each stage.
Inventory what each platform holds
Before moving anything, list the trace stores, prompt versions, evaluation datasets, annotation queues, dashboards, alerts and API keys in the current platform, and note which team owns each one. Mark each item as portable data, configuration to recreate or code that calls the platform's SDK. Confirm with the current vendor which export formats and APIs cover each category, and with your own engineers which instrumented services would need SDK changes. The output is a signed-off inventory that shows what transfers cleanly and what must be rebuilt.
Confirm export paths and residency with each vendor
Ask LangChain whether the self-hosted LangSmith deployment in your Kubernetes cluster offers bulk export of traces and datasets, and what format it uses. For Langfuse, check the self-hosting documentation and confirm which data sits in PostgreSQL, ClickHouse and the S3-compatible blob store, since those are the locations you must export from and validate. Record which features depend on a license key or the Enterprise add-on, because those may not be available on the other side. The output is a written confirmation per vendor of export methods, data locations and licensing conditions.
Map data residency for every store
Document where each category of data lives in the source and target deployments, including regions, cluster locations, backups and any managed services. Include the ClickHouse, PostgreSQL, Redis or Valkey and blob storage used by each platform, and note any traffic that leaves your boundary, such as telemetry or license checks. Have your compliance lead approve the map before any copy begins. The output is a residency map that a reviewer can check against your policy, with each open question assigned an owner.
Build the target environment and rebuild configuration
Stand up the target platform in your own infrastructure, following its self-hosting guide, and recreate projects, access roles, prompt structures and dashboards that the export does not carry over. Keep the new environment isolated from production traffic until validation starts. Record every manual rebuild step so the work can be repeated in later environments. The output is a running target instance with a checklist of rebuilt configuration signed off by the platform owner.
Run both platforms in parallel
Configure instrumented services to send traces to the source platform and, for a defined set of services, to the target as well, so that both receive live data. Compare trace counts, latency metrics, evaluation scores and alert behavior between the two for the same workloads. Keep the source as the system of record until the comparison is clean. The output is a parallel-run report that shows where the two platforms agree and where they differ, with each difference explained.
Migrate history and validate residency at each step
Export historical traces, prompts and datasets in batches, load them into the target, and check record counts and sample contents against the source. After every batch, re-run the residency map to confirm that the new copies sit only in approved regions and clusters and that no intermediate export file was left in an unapproved location. Delete temporary exports under your retention rules. The output is a batch log with reconciliation results and a residency check recorded for each batch.
Cut over and retire the source
Switch the remaining services' trace endpoints and keys to the target, update dashboards and alert routing, and confirm that new data arrives as expected. Keep read-only access to the source for an agreed period so teams can check historical records. When the retention and audit requirements are met, decommission the source, its backups and its keys according to your data disposal procedure. The output is a decommissioning record showing that the source is no longer receiving data and that its stores were removed or retained as approved.
Implementing Langfuse or LangSmith in your own infrastructure
The main difference in rollout is where the work sits. A self-hosted Langfuse deployment runs a web and a worker container backed by PostgreSQL, ClickHouse, Redis or Valkey and S3-compatible blob storage, according to the Langfuse self-hosting documentation. Self-hosted LangSmith is sold as an add-on to the Enterprise plan and runs in your Kubernetes cluster, using ClickHouse for traces, PostgreSQL for transactional data and Redis for queues and caching, per the LangSmith self-hosted documentation. Both stacks need the same data store categories, so sizing work is similar: estimate trace volume, retention and concurrent ingestion, then provision ClickHouse, PostgreSQL, the cache and object storage with backup and encryption settings your data classification requires. Ask each vendor for its current sizing guidance and minimum resource figures in writing, because the documentation you rely on will be the basis for your capacity plan.
Plan network and identity before instrumentation. Decide whether the observability endpoint sits on a private subnet reachable only from application workloads, how TLS terminates, and which egress paths the workers need. For SSO, confirm which login methods each edition supports for your identity provider and whether group-to-role mapping is available in the tier you buy. Key management is a frequent source of delay: database credentials, the Langfuse license key where add-on features need one, encryption keys for object storage, and API keys issued to each application must have owners, rotation rules and a recovery path. Instrumentation is usually the quickest part, but teams often underestimate how many services emit traces and how much prompt content they capture by default. Agree a redaction policy first.
Operations and evidence are where projects run long. ClickHouse is the component most likely to need specialist time: schema and table management, merge behavior under load, storage growth and restore testing. Write a backup and restore runbook for every stateful store, rehearse a restore into a separate environment, and record the results. Upgrades need a staging path, because self-hosted releases change schema and containers together. For assessment readiness, collect configuration baselines, access reviews, logging settings, backup test records and change history, and map them to the controls your auditor will sample. DeployOpen plans, implements, hardens, backs up and documents these self-hosted systems inside your own cloud account, data center or air-gapped network under a written, fixed scope. DeployOpen does not issue audit reports or certifications, so independent assessors remain responsible for those conclusions.
Langfuse vs LangSmith questions buyers ask before hiring help
Can I self-host Langfuse for free?
Largely yes, but the license and the infrastructure decide the answer. Langfuse is open core: code outside its ee directories is MIT licensed, while code inside those directories sits under a commercial license, according to its LICENSE file. Some add-on features require a license key, so confirm with Langfuse which features your team needs before you assume the free path covers them. Your costs then shift to the infrastructure you run: a web and a worker container backed by PostgreSQL, ClickHouse, Redis or Valkey, and S3-compatible blob storage, per the self-hosting documentation. Ask your team to size that footprint against expected trace volume.
What does self-hosting LangSmith require?
Self-hosted LangSmith is an add-on to the Enterprise plan, so the first requirement is a commercial agreement with LangChain. According to LangChain's documentation, it runs in your Kubernetes cluster and uses ClickHouse for traces, PostgreSQL for transactional data and Redis for queues and caching. Your team owns the cluster, backups, upgrades and network controls, and the license terms set what you may run and for how long. Ask LangChain in writing for the current Enterprise terms, the supported Kubernetes versions and the exact components you must operate.
How long does a self-hosted observability rollout take?
No duration is published for either platform, so treat any number you see online as unverified. The timeline depends on the number of applications instrumented, whether you already run ClickHouse and PostgreSQL, how your identity and network controls are set up, and how much retention and evidence work your compliance team requires. Fixed-scope work starts with a written scope, deliverables and timeline agreed before any work begins. Ask for a phased plan that separates a pilot on one application from production rollout and retention configuration.
What does the work need from our in-house team?
Your engineers need to own the application side: adding trace instrumentation, agreeing on what prompts and outputs may be captured, and reviewing dashboards. Your platform team needs to run the data stores, since Langfuse expects PostgreSQL, ClickHouse, Redis or Valkey and object storage, and LangSmith's self-hosted path adds Kubernetes operations. Your security team needs to approve data flows and access roles. Ask DeployOpen to define which of these responsibilities it covers under a fixed scope and which stay with your staff after handover.
Can one person run a self-hosted Langfuse or LangSmith deployment?
One skilled engineer can operate a small Langfuse pilot, but a production deployment is rarely a one-person job. Running it means backups for PostgreSQL and ClickHouse, patching containers or cluster components, monitoring disk and queue health, and handling on-call incidents when traces stop arriving. Coverage matters more than headcount: you need at least two people who can restore the stack and rotate credentials. Ask for a written runbook, an upgrade plan tied to each release, and a clear list of tasks that a retainer would cover if you choose ongoing support.
How do data residency rules change the choice?
Residency rules often decide the deployment model before features do. Self-hosting Langfuse keeps trace data in the infrastructure you choose, whether that is your cloud account, a data center or an air-gapped network, provided you configure every data store there. LangSmith's self-hosted option also runs in your cluster, but it is only available as an Enterprise add-on, so the contract and the license scope become part of your residency review. Ask both vendors to confirm where each component stores data, which telemetry leaves your network and what the license permits, then have your compliance lead record those answers.
What does a fixed-scope engagement cover, and what does it cost?
DeployOpen plans, implements, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts, and DeployOpen does not publish a price list, so a quote follows from that written scope. Cost is driven by the number of environments, the data stores to operate, integration with your identity provider, testing and documentation depth, and whether you want ongoing support or retainers. DeployOpen does not issue audit reports or certifications, so ask how it will prepare evidence for your assessor.
How DeployOpen helps choose and run your observability stack
DeployOpen plans, implements, hardens and documents self-hosted platforms inside your own cloud accounts, data centers or air-gapped networks. For LLM observability, that means helping you decide whether a self-hosted Langfuse deployment or a self-hosted LangSmith Enterprise add-on fits your residency rules, staffing and budget, then building whichever you choose.
How we scope
- Agree the written scope for Langfuse vs LangSmith before any work starts, covering target environment and data residency boundaries.
- Confirm which trace volumes, retention periods and users the deployment must serve, and which teams own each piece.
- Establish whether licensing questions, such as Langfuse license keys or the LangSmith Enterprise plan, are in scope or handled by your team.
How we build
- Deploy the chosen stack with its supporting services, such as PostgreSQL, ClickHouse, Redis or Valkey and blob storage, inside your network.
- Configure authentication, network access, secrets handling and backups to match your internal security standards.
- Test trace ingestion, access controls and failure recovery against the agreed acceptance criteria before handover.
How we hand over
- Document the architecture, component versions, configuration and operating runbooks for your platform and security teams.
- Walk through upgrade paths, backup and restore steps, and the licensing obligations that apply to your edition.
- Deliver written evidence of controls that your compliance team and independent auditors can review, without us issuing any attestation.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer, sized to the written scope of your deployment.
- Plan version upgrades against the release notes of the chosen platform and re-test affected integrations before rollout.
- Revisit the Langfuse vs LangSmith decision if residency rules, trace volumes or licensing terms change over time.
