Langfuse vs Opik: which to self-host

Langfuse vs Opik: when each one fits

Langfuse vs Opik is a decision you can make on four questions: which features you need behind a paid key, which databases your team can operate, how strict your identity rules are, and what in-house skills you already have. A regulated team that must keep LLM traces inside its own infrastructure should answer those questions before comparing dashboards. Both tools can be self-hosted, but they differ in where the paid line sits and in what the data stack looks like.

Langfuse fits teams whose core need is tracing, evaluations and prompt management under the MIT license, with the option to add an Enterprise license key for controls such as project-level RBAC, data retention policies, audit logs and the SCIM-based organization management API. It also suits a team that already runs PostgreSQL and ClickHouse, since a self-hosted Langfuse deployment uses both plus Redis or Valkey and S3-compatible storage. Confirm which of the key-gated features your auditors or security reviewers require, because those are the ones that trigger a paid license.

Opik fits teams that want the full platform under Apache-2.0, including the server backend, tracing, evaluations, prompt management, online evaluation rules and Opik Guardrails, with no commercial license needed to self-host, according to its README. It also suits teams expecting very high trace volume, because the README states the platform handles 40M+ traces per day, and teams comfortable operating ClickHouse, MySQL and Redis. Check whether your team can run that combination, and ask Comet to confirm which identity and access controls are available in the self-hosted edition before you commit.

Which platform fits which team scenario

This table maps common team situations to the platform that fits better and the condition that decides it. Read each row as a conditional recommendation: the named condition is what should change your choice, so check it against your own environment before shortlisting.

Scenario	Better fit	Condition that drives the choice
Small team that needs tracing and evaluations only	Either platform	Both keep core tracing, evaluations and prompt management in their open editions, so pick on the ecosystem your code already uses and the databases you are willing to run.
Platform team that needs project RBAC, audit logs and SCIM	Langfuse, if the Enterprise key is acceptable	Langfuse documents RBAC roles, audit logs and SCIM as features that need an Enterprise license key. Confirm how Opik's paid editions gate equivalent controls before deciding.
Team with heavy trace volume	Confirm with a proof of concept	Opik's README cites 40M+ traces per day. Langfuse scales by splitting web and worker deployments. Test ingestion at your real volume on both stacks.
Team already running ClickHouse	Langfuse, usually	Langfuse uses ClickHouse as a core store next to PostgreSQL, Redis or Valkey and blob storage. Opik also needs ClickHouse, but adds MySQL and Redis, so the shared footprint is smaller for Langfuse.
Team with no Kubernetes	Langfuse on Docker Compose for testing	Langfuse documents Docker Compose on a single VM for testing without high availability. Opik offers Docker Compose through its opik.sh script for local use. Production on either stack expects Kubernetes or managed services, so confirm your target.
Team that needs guardrails with observability	Opik, if Opik Guardrails fits your policy	Opik's README lists Opik Guardrails with tracing and evaluations. Langfuse's documentation does not list guardrails as a core feature, so confirm its current capabilities before ruling it in or out.
Team bound to OpenTelemetry instrumentation	Confirm for your stack	Opik supports OpenTelemetry and native integrations for 60+ frameworks. Langfuse also documents OpenTelemetry. Check which SDKs and framework integrations your applications use.
Team that wants a vendor-hosted option later	Opik, with a hosted path on Comet.com	Opik is also offered as a hosted service on Comet.com. Langfuse's hosted service is Langfuse Cloud, covered on its own comparison page. Weigh the hosted option only if you may move off self-hosting.

How Langfuse and Opik are built and deployed

Both platforms are self-hostable LLM observability stacks, but they differ in how many stateful services you run and which deployment paths the vendor documents. The cards below cover the components, the deployment options, and what each choice means for backups, upgrades and on-call work.

Langfuse runtime components

A self-hosted Langfuse deployment runs two application containers, Langfuse Web for the UI and APIs and Langfuse Worker for asynchronous event processing. Behind them sit PostgreSQL, ClickHouse, Redis or Valkey, and S3-compatible blob storage. Count six stateful or supporting services before you size the platform. Ask who owns patching and restore testing for each one, since your backup scope covers all of them.

