Open-source alternatives to LangSmith

Which open-source alternative to LangSmith fits your team

If you are facing a LangSmith renewal, a self-hosting requirement or a data residency or lock-in concern, the two main self-hosted replacements for tracing, evaluation and prompt management are Langfuse and Opik. LiteLLM or Portkey's AI Gateway only cover the gateway layer, so they complement a tracing platform rather than replacing one.

The trigger for many teams is licensing and plan scope. 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. Bulk export of trace data to Parquet in an S3-compatible bucket is only available on the Enterprise plan for customers who signed up after August 3, 2026, while earlier Plus customers keep access until February 1, 2027. Confirm your signup date, your current plan and the export terms in writing with LangChain before you plan around either date, since your contract governs what you can use.

Choose between the two replacements by what you run in production. Langfuse is open core: code outside its ee directories is MIT licensed, and some advanced features need an enterprise license key, so check which features your team depends on against the Langfuse self-hosting documentation. Its stack includes PostgreSQL, ClickHouse, Redis or Valkey, and S3 or blob storage, which means your platform team owns those databases. Opik is Apache-2.0 licensed and its README states the full platform, including tracing, evaluations and prompt management, can be self-hosted without a commercial license, so a legal review may be shorter. Run a pilot on your own traces and confirm the operational components and data residency requirements before committing.

Langfuse and Opik as self-hosted LangSmith replacements

Langfuse and Opik both cover tracing, evaluation and prompt management, and both can run in your own infrastructure. They differ mainly in licensing model and in the operational footprint you take on, so the choice depends on which license terms and components your security and platform teams can accept. LiteLLM sits alongside either one as an optional gateway.

Langfuse under open-core licensing

Langfuse is open core. Code outside its ee directories is MIT licensed, while code inside them falls under a separate commercial license, and some advanced features need an enterprise license key. Before committing, have legal review which features your team needs and whether they sit behind that key. Self-hosting for testing uses Docker Compose, and production deployments use Kubernetes with Helm. The trade-off is a broader feature set in exchange for reading the license boundary carefully.

Langfuse data stack dependencies

A self-hosted Langfuse deployment depends on PostgreSQL, ClickHouse, Redis or Valkey, and S3 or blob storage. Each one needs backup, patching, sizing and access control under your own operating model. Ask your platform team who will own each component, how ClickHouse is scaled and restored, and how storage is encrypted and retained. The trade-off is more moving parts than a single managed service, in exchange for full control of where trace data lives.

Opik under Apache-2.0

Opik, built by Comet, is licensed under Apache-2.0. Its README states that the full platform, including the server backend, web application, tracing, evaluations and prompt management, can be self-hosted without a commercial license. Confirm that the release you deploy matches the repository you reviewed, and check the open-source boundary against your requirements. The trade-off is a permissive license with fewer license conditions to track, paired with the need to validate feature coverage against your LangSmith workflows.

LiteLLM as a gateway complement

LiteLLM is an optional self-hosted gateway that exposes one OpenAI-compatible endpoint across many providers, with virtual keys, budgets, fallbacks and logging to Langfuse. It handles routing and spend control rather than trace analysis, so it complements either tracing platform. Its MIT license excludes the enterprise directory, which adds SSO, SAML and audit logs. Confirm which of those controls you need before you assume the open-source edition covers them.

How each LangSmith capability maps to open-source options

This table maps each main LangSmith capability to Langfuse, Opik and LiteLLM, with a coverage note for every row. Read the coverage column first, because gaps and partial matches determine how much of your current workflow needs rebuilding. Confirm specific feature parity against each project's current documentation before you commit to a migration plan.

