Short version: If your requirement is "I can run the whole thing on my own hardware, with my traces never leaving my VPC," these are the three that qualify — and the tiebreaker is the LICENSE file, not the dashboard. Opik (Comet) is the most permissive: Apache-2.0, no feature gating, you can even resell it. Langfuse has the deepest evals-plus-prompt-management product and the biggest ecosystem; its core is MIT, with a few enterprise features held back in commercially-licensed ee/ directories, and it's now backed by ClickHouse after the January 2026 acquisition. Phoenix (Arize) is the lightest to stand up and the most OpenTelemetry-native, but it ships under the Elastic License 2.0 — source-available, not OSI-open, and it forbids offering Phoenix as a managed service to others. All three are free to self-host with no usage caps, and all three ingest OpenTelemetry, so the smartest move is to instrument with vendor-neutral OTel first and treat the backend as swappable.

LangfuseOpik (Comet)Arize Phoenix
LicenseMIT core (ee/ dirs commercial)Apache-2.0 (fully permissive)Elastic License 2.0 (source-available)
Self-host costFree, unlimited on your infraFree, unlimited on your infraFree, unlimited on your infra
Resell as a service?Yes (MIT core)Yes (Apache-2.0)No — ELv2 forbids it
Best atEvals + prompt management, ecosystemPrompt optimization + guardrailsLightest start, OTel/OpenInference
OTel/OTLP ingestYesYesYes
BackingClickHouse (acq. Jan 2026)Comet MLArize AI

The only spec that outlives the demo: the LICENSE file#

Every one of these tools will show you a pretty trace waterfall in ten minutes. That is not the decision. The decision is what you're allowed to do with the software eighteen months from now, and that lives in a text file most founders never open.

Here's what's actually in those files. Langfuse's core is MIT (Expat) — genuinely permissive — with a carve-out: code under ee/, web/src/ee/, and worker/src/ee/ is governed by a separate enterprise license. So "Langfuse is open source" is true for the platform you'll actually run, with an asterisk on a handful of enterprise features. Opik is cleaner still: Apache-2.0 across the board, which is OSI-approved, permissive, and carries no feature gating between the self-hosted build and the paid cloud. Phoenix is the one to read carefully — it's the Elastic License 2.0, a source-available license. You can self-host it for free with no usage caps, but ELv2 is not OSI-approved, and it specifically bars you from providing Phoenix as a hosted or managed service to third parties.

For most founders that ELv2 restriction never bites — you're running an observability backend for your own app, not reselling it. But if you're building a platform where "we host your tracing for you" is part of the product, that clause is the whole ballgame.

What each one is actually best at#

Langfuse is the broadest product. It's an observability, evals, and prompt-management platform, with the largest integration surface of the three and a huge install base — which matters, because ecosystem gravity is why your framework probably already has a Langfuse exporter. It's also the one that just changed hands: ClickHouse acquired Langfuse on January 16, 2026, and both companies committed to keeping the core open source and self-hostable under the existing MIT license. Langfuse already ran on ClickHouse under the hood, so this is less a pivot than a formalization. We wrote up the deal and its lock-in implications here, and the tool highlight covers day-to-day use.

Opik is the one to reach for when evaluation and improvement are the same workflow. Beyond tracing and LLM-as-a-judge metrics, it ships a prompt-optimization SDK (the Opik Agent Optimizer) and guardrails in the open-source build — features other tools reserve for paid tiers or don't have at all. The full backend, not just a client SDK, deploys via Docker Compose locally or Kubernetes/Helm in production, all under Apache-2.0. If your instinct is "I want to close the loop from a bad trace to a better prompt without a second vendor," Opik packs the most into the free tier. It's the open-source anchor of our eval-platform comparison.

Phoenix wins on time-to-first-trace and OpenTelemetry purity. It's a single container — a docker run, a pip install arize-phoenix, or a Helm chart — and you have a tracing backend running in one process, fully air-gapped if you want, with nothing sent to Arize. Its instrumentation layer, OpenInference, is a separate Apache-2.0 project, so the emitting side is permissively licensed even though the server is ELv2. If you already speak OpenTelemetry and want the least infrastructure between you and a trace view, Phoenix is the fastest yes. The self-host walkthrough has the details.

The tool you demo in ten minutes and the tool you're locked into for two years are the same product wearing two different faces. The LICENSE file is the only place they tell you which one you're actually buying.

Instrument once: OTel is the escape hatch#

Here's the move that makes this whole comparison lower-stakes than it looks. All three of these platforms ingest OpenTelemetry. Langfuse exposes a native OTLP endpoint (OTLP over HTTP, JSON and protobuf). Opik has a native OTLP integration over HTTP transport. Phoenix is built on OpenInference, which is OTLP under the hood. That means if you instrument your agent with vendor-neutral OpenTelemetry rather than a proprietary SDK, your traces are portable: switching from Phoenix to Langfuse — or running two backends in parallel while you evaluate — is a config change, not a re-instrumentation project.

That asymmetry is the real advice buried in every "X vs Y" observability piece. The proprietary SDK is faster to wire up on day one and far more expensive to leave on day 400. Instrument with OTel, and the backend becomes a swappable component instead of a marriage — which also happens to be the foundation for attributing cost per task instead of per call once you're running at scale.

Pick X if…#

Whatever you pick, self-host a small pilot against your own traces before you commit — and instrument with OpenTelemetry so that if the pilot changes your mind, your data comes with you.