Langfuse deployment paths

Langfuse documents Docker Compose on a single VM for testing, without high availability, and Kubernetes with Helm or Terraform-based deployments on AWS, Azure and GCP for production. Plan on Compose for a proof of concept and move to Kubernetes before you put real traces behind it. Confirm which production path your cloud team will support, because the vendor documentation does not replace your own platform standards.

Opik runtime components

Opik's infrastructure uses ClickHouse, MySQL and Redis. Like Langfuse, it stores traces in ClickHouse, but it adds MySQL for relational metadata instead of PostgreSQL. Your team must operate two relational engines if you already run PostgreSQL elsewhere. Confirm with Comet which ClickHouse and MySQL versions the current release supports and how the stack handles schema migrations during upgrades.

Opik deployment paths

Opik self-hosts with Docker Compose for local use through its opik.sh script, and on Kubernetes with Helm charts for production. The Compose path is the documented route for evaluation, while the Helm path is the one to test against your cluster policies. Ask Comet which chart values are supported for external ClickHouse and MySQL, and whether the chart can point at managed services you already operate.

Backup and upgrade scope

Langfuse says updates within a major version are non-disruptive and apply database migrations automatically at startup, while major upgrades follow dedicated migration guides. Its v3 to v4 guide requires ClickHouse 25.12 or later, PostgreSQL 15 or later and Redis 7.0 or later, and advises about 3x ClickHouse disk headroom when backfilling historic data. Budget disk headroom and a rehearsed backup before any major upgrade. Ask Comet for the equivalent upgrade guide and backup procedure for Opik before comparing the effort.

Trace volume claims and on-call load

Opik's README states that the platform handles 40M+ traces per day, but that is a vendor statement about its own setup, not a sizing guarantee for your workload. Your on-call load depends on ingestion spikes, worker backlog and ClickHouse memory more than on the trace count alone. Run a load test with your own trace shape and ask both vendors how they recommend scaling workers and splitting ingestion from the UI.

Tracing, evaluations and prompt management compared

This table compares how Langfuse and Opik handle tracing, agent traces, evaluations, prompt management, online rules, guardrails and framework integrations. Rows marked to confirm depend on the release you deploy, so check them against the current docs before you shortlist. The main takeaway is that Opik's README lists its full self-hosted platform under Apache-2.0 with no license key, while Langfuse keeps several team and governance controls behind its Enterprise key.

Capability	Langfuse	Opik
Tracing and OpenTelemetry	Core tracing ships in the MIT edition without limits. OpenTelemetry ingestion is documented; confirm the supported span attributes for your SDK.	Supports OpenTelemetry, native integrations and a @track decorator for custom code.
Agent tracing	Confirm how multi-step agent runs display in your release, since the supplied facts do not describe the agent trace view.	Multi-step agent tracing is listed as a core feature in the README.
LLM-as-a-judge evaluations	Evaluation features are part of the MIT core. Confirm which judge metrics ship out of the box and which need custom configuration.	Built-in LLM-as-a-judge metrics for hallucination, moderation and RAG quality.
Prompt management and playground	Prompt management is in the core. Protected prompt labels need an Enterprise key. Confirm playground availability on the free tier.	Prompt management with a playground, included in the self-hosted Apache-2.0 platform.
Online evaluation rules	Confirm whether scheduled or rule-based online evaluation is available in your version and edition.	Online evaluation rules are listed as a platform feature in the README.
Guardrails	No guardrail feature is covered by the supplied facts. Confirm before assuming runtime blocking is available.	Opik Guardrails is listed. Confirm its exact scope, including whether it runs inline or only on logged data.
Framework integrations	Confirm the current list of SDK and framework integrations in the Langfuse docs for your stack.	Native integrations for LangChain, LangGraph, LlamaIndex and CrewAI, plus 60+ other frameworks.
Features behind an Enterprise key	Project RBAC, protected prompt labels, data retention, audit logs, server-side masking, UI customization, SCIM and the instance management API.	The README states the full platform can be self-hosted without a commercial license. Confirm which hosted-only features differ.

What each license keeps behind a paid edition