Capability	Open-source options	Coverage note
Tracing of LLM and agent runs	Langfuse and Opik both capture nested traces, inputs, outputs and metadata. LiteLLM can forward gateway logs to Langfuse or OpenTelemetry.	Broadly covered. Confirm how each tool handles your LangGraph multi-step graphs and streaming output in its current docs.
Evaluation datasets and experiments	Langfuse and Opik provide datasets and experiment runs for comparing prompt or model versions.	Partial. Confirm dataset import, scoring and experiment comparison features match your existing LangSmith evaluation workflow.
Prompt management and versioning	Langfuse offers prompt versioning and a prompt registry. Opik includes prompt management in its self-hosted platform.	Partial. Check labels, rollback behavior and SDK support for your prompt templates before assuming parity.
Online monitoring and alerting	Langfuse and Opik support dashboards and production trace review. Alerting usually depends on your own Prometheus, Grafana or Datadog setup.	Gap to verify. Confirm which alerting features ship in each project and plan external alerting if they do not.
Human feedback and annotation	Langfuse provides annotation queues and scoring. Opik supports feedback scores on traces.	Partial. Confirm reviewer roles, queue workflows and export options against your annotation process.
LangChain and LangGraph instrumentation	Langfuse has LangChain callback integration. Opik has LangChain tracing support. Both can also use OpenTelemetry-based paths.	Requires code changes. Replace the LangSmith tracing configuration and test graph runs in a staging environment.
Gateway routing, virtual keys and budgets	LiteLLM provides one OpenAI-compatible endpoint, virtual keys, budgets, rate limits and fallbacks, and is MIT licensed outside its enterprise directory.	Not a LangSmith feature. Adds coverage for model routing that LangSmith does not provide, so treat it as an optional addition.
SSO, audit logs and multi-team management	LiteLLM Enterprise and the enterprise directories of Langfuse cover these areas under separate licenses.	Gap in open-source tiers. Confirm which of these controls you need and whether they require a commercial license key.

What you give up when you leave LangSmith and the usual workarounds

Moving off LangSmith trades vendor-run operations and managed services for responsibilities your team or a partner must carry. The cards below cover where the gaps usually appear, what each workaround looks like, and what to confirm with each open-source option before you commit.

Vendor-managed upgrades and hosting

LangSmith Cloud is operated by LangChain, so upgrades, scaling and availability work happen on its side. Self-hosting moves that work to you: you own Kubernetes capacity, Helm chart upgrades, database maintenance and incident response. Langfuse self-hosting depends on PostgreSQL, ClickHouse, Redis or Valkey, and S3 or blob storage, so each of those components needs an owner. Before you start, confirm which upgrade path and release cadence each platform documents, and who on your side will run them.

LangChain-native hub integrations

Teams that rely on LangSmith's prompt hub, playground and tight LangChain and LangGraph integration may find some workflows need rework. Langfuse and Opik accept traces through their own SDKs and standard instrumentation, so the work is mostly in how prompts are versioned and where they are fetched at runtime. Inventory every place your code pulls prompts or datasets from the hub, then test each one against the replacement before cutover.

Data residency across regions

LangSmith Cloud keeps data in the region where the account signed up, across GCP US (Iowa), GCP EU (Netherlands), GCP APAC (Sydney) and AWS US (Ohio), while billing information stays in the US. Self-hosting lets you pick the region and cloud account yourself, but you must then design multi-region replication, backups and failover. Confirm where your trace data will reside, where backups are stored, and whether any vendor support access touches production data.

Enterprise SSO and audit features

Some enterprise controls may sit behind a license key in open-core products. Langfuse states that advanced features need an enterprise license key, and self-hosted LangSmith requires an Enterprise plan with a license key. A self-hosted identity integration, such as your existing identity provider in front of the application, can cover login, while audit logging may need your own collection pipeline. Confirm which SSO, role and audit features are in the community edition and which need a commercial license.

Trace retention and bulk export

LangSmith bulk export writes trace data to an S3-compatible bucket in Parquet format, and for customers who signed up after August 3, 2026, it is only available on the Enterprise plan. Earlier Plus customers keep access until February 1, 2027. Before you leave, run a documented export and retention runbook that covers schema, retention periods and deletion, and test a restore into your new platform. Ask LangChain for the export format specification and confirm what your plan entitles you to.

Support contracts and response

LangSmith's commercial support comes with the vendor relationship, including Enterprise plan terms. Open-source projects rely on community channels and maintainer responsiveness, and self-hosted platforms have no vendor on the hook for your incident. A fixed-scope implementation or a retainer can add operational support, upgrades and testing on your environment. Ask each candidate for its documented support channels, any commercial support it offers, and the response commitments in writing before relying on them.

How the self-hosted Langfuse or Opik stack fits your VPC

