Open-source LLM observability tools compared

Which open-source LLM observability tool fits your team

If your priority is a permissive license for the core product and a self-hosted deployment with the broadest feature set, Langfuse and Opik are the strongest starting points, while Arize Phoenix suits teams whose license policy accepts source-available code and whose use does not involve offering Phoenix to third parties as a hosted service. Langfuse is open core: code outside its ee directories is MIT, and code inside them is under a commercial license. Opik is Apache-2.0, and its README states the full platform, including tracing, evaluations and prompt management, can be self-hosted without a commercial license. Phoenix is licensed under the Elastic License 2.0, which is source-available and not an OSI-approved open source license.

Your license policy should decide the shortlist before features do. Legal teams should read the Langfuse LICENSE file and the Phoenix LICENSE file together with their own counsel, then check which Langfuse features need an Enterprise license key, such as project-level RBAC, audit logs and SCIM, against the access controls your auditors expect. Phoenix documents free self-hosting with no feature limitations, which may matter more to a team that needs everything in one place than the license wording does.

Operating capacity is the other deciding factor. Langfuse runs web and worker containers with PostgreSQL, ClickHouse, Redis or Valkey and S3-compatible storage, and its scaling guide lists ClickHouse at 2 CPU and 8 GiB as a minimum. Opik also depends on ClickHouse, MySQL and Redis. Phoenix starts on SQLite and can use PostgreSQL, which keeps a pilot simple. Ask your platform team which of these data stores it already runs and supports, and confirm the sizing for your expected trace volume before you commit to any of the three.

Which open-source LLM observability tool fits which team situation

This table matches each common team situation to the observability tool whose supplied facts fit it best, along with the condition under which another option would be the better pick. Read it as a starting shortlist, then confirm the license, deployment and gating details against your own requirements and the vendor documentation.

Scenario	Best fit	Why, and when another option wins
Small team wants tracing and prompt management on a single VM for testing	Langfuse	Docker Compose on a single VM is documented for testing, with no high availability, and core features are available in the MIT-licensed version. Choose Opik if you prefer a single Docker Compose start via its opik.sh script and ClickHouse, MySQL and Redis; Phoenix is simpler still if you only need local tracing and evaluation on SQLite.
Platform team deploying to Kubernetes for production	Langfuse	Langfuse documents Kubernetes deployments with Helm or Terraform on AWS, Azure and GCP, and lists per-component minimum resources. Opik also offers Helm charts, so Opik becomes the better pick if you want the MIT-free Apache-2.0 platform with ClickHouse, MySQL and Redis already in your stack.
Policy requires OSI-approved licenses with no paid gating of core features	Opik	Opik is Apache-2.0 and its README states the full platform, including evaluations and prompt management, can be self-hosted without a commercial license. Langfuse core is MIT, but its ee directories carry a commercial license, so confirm that no ee code is needed for your required features.
Team already uses OpenTelemetry or OpenInference instrumentation	Arize Phoenix or Opik	Phoenix uses OpenInference on OpenTelemetry, the same instrumentation works with Arize AX, and Opik supports OpenTelemetry directly. Phoenix's Elastic License 2.0 bars offering it as a hosted service to third parties, so pick Opik if that restriction or the lack of OSI approval conflicts with your policy.
Team needs air-gapped deployment	Arize Phoenix	Phoenix documentation states traces, prompts and data stay in your infrastructure, including air-gapped deployments, with no license fees or usage limits. Confirm the air-gapped procedure for Langfuse or Opik with each vendor, since their facts do not address it, and check that Elastic License 2.0 terms suit your use.
Team needs RBAC, audit logs or SCIM from day one	Phoenix or Langfuse Enterprise	Phoenix self-hosting supports OAuth2, LDAP and local accounts with role-based permissions, which covers many access needs without a license key. Langfuse gates project-level RBAC, audit logs and SCIM behind an Enterprise license key, so budget for that license and ask the vendor for its terms before committing.