Langfuse is open core. Code outside its enterprise directories is released under the MIT Expat license, while code inside the ee, web/src/ee and worker/src/ee directories falls under a separate commercial license. Langfuse states that all core features and APIs are available in the open-source version without limits, and self-hosted deployments run the same codebase as Langfuse Cloud. The split is therefore about which directories carry commercial terms, not about which tracing or evaluation features work.

Permissive core: The MIT-licensed code covers the core product, and you can self-host it without a license key.
Commercial directories: Files in the ee directories need the Enterprise license terms, so confirm which directories your build touches.
Same codebase: Langfuse says self-hosted and Langfuse Cloud deployments share one codebase.
No feature limits claimed: Langfuse states core features and APIs have no limits in the open-source version.
Scope of the claim: Confirm with Langfuse in writing how the ee directories apply to your planned use, including any hosting-as-a-service arrangement.

Before purchase, ask Langfuse to confirm in writing which directories and components fall under the commercial license for your intended deployment.

What drives the running cost of each platform

Running either platform costs more than its license line, which is zero for both open-source editions. The cost sits in the databases and containers you run, the people who operate them, and the support and upgrade work you buy or staff. The cards below separate those components so you can ask each vendor or partner for the same breakdown.

Infrastructure floor for Langfuse

Langfuse documents minimums of 2 CPU and 4 GiB for the web container, the 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. These are starting points for sizing, not production capacity. Add blob storage and the growth of ClickHouse disk, which the v4 upgrade guide says to plan for with about 3x headroom when backfilling history.

Infrastructure footprint for Opik

Opik runs on ClickHouse, MySQL and Redis, and its README states it handles 40M+ traces per day. The project does not publish per-component minimums in the sources we reviewed, so request sizing for your expected trace volume, retention and concurrent users before comparing hosting bills. Ask whether MySQL and ClickHouse are sized separately for production and whether Redis is clustered or single-node.

Skilled operations staff

The largest recurring cost is usually the engineer hours to run ClickHouse, the transactional database and the cache, plus Kubernetes or Compose upkeep. Opik adds a MySQL database to a stack that also includes ClickHouse and Redis, so confirm who owns backups, restores and version drift for each store. Estimate the share of an existing platform team that this consumes, and record it as a recurring line.

Support tiers and their scope

Langfuse's self-hosted pricing page lists a free open source plan and a custom-priced Self-Hosted Enterprise plan that adds a named support engineer, solutions architect access and a support SLA. Opik's support terms for self-hosted users are not in the supplied sources, so ask Comet what response commitments, upgrade help and security fix windows apply. Compare these terms against an independent partner retainer, which is scoped in writing.

Paid features and license keys

Langfuse keeps RBAC roles, protected prompt labels, data retention policies, audit logs, server-side masking and SCIM behind an Enterprise license key, and some of those controls may matter to your compliance evidence. Opik's README says the full platform, including tracing, evaluations and prompt management, is available without a commercial license, but confirm which governance controls are gated before you assume parity. License fees recur annually and should be a line item in any Langfuse quote.

Upgrades and hosted alternatives

Langfuse says minor updates within a major version are non-disruptive and migrate the database at startup, while major upgrades follow dedicated guides with ClickHouse 25.12 or later required for v4. Each major upgrade is a planned, one-time project with testing time and rollback planning. Comet also hosts Opik on Comet.com and Langfuse Cloud is unit-priced, so price a managed option beside self-hosting to compare total cost honestly.

Moving LLM traces and prompts from one platform to the other

This sequence moves a team's LLM tracing, prompts and evaluation setup from Langfuse to Opik, or the reverse, with a clear record of what carried over and what was rebuilt.