The core decision is where each component runs. Both Langfuse and Opik are self-hosted, so the whole tracing stack lands in your own infrastructure, and data residency is set by the cluster and storage locations you choose, not by the vendor. Application services that call LLMs are instrumented with LangChain or LangGraph callbacks, or with OpenTelemetry where the workload is not built on LangChain. Those services send trace data to the tracing server, which runs inside a private subnet with no inbound exposure beyond your internal load balancer or ingress. Langfuse documents Kubernetes with Helm for production and Docker Compose for testing, and Opik publishes its own deployment guides, so confirm the exact service list against the current Langfuse self-hosting documentation and the Opik repository before you size anything.

Behind the tracing server sit the data services. Langfuse depends on PostgreSQL for transactional data, ClickHouse for trace analytics, Redis or Valkey for queueing and caching, and S3 or blob storage for event and media payloads. Each of these is a stateful service with its own backup, patching, encryption and access controls, and each needs an owner in your platform team. Confirm how Opik distributes its storage and analytics roles, because the component mix affects which managed database services you can reuse and which you must run yourself. If you plan to route model traffic through a gateway such as LiteLLM, place it between your applications and the LLM providers, so it can write logs to the tracing server while enforcing keys, budgets and rate limits. Ask your architects to document the network egress rules for each provider, since the gateway, not the tracing server, is the component that calls external model endpoints.

Before you approve the design, run three checks with your security and platform teams. First, confirm that the storage buckets, databases and cache all sit in the region and account your data policy requires, and that backups stay there too. Second, confirm which Langfuse features need an enterprise license key, since the self-hosting documentation says some advanced features do, and which controls you need for SSO, audit logging and role separation. Third, decide who may read traces that contain prompts and user content, because the tracing store will hold that material. Treat the topology above as a starting point and verify it with the vendor's current deployment documentation during the design phase.

How to migrate LangSmith traces, prompts and instrumentation

This sequence moves LangSmith projects, prompts and LangChain or LangGraph instrumentation onto a self-hosted platform such as Langfuse or Opik while keeping historical traces available and the old system retired only after its data is checked. Each step names the output that lets the next one start.

Inventory projects, datasets, prompts and call sites
Your engineers list every LangSmith project, dataset, prompt and evaluator in use, then find each LangChain or LangGraph call site that sends traces, including tracing settings applied through environment variables and code. Record which services, owners and environments depend on each project, and note which projects hold data your compliance team must retain. The output is a single inventory sheet with one row per project and one row per call site, reviewed by the service owners who will sign off on the pilot.
Confirm your export entitlement early
Your administrator confirms with LangChain whether your account can use bulk export. The researched facts say bulk export writes trace data to an S3-compatible bucket in Parquet format, and that for customers who signed up after August 3, 2026 it is only available on the Enterprise plan, while earlier Plus customers keep access until February 1, 2027. Confirm your sign-up date and plan in writing, and ask for the export terms that apply to your account. The output is a written answer that determines whether your historical traces are exported in bulk or pulled through the API.
Export traces to S3-compatible Parquet
Where your plan allows it, your platform engineers configure bulk export to an S3-compatible bucket that you control, using the bucket settings and access policies your security team approved. Confirm the bucket is encrypted, access is limited to the team that will load the data, and retention rules match your policy. Run the export for one project first and check that row counts and time ranges match what LangSmith shows. The output is a verified Parquet dataset per project stored in your bucket.
Map trace fields and prompt versions
Your data engineers write a mapping from LangSmith run fields (inputs, outputs, run type, parent and child runs, token usage, latency, metadata and tags) to the trace model of the target platform, and decide how prompt versions and their labels move across. Langfuse and Opik use different schemas, so expect some fields to need transformation and some to have no direct equivalent. Keep the original project name and run identifiers in metadata so every migrated trace can be traced back to its source. The output is a reviewed mapping document and a load script that a sample of traces passes end to end.
Run a pilot on one service
Choose one service with moderate traffic and low regulatory exposure, then instrument it for the new platform while keeping LangSmith tracing active. Your engineers add the target platform's LangChain or LangGraph callback handler or OpenTelemetry exporter, and the service owner reviews a set of traces for completeness, prompt linkage and error capture. Confirm that sensitive fields are redacted before storage if your policy requires it. The output is a signed-off pilot report listing what was captured, what is missing and what the team changed.
Compare traces in a parallel run
For a fixed observation window agreed with the service owner, both platforms receive traces from the same requests. Your team compares trace counts, span hierarchy, token and cost fields, latency values and evaluation scores between the two systems, and records every mismatch with its cause. Repeat the comparison for error paths and for any tools or retrieval steps the service uses. The output is a discrepancy log with each item resolved, accepted or scheduled for a fix before cutover.
Cut over instrumentation through environment configuration
Your platform team switches each remaining service to the new platform by changing environment configuration, such as the endpoint, public and secret keys or tracing flags, rather than editing application code. Roll out one environment at a time and keep a documented rollback value for each service. Watch ingestion, error rates and the dashboards your on-call team uses during the rollout. The output is a change record showing every service, the configuration applied and the date it moved.
Decommission LangSmith with retention checks
Before you disable LangSmith tracing, your compliance lead confirms that exported data, the new platform's retention settings and any legal hold requirements are recorded in your data inventory. Remove the tracing settings from every service, revoke API keys, and confirm with LangChain how your account data will be deleted or retained under your contract. Keep the Parquet archive for the period your policy sets. The output is a closure record that auditors or internal reviewers can read without asking the engineers who ran the migration. Independent auditors, not DeployOpen, judge whether the record meets any specific requirement.

