Langfuse vs Arize Phoenix: License, Self-Hosting and Tracing

Langfuse vs Phoenix: Which One Fits Your Team?

Langfuse and Arize Phoenix both trace LLM and agent calls, run evaluations and version prompts. Langfuse fits a team that needs an MIT-licensed core, judges that score live production traffic and prompt labels per environment or tenant, and can run a multi-service stack. Phoenix fits a team that wants the smallest self-hosted footprint and Arize's own OpenInference instrumentation, and accepts the Elastic License 2.0 terms.

The table reflects files and docs read on October 19, 2026. The Langfuse column rests on its docker-compose.yml and documentation source; the Phoenix column on its self-hosting configuration page and other docs in the Phoenix repository. Each later section links the page behind its rows.

Is Langfuse or Phoenix Open Source? MIT vs the Elastic License

The Langfuse LICENSE carves three ee directories, one at the root and one each under web and worker, out of its MIT grant and places them under a separate Enterprise license. The Phoenix LICENSE at the repository root is the Elastic License 2.0; the phoenix-otel and phoenix-client packages in the same repository carry their own Apache 2.0 licenses.

GitHub's license badge does not settle it, because the API returns NOASSERTION for both repositories. A script run on October 19, 2026 read each LICENSE file, the license fields of each project's PyPI package and the Open Source Initiative license list; this is its output:

run 2026-10-19T22:01Z

1. License, three ways
langfuse/langfuse
  GitHub API spdx_id : NOASSERTION
  LICENSE line 1:
    Copyright (c) 2023-2026 ClickHouse, Inc.
Arize-ai/phoenix
  GitHub API spdx_id : NOASSERTION
  LICENSE line 1:
    Elastic License 2.0 (ELv2)
PyPI langfuse 5.0.2
  license_expression : MIT
PyPI arize-phoenix 20.23.0
  license_expression : null (license: Elastic-2.0)
Langfuse ee dirs    : "ee/" "web/src/ee/" "worker/src/ee/"
  under ee/LICENSE   : Langfuse Enterprise license
  copyright holder   : ClickHouse, Inc.
OSI list entries    : 127
  has mit           : true
  has elastic-*     : false

In that output, the langfuse package on PyPI is the Python SDK, so its MIT expression describes the client, not the server. The arize-phoenix package leaves license_expression empty and carries "Elastic-2.0" in the older license field, so a check that reads only license_expression finds no license for Phoenix.

The Elastic License 2.0 states: "You may not provide the software to third parties as a hosted or managed service, where the service provides users with access to any substantial set of the features or functionality of the software." Running Phoenix for your own team is allowed; offering Phoenix to customers as a hosted service is not.

Published Phoenix vs Langfuse comparisons make claims that the projects' own files confirm or contradict:

The gating claim comes from Arize's Langfuse comparison page, a docs page kept in the Phoenix repository. Langfuse's June 2025 open-sourcing post moved managed LLM-as-a-judge evaluations, annotation queues, prompt experiments and the playground to MIT, and its Enterprise license key page lists what still needs a key:

• Access - project-level RBAC roles, organization creators, the Org Management API and SCIM.
• Governance - audit logs, data retention policies and server-side data masking.
• Prompts and branding - protected prompt labels and UI customization.
• Operations - the Instance Management API.

The Phoenix license page says self-hosting "is free and fully permitted" and calls Phoenix "a fully open-source platform". Read both together: Phoenix has no feature gates, and its license still restricts hosting it for others, which MIT does not.

Who Owns Langfuse and Arize Phoenix After the ClickHouse and Dynatrace Deals?

Langfuse's maintainers wrote "We're excited to announce that Langfuse is joining ClickHouse" in a GitHub announcement on January 16, 2026. The same post answers "Is Langfuse still open source?" with "No licensing changes planned."