Langfuse, Opik and Arize Phoenix: what each tool is and how it is licensed

Langfuse, Opik and Arize Phoenix all cover tracing, evaluation and prompt management, but their license terms decide who can run them and how. Each card names the license, the condition under which that term matters and the operating footprint it implies for your team.

Langfuse: open core license

Langfuse is open core. Code outside its ee directories is MIT licensed, and code inside ee/, web/src/ee/ and worker/src/ee/ falls under a separate commercial license. Langfuse states that all core features and APIs are available in the MIT open source version without limits, and self-hosted deployments run the same codebase as Langfuse Cloud. Check which features your team needs before you build on them, because RBAC roles, audit logs, data retention and SCIM need an Enterprise license key.

Langfuse self-hosting footprint

A self-hosted Langfuse runs a Web container for the UI and APIs and a Worker container for asynchronous event processing. Both depend on PostgreSQL, ClickHouse, Redis or Valkey, and S3-compatible blob storage. Langfuse documents Docker Compose on a single VM for testing without high availability, and Kubernetes with Helm or Terraform for production on AWS, Azure and GCP. Ask who will operate ClickHouse, since it has the largest memory requirement in the scaling guide and the heaviest upgrade path.

Opik: Apache-2.0 with full self-hosting

Opik is Apache-2.0 licensed, and 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. Comet maintains it in the comet-ml GitHub organization. Local use runs through the opik.sh script with Docker Compose, and production runs on Kubernetes with Helm charts. Its stack is ClickHouse, MySQL and Redis, so confirm that your database team will support MySQL alongside any ClickHouse you already run.

Opik hosted option on Comet.com

Opik is also offered as a hosted service on Comet.com, so you can choose between running it yourself and using a vendor-managed service. Choosing the hosted route moves operation of the ClickHouse, MySQL and Redis stack to Comet. Before you decide, confirm where trace data is stored, who can access it and whether your compliance team accepts a hosted option for regulated workloads. The README's 40M+ traces per day figure describes stated platform scale, not a commitment for your deployment.

Phoenix: Elastic License 2.0

Phoenix is licensed under the Elastic License 2.0, which makes it source-available but is not an OSI-approved open source license. ELv2 forbids providing the software to third parties as a hosted or managed service and forbids circumventing license key functionality. Internal use inside your own infrastructure is the case the license covers most directly, so the question is whether you plan to offer Phoenix as a service to other parties. Have legal review the LICENSE file against that plan before adoption.

Phoenix self-hosting without feature limits

Phoenix's self-hosting docs say it is free to self-host with no feature limitations, no license fees and no usage limits, and that traces, prompts and data stay in your infrastructure, including air-gapped deployments. Self-hosted Phoenix supports OAuth2, LDAP and local accounts with role-based permissions. It starts on a file-based SQLite database by default, so set PHOENIX_SQL_DATABASE_URL to a PostgreSQL connection before any shared team use.

Which Langfuse features need an enterprise license key

Langfuse states that all core features and APIs are available in the MIT-licensed open source version without limits, so tracing, evaluation and prompt management do not depend on a license key. The line that matters for governance sits elsewhere. Self-hosted Langfuse asks for an Enterprise license key before you can use project-level RBAC roles, protected prompt labels, data retention policies, audit logs, server-side data masking, UI customization, organization creators, the org management API with SCIM and the instance management API. Only the code inside the ee directories carries the commercial license, so the boundary is set by features, not by the codebase you deploy.

Before you choose, map each item to a written control in your governance requirements. If your access reviews depend on project-level roles, your retention rules require enforced deletion periods, your prompt changes need protected labels, or your identity team must provision users through SCIM, the open source edition will not meet those needs on its own. If none of them is required, the open source edition may be sufficient, and you should confirm that with your security and compliance leads. Check the current list on the Langfuse license key documentation, since features move between tiers over time.