Moving LangChain and LangGraph instrumentation without rewriting agents

The goal of this section is to change where traces go without editing agent logic. Most LangChain and LangGraph applications already emit trace data through the callback system, and the cleanest route is to keep that instrumentation point stable and move only the configuration that decides where the events land. In practice, teams read the destination from environment variables at process start, so the tracing backend becomes a deployment setting rather than a code change. Confirm which tracing variables your current LangChain and LangGraph versions read, because the names have changed across releases and an old variable can silently send nothing.

For the self-hosted target, there are two common patterns. The first uses a Langfuse or Opik callback handler that is attached in one shared module, so each chain or graph receives it through configuration rather than hard-coded calls. The second uses OpenTelemetry exporters, which fits teams that already run a collector and want one pipeline for services that are not LLM applications. Check that the callback package or exporter you pick supports your installed LangChain and LangGraph versions, and that it captures the span types your agents rely on, such as tool calls and nested graph steps. Test this in a staging environment with a representative agent, not only with a single prompt.

Dual-write during the parallel run is the step that protects evaluation history. Send each trace to LangSmith and to the new backend at the same time, compare counts and a sample of span contents for the same requests, and only then switch off the old exporter. Your effort depends mainly on how many services emit traces, how many custom callbacks and evaluation scripts read from LangSmith, and whether any dataset or annotation workflow depends on LangSmith-specific features. Ask your implementation partner or internal team to inventory each of these in writing before the parallel run starts, and confirm callback and exporter compatibility with the library versions running in your own environment.

Which LangSmith alternative fits your situation

Teams with strict residency rules need to know where trace data is stored and processed at every layer. LangSmith Cloud keeps data in the region where the account signed up, which covers several GCP and AWS regions, but billing information stays in the US. If your obligations require full control over the storage location, a self-hosted platform is the more direct route. Langfuse is a practical fit because it runs in your own Kubernetes cluster or with Docker Compose for testing, and it needs PostgreSQL, ClickHouse, Redis or Valkey, and S3 or blob storage that you operate. Opik is Apache-2.0 licensed and states that the full platform can be self-hosted without a commercial license.

Storage footprint: List every component that persists prompts, inputs, outputs and metadata, including the ClickHouse and object storage tiers.
Telemetry and callouts: Confirm whether the platform, or any gateway you pair with it, makes outbound calls during normal operation.
Billing and account metadata: Ask whether any personal or account data leaves your region even when trace payloads stay local.
Backups: Check that backup copies follow the same region and key management rules as primary storage.

Confirm these points with the vendor in writing and verify them in your own environment before moving production traces.

Questions buyers ask before replacing LangSmith

How much effort does moving off LangSmith take?

The effort depends mostly on how much of your stack depends on LangSmith's instrumentation, how many projects, datasets and evaluators you need to carry over, and how much historical trace data you must keep. Teams that use LangChain and LangGraph with the standard tracing environment variables usually face a smaller code change than teams that call the LangSmith SDK directly in many services. Prompt libraries, evaluation datasets and dashboards are often the slowest parts to recreate. Ask any implementation partner for a written scope that lists each service, each evaluator and each data retention requirement before agreeing on a timeline.

What does the migration need from our engineering team?