The repository shows the change in its files: the script found ClickHouse, Inc. as copyright holder in the root LICENSE, and the Enterprise license refers to agreements with "Langfuse GmbH or ClickHouse, Inc." The MIT grant itself is unchanged.

In a Dynatrace press release dated October 1, 2026, the company announced that it had completed the deal for Arize; the release gives no separate closing date. The release says "Arize will continue supporting both Phoenix, its open-source platform, and AX, its enterprise platform", and that "Over time, Arize capabilities will be integrated into Dynatrace".

• What has changed - the company behind each tool. The license terms, read on October 19, 2026, are still MIT with ee carve-outs for Langfuse and ELv2 for Phoenix.
• What to watch - the Phoenix and AX roadmap as Dynatrace integrates Arize, and any license change in either repository; rerun the license check at each upgrade.
• What is out of date - a comparison page written before October 2026 cannot reflect the completed Dynatrace deal, so check the date on any you read.

Self-Hosting Langfuse vs Phoenix: Service Stack or Single Process

The same script parsed the services in the Langfuse Compose file and read Phoenix's Docker deployment page and configuration docs:

2. Self-host footprint
Langfuse compose services: 6
  langfuse-worker, langfuse-web, clickhouse
  minio, redis, postgres
Phoenix docs, single container:
  docker run -p 6006:6006 -p 4317:4317
    arizephoenix/phoenix:latest
  default store SQLite: true
  PostgreSQL option   : true

Langfuse needs six containers before the first trace arrives, and the Langfuse Docker Compose guide says "The docker compose setup lacks high-availability, scaling capabilities, and backup functionality." For a VM it recommends "at least 4 cores and 16 GiB of memory", and for high availability it recommends Kubernetes with Helm.

Phoenix starts from a Python install or the container above. With no database URL set, the Phoenix configuration page says it "starts with a file-based SQLite database in a temporary folder", so a persistent setup either mounts a volume for PHOENIX_WORKING_DIR or sets PHOENIX_SQL_DATABASE_URL to PostgreSQL.

pip install arize-phoenix
phoenix serve

• Backups - Langfuse needs backups of Postgres, ClickHouse and the S3-compatible bucket; Phoenix needs its SQLite file or its PostgreSQL database.
• First production step - for Phoenix, move from the temporary SQLite file to PostgreSQL; for Langfuse, move from Compose to the Helm chart. Braintrust vs Langfuse walks through self-hosting Langfuse step by step beside the Braintrust data plane.

OpenInference vs OpenTelemetry: How Langfuse and Phoenix Read Traces

Phoenix reads spans written to Arize's OpenInference semantic conventions, an Apache-2.0 set of attribute names that rides on OpenTelemetry. The spec says "The openinference.span.kind attribute is required for all OpenInference spans", with values such as LLM, TOOL, AGENT and RETRIEVER.

Langfuse takes OTLP from its own SDKs or any OpenTelemetry source and translates attributes into its data model. Its OpenTelemetry attribute mapping lists OpenInference keys next to gen_ai and MLflow ones; the script checked nine OpenInference LLM-span attributes against that table:

3. OpenInference LLM span vs Langfuse mapping
attribute                     spec Langfuse table
openinference.span.kind       yes  not in table
input.value                   yes  named
output.value                  yes  named
llm.model_name                yes  named
llm.invocation_parameters     yes  named, as prefix.*
llm.token_count.prompt        yes  parent prefix.*
llm.token_count.completion    yes  parent prefix.*
llm.input_messages            yes  not in table
llm.prompt_template.version   yes  not in table
Langfuse OTLP gRPC unsupported: true
Phoenix OTLP gRPC on 4317    : true

Input, output, model, parameters and token counts from OpenInference spans land in Langfuse's own fields. Two of the "not in table" rows are handled anyway: Langfuse's OpenTelemetry ingestion code, read on October 19, 2026, maps openinference.span.kind to its observation types (LLM to generation, TOOL to tool, AGENT to agent) and rebuilds a span's input and output from llm.input_messages and llm.output_messages when the span carries neither input.value nor output.value.