Inventory SDKs, instrumentation and trace consumers
The platform engineering or ML platform owner lists every application that sends traces, the SDK or decorator each one uses, which framework integrations are active and which dashboards, alerts or downstream jobs read the trace data. Teams running Opik's native framework integrations or the @track decorator should note each call site, because those wrappers do not move unchanged. The output is a written inventory with one row per application and a named owner for each, reviewed before any code changes.
Decide whether to dual-write through OpenTelemetry
The team decides whether new traces go to both platforms during a cutover window. Both platforms accept OpenTelemetry (Langfuse documents OpenTelemetry ingestion, and Opik supports OpenTelemetry), so an OpenTelemetry exporter can send the same spans to each. Confirm with each vendor which span attributes, such as LLM input and output and token usage, map to native fields on the receiving side, because attribute handling can differ. The output is a recorded decision on dual-write, its end date and the owner who can switch it off.
Export prompts and evaluation datasets
The team exports prompt versions, labels and any evaluation datasets from the source platform and imports them into the target. Neither vendor's export tooling is assumed here, so confirm the supported export formats, what metadata survives and whether prompt labels and version history carry over with each vendor before relying on them. The output is a checked copy of prompts and datasets, compared by version count and content against the source, with differences logged.
Decide how much trace history to backfill
The team chooses between backfilling historic traces into the new platform and accepting a gap in history. Backfill is costly in storage and effort, and it may not be possible for every span format, so confirm with the vendor whether historic traces can be imported at all. Teams with audit or retention obligations should keep the source platform's data for the required period instead of relying on a migrated copy. The output is a written history decision for each application, signed off by the data owner.
Re-create judge configurations, rules and dashboards
Evaluation rules, LLM-as-a-judge configurations, online evaluation rules, alerts and dashboards do not carry over automatically, so the team rebuilds them on the target platform. Opik offers hallucination, moderation and RAG judge metrics and online evaluation rules, and Langfuse has its own evaluation setup, so each judge prompt and threshold must be re-validated against a fixed set of traces. The output is a side-by-side results check where scores from the old and new configurations are compared on the same examples.
Re-instrument SDK wrappers in application code
Developers replace the source platform's SDK calls and decorators with the target platform's equivalents in each application, then run them in a non-production environment. Framework callbacks and custom tracing helpers need separate testing because their span structure can differ. The output is a passing test run per application that shows traces with the expected nesting, user and session fields and token counts in the target platform.
Retire the old stack after a verified cutover
Once the team has confirmed that traces, prompts, evaluations and alerts work on the target platform, it stops dual-writing, removes old SDK calls and sets a read-only retention period on the source data. The team then decommissions the source databases and services only after its retention obligations are met. The closing check is a signed record listing each application, its cutover date and where its historic data is stored, kept with the infrastructure documentation.

Where self-hosted Langfuse and Opik projects usually run long

Most of the effort in either project sits in the data stack, not in the tracing SDK. Self-hosted Langfuse runs a web and a worker container backed by PostgreSQL, ClickHouse, Redis or Valkey and S3-compatible blob storage, so your team must provision and patch all of those. Opik's infrastructure uses ClickHouse, MySQL and Redis, and the Opik README documents Docker Compose through its opik.sh script for local use and Helm charts for Kubernetes production. Compose is quick to try, but a production rollout means your team operates MySQL alongside ClickHouse, with backups, upgrades and access control for each. Confirm with Comet which database versions and sizing the current Helm chart expects before you commit to a platform design.

ClickHouse sizing and upgrades carry the most risk for Langfuse. The scaling guide lists at least 2 CPU and 8 GiB for ClickHouse, with at least 16 GiB of memory for larger deployments. The v3 to v4 upgrade guide requires ClickHouse 25.12 or later (26.4 recommended), PostgreSQL 15 or later and Redis 7.0 or later, moves to an observations-first ClickHouse data model, and advises about 3x ClickHouse disk headroom when backfilling historic data. Plan that headroom before the migration window, and test the backfill on a copy of production data. Ask Langfuse for the storage growth you should expect from your trace volume, because the guide does not give a per-trace figure.

Identity, SSO and instrumentation are where the team effort spreads across roles. Langfuse places project-level RBAC, audit logs, SCIM and the org management API behind an Enterprise license key, so budget identity work against the edition you intend to run. Confirm which of these features your Opik deployment requires and how Opik handles user roles in your chosen setup. Instrumentation effort depends on your frameworks: Opik lists native integrations with LangChain, LangGraph, LlamaIndex, CrewAI and 60+ other frameworks plus a @track decorator, while Langfuse supports OpenTelemetry. Evaluations need a judge model and a rule owner, and that person must be named before go-live. Your team must supply the database operators, a Kubernetes or VM platform owner, an identity administrator and an application owner for each instrumented service.