The Self-Hosted Enterprise plan is custom-priced and adds a named support engineer, solutions architect access and a support SLA. Those are commercial services, not extra product functions, so ask the vendor what each includes, what response commitments are written into the SLA and whether they apply to your deployment model. Include the license terms, support scope and renewal conditions in any quote you request, and compare them against the effort your own team will carry for upgrades, backups and monitoring under the open source edition.

How open-source LLM observability tools compare on features and architecture

This table compares Langfuse, Opik and Arize Phoenix on license, feature gating, instrumentation, data stores, evaluation, prompt management, authentication and deployment. Read each row as a question to answer for your own environment, and treat any cell marked to confirm as a point to check with the vendor before you commit.

Area	Langfuse	Opik	Arize Phoenix
License	MIT for most of the repository, with a commercial license for enterprise directories	Apache-2.0, with the full platform self-hostable without a commercial license	Elastic License 2.0, source-available and not OSI-approved
License scope	Code under the ee directories is under a separate enterprise license	Stated in the README to cover server, web app, tracing, evaluations and prompt management	Forbids offering Phoenix to third parties as a hosted or managed service
Feature gating	Project-level RBAC, protected prompt labels, retention policies, audit logs, data masking and SCIM need an enterprise license key	Core features described as self-hostable without a commercial license; confirm any gated items with Comet	Self-hosting docs state no feature limitations; confirm the terms that apply to your use
Instrumentation standard	OpenTelemetry support documented alongside Langfuse SDKs	OpenTelemetry, native integrations with LangChain, LangGraph, LlamaIndex, CrewAI and 60+ frameworks, and the @track decorator	OpenTelemetry-based tracing with OpenInference instrumentation, which also works with Arize AX
Data stores	PostgreSQL, ClickHouse, Redis or Valkey and S3-compatible blob storage	ClickHouse, MySQL and Redis; the README states 40M+ traces per day	SQLite by default; PostgreSQL through PHOENIX_SQL_DATABASE_URL or separate connection variables
Evaluation features	Evaluation and experiments documented; confirm which judge models and metrics ship in your edition	LLM-as-a-judge metrics for hallucination, moderation and RAG, plus online evaluation rules	LLM-based evaluations, versioned datasets and experiments
Prompt management	Prompt management with protected labels gated behind the enterprise key	Prompt management with a playground	Prompt management listed in the README; confirm versioning and approval workflow
Authentication	RBAC roles and SCIM provisioning need the enterprise license key; confirm SSO options for your IdP	Confirm SSO and role model for self-hosted installs with Comet	OAuth2, LDAP and local accounts with role-based permissions
Deployment options	Docker Compose on a single VM for testing; Kubernetes with Helm or Terraform on AWS, Azure and GCP for production	Docker Compose through opik.sh for local use; Kubernetes with Helm charts for production	Terminal, Docker, Kubernetes, Helm, AWS CloudFormation, Azure ARM and other hosted templates

What self-hosting each tool requires, by environment

A single virtual machine is the fastest way to evaluate these tools side by side with traces from your own applications. Each vendor's testing path trades resilience for speed, so use it as a sandbox and keep production traces off it. Langfuse documents its self-hosting path with Docker Compose on one VM, and that setup has no high availability.

Langfuse Docker Compose: The self-hosting docs position Docker Compose on a single VM for testing. A host failure stops ingestion, so do not treat this setup as a durable store for production traces.
Langfuse minimums: The scaling guide lists 2 CPU and 4 GiB for web, worker and PostgreSQL, 1 CPU and 1.5 GiB for Redis or Valkey, and 2 CPU and 8 GiB for ClickHouse. These are vendor minimums, so size them against your trace volume.
Opik local install: The opik.sh script starts the stack with Docker Compose for local use. Opik runs ClickHouse, MySQL and Redis, so check the host capacity for all three before you size the VM.
Phoenix quick start: Phoenix can run from the terminal or Docker and starts with a file-based SQLite database by default. Move to PostgreSQL through PHOENIX_SQL_DATABASE_URL once the test grows beyond one user.