Your team needs to name owners for the services that emit traces, someone who can approve changes to tracing configuration, and someone who knows which prompts and evaluators are in production use. Platform engineers need access to the Kubernetes cluster or cloud account where Langfuse or Opik will run, along with the managed database, cache and object storage it depends on. Security and compliance staff should confirm where traces may be stored and who may read them. Plan for review time on each service, because instrumentation changes need testing before they reach production.

Can our own team migrate from LangSmith without outside help?

Some teams can, particularly those with a small number of services, strong Kubernetes experience and time to test instrumentation changes. The work that often needs experienced hands is the production deployment: sizing PostgreSQL, ClickHouse, Redis or Valkey and object storage, configuring backups and upgrades, and documenting the setup for auditors. Langfuse documents Docker Compose for testing and Kubernetes with Helm for production, which gives a clear starting point. Decide early which parts your team will own after go-live, since that ownership decides whether you need a retainer for upgrades and continuous support.

How does Parquet export fit into the migration plan?

LangSmith bulk export writes trace data to an S3-compatible bucket in Parquet format, which gives you a copy of historical traces you can load into another system or archive. For customers who signed up after August 3, 2026, bulk export is only available on the Enterprise plan. Earlier Plus customers keep access until February 1, 2027. Confirm your account's plan and date before you rely on export, and check whether your target platform can ingest the Parquet files directly or whether a conversion step is needed. Export gives you history, but it does not recreate live tracing, evaluators or prompt versions, so those need their own migration steps.

Does self-hosting LangSmith require the Enterprise plan?

Yes. Self-hosted LangSmith is an add-on to LangChain's Enterprise plan and needs a license key. It deploys to your own Kubernetes cluster using Helm charts, and Terraform is also documented. This matters for cost planning because the Enterprise plan, the license and the infrastructure you run are separate line items. Ask LangChain for a written quote that separates the license, the cluster and the storage, and confirm which features are included before you compare the total with an open-source option.

Do Langfuse or Opik need an enterprise license for their features?

It depends on the feature and the product. Langfuse is open core: code outside its ee directories is MIT licensed, and code inside them uses a separate commercial license. Langfuse states that self-hosting is open source, but some advanced features need an enterprise license key. Opik, built by Comet, is Apache-2.0 licensed, and its README states that the full platform, including tracing, evaluations and prompt management, can be self-hosted without a commercial license. Before you commit, list the features you need, such as SSO, audit logs or specific evaluation tooling, and check each one against the current license files.

How does DeployOpen scope a LangSmith replacement?

DeployOpen scopes each engagement in writing before work starts. The scope usually covers which services move, which platform is deployed (for example Langfuse or Opik), where it runs in your cloud account or data center, how instrumentation changes are tested, how historical data is handled, and what documentation and handover you receive. Most engagements are fixed-scope, and ongoing support, upgrades and continuous testing are available as retainers. DeployOpen does not publish a price list, so the quote follows from the agreed scope. Ask for the written scope and the list of deliverables before comparing proposals.

How DeployOpen scopes, migrates and supports the replacement

DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For a LangSmith replacement, that means starting from your trace volumes, data residency needs and LangChain and LangGraph usage before any platform is installed.

How we scope

Inventory which LangChain and LangGraph applications send traces, and which LangSmith features (tracing, evaluation, prompt hub, datasets) each team uses
Confirm where trace data must physically reside, and whether self-hosting in your own infrastructure meets that requirement
Agree a fixed written scope covering deliverables, timelines and responsibilities before any migration work begins

How we build

Deploy Langfuse or Opik in your environment, with PostgreSQL, ClickHouse, Redis or Valkey and S3 or blob storage configured to your standards
Re-instrument application code with the chosen platform's SDK or OpenTelemetry exporter, and test that traces, scores and prompts arrive correctly
Run security testing against the deployed platform and its APIs, and document the configuration for your review

How we hand over

Provide architecture, configuration and runbook documentation covering backups, upgrades, access control and retention settings
Export and preserve historical LangSmith data in an agreed format, and verify it can be read after cutover
Prepare evidence and controls for your internal or external compliance assessors, without issuing any audit report or certification

How we support

Ongoing support, upgrades and continuous security testing are available as retainers after handover
Confirm with your team which support boundaries apply, including who handles platform incidents and version upgrades
Ask any quote to separate one-time migration work from recurring infrastructure and retainer costs, so budgets can be compared accurately