Questions buyers ask before choosing or hiring help

Is Langfuse free to self-host and is Opik free to self-host?

Yes, both can be self-hosted without paying the vendor for the core platform. Langfuse's repository is MIT licensed except for content in its ee directories, and Langfuse states that all core features and APIs are available in the MIT-licensed open source version without limits. 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. Your costs are the infrastructure you run and the people who operate it. Confirm the current terms in the Langfuse LICENSE file and the Opik repository before you commit.

What does Langfuse Enterprise add, and when do we need it?

Langfuse Enterprise adds features that need a license key on a self-hosted deployment. The list includes project-level RBAC roles, protected prompt labels, data retention policies, audit logs, server-side data masking, UI customization, organization creators, and the org management API with SCIM and the instance management API. You need it when your governance rules require one of these controls, such as SCIM provisioning from your identity provider or retention enforcement inside the tool. If none of these is a requirement, the open source edition covers tracing, evaluations and prompt management. The self-hosted pricing page lists a custom-priced Self-Hosted Enterprise plan that adds a named support engineer, solutions architect access and a support SLA. Ask Langfuse for the current quote and terms.

How much effort does a self-hosted Langfuse or Opik deployment take, and who runs it?

Effort depends on the scale you need and on how many stateful services your team already runs. A self-hosted Langfuse deployment runs a web and a worker container backed by PostgreSQL, ClickHouse, Redis or Valkey, and S3-compatible blob storage. Langfuse documents Docker Compose on one VM for testing without high availability, and Kubernetes with Helm or Terraform for production. Opik uses ClickHouse, MySQL and Redis and offers Docker Compose through its opik.sh script or Helm charts for Kubernetes. The people who run it are usually a platform or SRE team that owns backups, upgrades, monitoring and capacity. Ask each vendor for its minimum and recommended resource profile for your expected trace volume.

Which databases does each platform require?

Langfuse requires PostgreSQL for transactional data, ClickHouse for trace and analytics storage, Redis or Valkey for queues and caching, and S3-compatible blob storage. Its scaling guide lists 2 CPU and 4 GiB for 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. Opik's infrastructure uses ClickHouse, MySQL and Redis. The practical difference is PostgreSQL for Langfuse versus MySQL for Opik, while both rely on ClickHouse for traces. Confirm the current database versions in the Langfuse self-hosting documentation and the Opik README, since the Langfuse v3 to v4 guide sets its own minimum versions.

Can our own engineers do the work without a consultant?

Often yes, if your team already operates PostgreSQL or MySQL, ClickHouse, Redis and object storage, and has Kubernetes or Docker Compose experience. The work is usually a deployment, a set of SDK or OpenTelemetry instrumentation changes in your applications, identity and access setup, and a routine for backups and upgrades. The effort rises when no one on the team has run ClickHouse in production, because its memory and disk sizing drive both cost and reliability. Langfuse says updates within a major version apply database migrations at startup, while major upgrades follow dedicated guides. Ask a team member to read the upgrade guide and the scaling guide, then estimate the work from those pages.

What would an implementation partner handle for us?

A partner such as DeployOpen plans, implements, integrates, hardens, backs up, upgrades, documents and supports self-hosted platforms inside your own infrastructure. For an observability tool, that can mean sizing the stack, deploying it in your cloud account or data center, connecting identity, configuring retention and access controls, wiring instrumentation into your applications, and writing the runbooks your operators will use. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. Ongoing support and upgrades are available as retainers. DeployOpen does not issue audit reports or certifications, so evidence for an assessment comes from your auditor's review of the controls you operate.

How long does a migration between Langfuse and Opik take, and what drives it?

The duration depends on how many applications send traces, how many prompts and evaluation datasets you keep, and whether you need historic data moved or only new traces. Instrumentation is usually the largest part, because each application must point at the new platform or emit OpenTelemetry data. Historic data migration depends on export and import options that you must confirm with each vendor. Langfuse's v3 to v4 guide advises about 3x ClickHouse disk headroom when backfilling historic data, which shows how storage affects planning. No duration figure is given here, so ask for a written scope that lists applications, data volumes and cutover steps before you set a date.