When input.value is present, Langfuse uses it as the input and leaves the message list out of metadata. The prompt template version is in neither the docs table nor that code, so it lands where the Langfuse page puts unmapped attributes: "Nested under metadata.attributes (catch-all)".

• Exporter protocol - Langfuse says "gRPC is not supported yet", so an exporter set to gRPC for Phoenix's port 4317 must switch to HTTP before it can send to Langfuse.
• Moving between the two - instrumenting once with OpenInference or gen_ai attributes lets the same spans reach either backend; Langfuse-specific keys under langfuse.* mean nothing to Phoenix. The same gen_ai conventions also define OpenTelemetry LLM metrics, the histograms and counters for token usage and operation duration.
• Agent spans - both store tool-call spans, the raw material for AI agent tracing; OpenInference names TOOL and AGENT span kinds, and Langfuse's ingestion code turns them into its tool and agent observation types.

Evals, Datasets and Experiments in Langfuse and Phoenix

Both tools run LLM-as-a-judge evaluators and code checks over datasets and experiments, but a judge configured in the Langfuse UI can also run on live data. The Langfuse LLM-as-a-judge docs say its evaluators "can run on Observations (individual operations) or Experiments", and call observation-level evaluators "the recommended target for live production data".

Phoenix's server evals page says to "Attach evaluators directly to a dataset and run them automatically on every experiment". Arize's own comparison table marks online evals as an AX and Langfuse feature, not a Phoenix one, so production traces in Phoenix are scored by its Python or TypeScript evals SDK in a job you run.

• Continuous scoring of live traffic - Langfuse runs it on the server once a rule with filters, a sampling rate and evaluators is saved; Phoenix needs a scheduled SDK job you operate.
• Experiments without local code - Phoenix's built-in server evaluators, such as Exact Match, Regex and Levenshtein Distance, run on every Playground experiment against a dataset.
• Score types - Langfuse judges write numeric, categorical or boolean scores; Phoenix stores evaluation results as annotations with a label, a score and an explanation.

Prompt Management in Langfuse vs Phoenix

Both store prompt templates with version history and let code fetch a version by a name you assign. The Langfuse version control page says labels can assign prompts "to environments (staging, production), tenants (tenant-1, tenant-2), or experiments (prod-a, prod-b)".

Phoenix's tag-a-prompt guide says prompts "are versioned in a linear history" and ships production, staging and development tags, plus custom tags.

• Locking a production prompt - Langfuse's protected prompt labels stop viewer and member roles from moving a label such as production, and on self-hosted Langfuse they need the Enterprise key.
• Linking prompts to traces - Langfuse links a generation to a managed prompt through langfuse.observation.prompt.name and version; OpenInference carries llm.prompt_template.version, which the mapping above does not list.

Phoenix vs Arize AX: Which Arize Product Are You Comparing?

"Langfuse vs Arize" often means Arize AX, not Phoenix. Arize's Phoenix and AX FAQ calls Phoenix "Arize's open-source platform for agent development and evaluation" and AX "Arize's managed, all-in-one AI engineering platform"; AX self-hosting "requires a commercial license". It lists HIPAA and SOC 2 certifications for AX that "don't apply" to Phoenix "in the same way".

The FAQ also says "no Phoenix feature is gated by the commercial offering", and Arize's Langfuse comparison table marks custom dashboards, workspaces, semantic querying and a copilot assistant as AX-only.

Langfuse Advantages vs Phoenix Advantages

These points come from each project's own files, as read for this comparison. Langfuse Cloud's meter is in its billable units page: units are traces plus observations plus scores, and the same page says the self-hosted MIT edition is not billed by usage.

Langfuse is stronger on these points:

• An MIT core, which allows hosting Langfuse for others; the Elastic License 2.0 does not allow that for Phoenix.
• Server-side judges on live production observations, set up without a separate scoring job.
• One ingestion endpoint that maps gen_ai, OpenInference and MLflow attributes, plus Langfuse Cloud regions in the EU, US and Japan and a HIPAA region, as listed on its OpenTelemetry page.
• Prompt labels per environment, tenant or experiment.

Phoenix is stronger on these points:

• A single process or container with SQLite, the shortest path from install to a running UI.
• OTLP over gRPC as well as HTTP, so existing gRPC exporters connect unchanged.
• Its own instrumentation layer, OpenInference, maintained by the same company as the backend.
• Server evaluators attached to a dataset, which score every Playground experiment with no local code.

Can a Langfuse or Phoenix Trace Prove What an Agent Did?

Langfuse and Phoenix keep what an agent's code reported about a run: spans, tool-call attributes such as OpenInference's message.tool_calls, and the scores judges gave those records. When a span says a refund tool returned success but the payments ledger never changed, the trace still shows a success, and a judge reading that trace has nothing else to go on.

TestMu AI's Agent Assurance tests that effect before the agent ships. Starting from the agent's source, or from a PRD or spec if the source is out of reach, it drafts scenarios, gives each one acceptance criteria, and runs them against the live agent on your staging environment.

• Files and artifacts - changes on disk inside the paths the agent's profile names, plus anything the run produced.
• Tool calls - each call observed during the run, checked against the agent's own declared tool list and its must-not-call rules.
• Records - a read-only lookup through a tool you approve, such as a query that confirms the refund row exists.
• Verdicts - each criterion receives Pass, Fail or Unable to Verify; a model judge scores some criteria, yet an agent's word that it acted never stands in for evidence.

Its scenario pass rate counts only scenarios that reached a decided verdict, and the report lists verification coverage and named gaps for what the run could not observe. Most tracing and eval tools grade the record an agent leaves behind, while Agent Assurance grades the change a run made.

Agent Assurance, still pre-alpha and publicly installable, ships its terminal client, the Rook CLI, through npm:

npm install -g @testmuai/rook

Node.js version 20 or above is a prerequisite for the npm package, and the client works on macOS and Linux, and 64-bit Windows through npm or WSL. A shell installer that verifies checksums, and Homebrew, cover macOS and Linux too, as the Rook CLI installation guide explains. Writes the agent makes during a run persist, since nothing is undone afterwards, so give it a staging target.

Agent Assurance does not store production traces or watch live traffic. Langfuse or Phoenix keeps recording what happens in production, and an Agent Assurance run checks a release candidate's effects before users meet it.

Choosing Between Langfuse and Phoenix, Check by Check

Work through these in order and stop at the first item that rules a tool out.

• Hosting for others - if you will offer the tracing UI to customers as a service, the Elastic License 2.0 rules out Phoenix; Langfuse's MIT core allows it.
• Operations budget - if nobody will run ClickHouse, Redis and object storage, Phoenix with PostgreSQL is the smaller system to keep alive.
• Live scoring - if judges must score production traffic continuously without a job you schedule, Langfuse's observation-level evaluators do that on the server.
• Existing instrumentation - if your exporters speak gRPC or you rely on OpenInference message attributes, test them against Langfuse's mapping before you migrate.
• Admin controls - Langfuse's Enterprise license key page puts audit logs, SCIM and retention policies on self-hosted Langfuse behind its Enterprise key, so budget for one if you need them.
• Third candidate - if LangSmith is on the shortlist, LangSmith vs Langfuse compares that pair. When Braintrust joins LangSmith on the list, LangSmith vs Braintrust compares those two on evals, tracing and CI.

Start by rerunning the license and footprint checks against today's files, then send one week of real spans to the candidate you chose. For agents that act on files, tools and records, the guide to Agent Assurance test scenarios shows how to write the criteria a staging run is graded on.