Check whether your test VM's backups, disk growth and upgrade path match what production will need.

How storage choices and instrumentation standards affect switching later

The instrumentation layer is the main lock-in point in LLM observability, more than the backend you pick today. OpenTelemetry and OpenInference are open standards, and Phoenix states that the same OpenTelemetry and OpenInference instrumentation works with both Phoenix and Arize's managed platform. Opik and Langfuse also support OpenTelemetry. Code written against those standards can usually change backends with fewer edits. Framework-specific callbacks and proprietary SDK calls scattered through application code raise the cost of moving, because every call site has to be rewritten and retested. Before you commit, ask each vendor which OpenTelemetry attributes it maps to its own data model and whether custom metadata, scores and prompt versions survive a move.

Each tool also depends on its own data stores, and those choices shape operating cost and exit options. Self-hosted Langfuse runs web and worker containers on PostgreSQL, ClickHouse, Redis or Valkey and S3-compatible blob storage. Opik uses ClickHouse, MySQL and Redis. Phoenix starts with SQLite by default and can use PostgreSQL through PHOENIX_SQL_DATABASE_URL. Langfuse's v3 to v4 upgrade moved to an observations-first ClickHouse data model and advised about 3x ClickHouse disk headroom when backfilling historic data, so a storage plan that looks adequate for steady state may not cover a migration. Ask each vendor for its upgrade and backfill guidance in writing, and confirm the ClickHouse version it requires.

Plan for data export and retention before you choose a store, not after traces have accumulated. Decide how long traces, prompts and evaluation results must be kept, who can delete them, and how deletion is evidenced. Ask whether each product offers bulk export through its API or database, in what format, and whether prompt versions and evaluation scores export with the traces that reference them. Langfuse's data retention policies are an Enterprise license feature, so confirm whether your retention requirement needs that license. Test a full export and re-import into a scratch environment once, because the first real migration is a poor time to learn the format.

How to choose and pilot an LLM observability tool

This sequence moves a team from license policy to a written scope, so that the shortlist of Langfuse, Opik and Arize Phoenix is tested against the team's own requirements before any vendor quote is requested.