Does the open source edition meet security and compliance needs?

It depends on which controls your assessment requires. Both platforms can be self-hosted inside your network, which keeps trace data under your control, and that is the main reason many regulated teams choose self-hosting. Features such as SCIM, RBAC roles, audit logs and retention policies are Langfuse Enterprise features on a self-hosted deployment, so check whether your control set depends on them. For Opik, confirm which access, audit and retention controls the open source release provides and which, if any, need the Comet hosted or commercial offering. Neither DeployOpen nor any vendor issues attestations, so ask your assessor which evidence they will accept.

How to decide which platform to run in your environment

Start with the paid features, because they decide whether the open edition is enough. Langfuse keeps all core tracing, evaluation and prompt features in its MIT-licensed code without limits, but project-level RBAC, protected prompt labels, data retention policies, audit logs, server-side data masking, UI customization, and the org management API with SCIM all need an Enterprise license key. Opik's README states that the full platform, including tracing, evaluations and prompt management, can be self-hosted without a commercial license, and the Opik features listed in its README do not carry a license key requirement in the supplied facts. Write down every control your auditors or security team expect, then check each one against the current Langfuse license key documentation and the Opik repository. Confirm with Comet whether any Opik capability you need sits outside the Apache-2.0 release. Next, size the database team you actually have. Langfuse needs PostgreSQL, ClickHouse, Redis or Valkey and S3-compatible storage, and its scaling guide lists 2 CPU and 8 GiB for ClickHouse with at least 16 GiB for larger deployments. Opik needs ClickHouse, MySQL and Redis. Both put analytics in ClickHouse, so the question is who will patch, back up and tune it. Ask whether your platform team already runs ClickHouse in production, and whether MySQL or PostgreSQL is the standard you want to support. Also confirm the upgrade path: Langfuse's v3 to v4 guide requires ClickHouse 25.12 or later and about 3x ClickHouse disk headroom for backfills, so ask Opik's maintainers for the equivalent storage and migration requirements for the version you plan to run. Then confirm identity and RBAC with your security team before the pilot, not after. Check how each platform authenticates users, whether SSO is in the open edition or behind a license, and how roles map to projects in your organization. Test ingestion volume with a realistic sample of your own traces, measuring storage growth and query latency in ClickHouse, and ask each vendor for the sizing they recommend at your volume. Run a time-boxed pilot on your own infrastructure with the same tracing, evaluation and prompt workflows your teams use, and record the operator hours it took. Put the results, the license checks and the vendor answers into one written decision record.

How DeployOpen helps teams choose and run LLM observability

DeployOpen is a Chainscore Labs company that plans, implements, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside the client's own infrastructure. For Langfuse vs Opik, we help teams test both tools against their own trace volumes, data stores and governance rules before committing to one.

How we scope

Confirm which features your team needs from the MIT edition and which may require a Langfuse Enterprise license key or Opik equivalents.
Record the target hosting model, whether Docker Compose on one VM or Kubernetes, and who owns ClickHouse operations.
Agree the written scope, deliverables and timeline in writing before work starts, since most engagements are fixed-scope.

How we build

Deploy the chosen platform in your cloud account, data center or air-gapped network, with the databases it requires.
Instrument a representative agent or LLM application with SDK or OpenTelemetry tracing and test evaluations and prompt versioning.
Test the platform's access controls, data retention and backup behavior against the requirements agreed during scoping.

How we hand over

Document the architecture, component inventory, configuration, network paths and secrets handling for your operations team.
Provide runbooks for upgrades, including the database migration steps your chosen version requires, and for backup and restore.
Walk your engineers through tracing, evaluation and prompt management workflows so the team can extend the setup independently.

How we support

Offer ongoing support, upgrades and continuous testing as a retainer if your team wants DeployOpen to keep operating the stack.
Plan version upgrades against each project's release notes and migration guides, and re-test after every change.
Review capacity and database sizing as trace volume grows, and confirm changes in writing before they are made.

Langfuse vs Opik