Set the license policy before comparing features
Start by deciding which license terms your organization accepts: OSI-approved open source only, source-available licenses such as the Elastic License 2.0, or open-core products where paid features are acceptable. Legal or procurement owns this decision, and the output is a short written policy. Phoenix is licensed under ELv2, which is source-available rather than OSI-approved, and it forbids offering the software to third parties as a hosted or managed service. Langfuse's core is MIT outside its ee directories, and Opik is Apache-2.0. Confirm with your counsel how each license applies to your internal use, and record the decision so that later steps can exclude tools that fail it.
List the governance features you must have
Have the security and platform leads list the governance controls the tool must provide in your environment, such as project-level RBAC, audit logs, SCIM provisioning, server-side data masking, data retention policies and SSO. Mark each as required, preferred or not needed. Then check each candidate's documentation for that feature and note whether it is in the free edition or behind a license key. For Langfuse, the self-hosting docs list several of these as Enterprise license key features. For Phoenix, the self-hosting docs describe OAuth2, LDAP and local accounts with role-based permissions. The output is a feature matrix with a source link for each cell, and any cell you cannot confirm is marked for vendor follow-up.
Decide the deployment target
Choose where the tool will run: a single virtual machine for evaluation, Kubernetes for production, or an air-gapped network. The platform team owns this decision because it sets the operating burden. Langfuse documents Docker Compose on a single VM for testing without high availability, and Kubernetes with Helm or Terraform for production. Opik uses Docker Compose through its opik.sh script for local use and Helm charts for production. Phoenix documents many targets, including Docker, Kubernetes, Helm and air-gapped deployments. The output is one named target per candidate, plus a note on whether your cluster, cloud accounts or network rules support that target without exceptions.
Pick the instrumentation standard
Decide how application code will emit traces, since this choice determines how easily you can switch tools later. Ask the engineering lead whether the team needs OpenTelemetry as the transport, OpenInference semantic conventions, or a framework-specific SDK. Opik supports OpenTelemetry and offers native integrations with frameworks such as LangChain and LlamaIndex, plus a @track decorator. Phoenix uses OpenInference instrumentation, which the README says works with both Phoenix and Arize AX. Langfuse documents OpenTelemetry ingestion. The output is a written instrumentation standard that names the libraries and the trace attributes your teams will use, so that the same instrumentation can be sent to each candidate during the pilot.
Run one application through two candidates
Choose one representative application, ideally one with a retrieval step and one agent or multi-step flow, and instrument it for two candidate tools at the same time. The engineering lead and an evaluation owner run the same prompts and the same test cases through both. Compare what each tool captures, how traces appear for multi-step calls, how evaluations and prompt versions are managed, and how much work the instrumentation required. Record the results in a shared table. The pilot is complete when both candidates have received identical traffic and the team has written down which gaps were caused by configuration and which were caused by the product.
Check upgrade paths and data stores against your capacity
Before choosing, have the platform team confirm that it can run every data store the tool requires and can complete its upgrades. Langfuse self-hosting uses PostgreSQL, ClickHouse, Redis or Valkey and S3-compatible storage, and its v3 to v4 upgrade guide lists version floors for ClickHouse, PostgreSQL and Redis, plus added disk headroom during backfill. Opik uses ClickHouse, MySQL and Redis. Phoenix starts on SQLite by default and can use PostgreSQL. Ask each vendor for its upgrade guides and the database versions each release requires, then compare them with the versions your team already operates. The output is a dependency list per candidate and a named owner for every store.
Write the requirements into a scope and request quotes
Turn the results of the earlier steps into a written scope that states the license policy, required governance features, deployment target, instrumentation standard, data stores, upgrade commitments and the application set for production. Send the same scope to each vendor and to any implementation partner you consider. Ask each party to state what is included in a license or subscription, what support levels are offered and what they cost, and which items would be separate services. Costs recur through licenses or support tiers, infrastructure for the data stores and storage growth, and internal operating time. Vendors may not publish prices, so the scope is what makes quotes comparable. Done means every candidate has answered the same written requirements.

What teams ask before self-hosting LLM observability

What does self-hosting Langfuse, Opik or Phoenix actually cost?

The software licenses are not the main line item for the free tiers: Langfuse's core features are MIT-licensed without limits, Opik is Apache-2.0 and Phoenix has no license fees for self-hosting. The recurring costs are the infrastructure (compute, storage and databases such as PostgreSQL, ClickHouse, Redis or Valkey, and Opik's MySQL), the staff time to operate and upgrade it, and any paid support or enterprise license you add. Infrastructure and staff time recur every month, while setup is largely one-time. Costs rise with trace volume, retention length and how much high availability you need. Ask any vendor or partner for a written scope that separates infrastructure sizing, staff hours, license fees and support tiers, and states what is one-time and what recurs.

How much operating effort does each tool need in-house?

Effort depends mostly on the number of stateful services you run and how much ingestion you expect. Langfuse self-hosting runs a web and a worker container alongside PostgreSQL, ClickHouse, Redis or Valkey and S3-compatible storage, and its docs separate a single-VM Docker Compose setup for testing (no high availability) from Kubernetes deployments for production. Opik uses Docker Compose for local use and Helm charts on Kubernetes for production, with ClickHouse, MySQL and Redis behind it. Phoenix starts on SQLite by default and can move to PostgreSQL, so its footprint is the smallest of the three for a pilot. Confirm with each project's current docs how many services production needs and who owns backups and retention.

Can our team deploy one of these tools without outside help?

A team with Kubernetes, PostgreSQL and ClickHouse administration experience and some OpenTelemetry instrumentation skill can usually deploy a pilot alone, while production clusters with high availability, backup and upgrade routines are harder to staff without that depth. Langfuse production setups need ClickHouse and Redis or Valkey administration. Opik requires ClickHouse and MySQL knowledge. Phoenix needs the least database work but still requires instrumentation with OpenTelemetry and OpenInference. If your team lacks these skills, an implementation partner can work from a written scope covering deployment, hardening, backup and documentation, and you should ask for named deliverables and handover terms before work starts.

What does Phoenix's Elastic License 2.0 prohibit?

Phoenix is licensed under the Elastic License 2.0, which forbids providing the software to third parties as a hosted or managed service and forbids circumventing license key functionality. Running Phoenix inside your own infrastructure for your own teams is the use the license permits, and the self-hosting docs state there are no feature limits or usage fees. Offering Phoenix as a service to customers, or building a managed offering on top of it, falls outside that permission. ELv2 is source-available, not an OSI-approved open source license, so have your legal team review the text in the Phoenix LICENSE file before you plan any external product use.

Do the free self-hosted tiers include the features we need?

For Langfuse, all core features and APIs are in the MIT-licensed version without limits, but several governance features need an Enterprise license key: project-level RBAC roles, protected prompt labels, data retention policies, audit logs, server-side data masking, UI customization, and SCIM-based organization management. Opik's README states the full platform, including evaluations and prompt management, can be self-hosted without a commercial license. Phoenix is free to self-host with no feature limitations and supports OAuth2, LDAP and local accounts with role-based permissions. Make a list of your access control, retention, audit and masking requirements, then check each against the current license key documentation before you assume a free tier meets them.

How long does an upgrade or migration take?

The timeline depends on your version, data volume and how much historic data you backfill, so no fixed duration applies. Langfuse says minor updates within a major version are non-disruptive and run database migrations at startup, while major upgrades follow separate guides. The v3 to v4 guide requires ClickHouse 25.12 or later, PostgreSQL 15 or later and Redis 7.0 or later, moves to an observations-first data model, and advises about 3x ClickHouse disk headroom when backfilling. Opik and Phoenix publish release notes on their GitHub release pages. Read the relevant upgrade guide and test it on a copy of your data before you set a schedule, and ask for the upgrade plan and rollback steps in your written scope.

Which skills and services should a written scope cover?

A useful scope lists the deployment target, the instrumentation work for each application, the storage and retention design, the access and SSO setup, backup and restore testing, and the handover documentation. Ask who pays for each item (your staff, a partner, or the vendor's enterprise support) and what recurs afterward, such as upgrades, patching and on-call. Engagements from DeployOpen are typically fixed-scope, with scope, deliverables and timelines agreed in writing before work starts, and ongoing support and upgrades are available as retainers. Ask any provider for a quote that follows from that written scope.

How DeployOpen scopes and delivers LLM observability selection and implementation

DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For LLM observability, that means choosing a tracing and evaluation stack that fits your license constraints, storage standards and operating capacity, then running it as part of your infrastructure.

How we scope

Written scope names which tracing, evaluation and prompt management features are in and out of the engagement.
We record which license terms apply to each candidate, including any enterprise-licensed features your team needs.
Scope captures where traces, prompts and evaluation data must reside, including any air-gapped requirement.
Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.

How we build

We deploy the chosen platform into your environment using the documented self-hosting topology for your target.
We instrument sample applications using OpenTelemetry-based approaches so trace data flows into the chosen backend.
We configure storage, databases and blob backends and document the sizing decisions behind them.
We run security testing against the deployment, covering access controls, authentication and exposed endpoints.

How we hand over

Handover includes architecture documentation, configuration records and runbooks for upgrades and backups.
We document which features depend on a license key so your team knows what is in use and why.
Compliance readiness evidence is prepared for your assessors, though independent auditors issue any audit reports.
Your team receives operating guidance for routine tasks, major version migrations and capacity monitoring.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover.
Retainer scope for observability platforms can cover version upgrades, migration reviews and backup checks.
Continuous testing can be added to re-verify access controls after platform or instrumentation changes.
Ask for the retainer scope and its deliverables in writing before committing to ongoing work.