Which open-source Arize alternative fits your team
Langfuse, Opik and Arize Phoenix are the main self-hosted options for teams moving LLM tracing and evaluation off Arize AX, and each fits a different team. Langfuse is open core: code outside its ee directories is MIT licensed, while some advanced features need an enterprise license key. 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. Phoenix is the Arize-built option, but it is licensed under the Elastic License 2.0, which is not an OSI-approved open-source license and forbids offering the software to third parties as a hosted or managed service. If your legal team requires OSI-approved licensing or plans to resell or host the tool for other parties, check that point first.
Teams usually start looking at alternatives for a renewal, a data residency requirement, a licensing change or a wish to avoid lock-in. Arize does not present this as a question of fault. Arize maintains Phoenix, an open-source tracing and evaluation tool built on OpenTelemetry and OpenInference, and Arize AX, a managed enterprise platform built on the same open standards. Arize AX also has a self-hosted option that runs on Kubernetes in GCP, AWS, Azure, IBM Cloud, OpenShift or Rancher environments. The decision is therefore about fit: which product, which deployment model, and how much of the operating burden your team wants to carry.
Before you shortlist, confirm which of Arize's offerings you actually use today, since Phoenix, Arize AX and its self-hosted option have different licensing, support and operating profiles. Then list the requirements that drive the choice: the license terms your counsel accepts, whether you need enterprise features such as single sign-on or audit logging, the cloud and region where traces must stay, and the platform engineering skills you can staff. Those answers narrow the three open-source candidates quickly, and they set the questions to put to each vendor and to any implementation partner before you commit.
Langfuse, Opik and Phoenix compared as self-hosted options
Each option below can be run inside your own infrastructure as a replacement or complement to Arize AX. The licenses differ in ways that matter for procurement, so read each card's license note before you shortlist. Trace data, evaluation results and prompt history stay in your environment in every case.
Langfuse: open core with a license boundary
Langfuse is open core. Code outside its ee directories is MIT licensed, while code inside them sits under a separate commercial license, and some advanced features need an enterprise license key. For a self-hosted deployment you run Docker Compose for testing or Kubernetes with Helm for production, and you operate PostgreSQL, ClickHouse, Redis or Valkey, and S3 or blob storage. The trade-off is a broader data stack to run in exchange for a mature tracing and prompt management model. Confirm which features your evaluation needs sit inside the enterprise license before you commit.
Opik: fully open under Apache-2.0
Opik, built by Comet, is licensed under Apache-2.0, 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. That makes it the simplest option to justify to a legal team that wants no feature gated behind a commercial key. The trade-off is that you own the operational work of upgrades, backups and scaling for a platform whose vendor offers the commercial path. Ask Comet for the current deployment guide and the supported container and Kubernetes footprint before sizing hardware.
Arize Phoenix: source-available, not open source
Phoenix is built on OpenTelemetry and OpenInference, which eases instrumentation, but it is licensed under the Elastic License 2.0. That license is not OSI-approved and forbids offering the software to third parties as a hosted or managed service. Internal self-hosting is generally the use case it permits, yet a platform team that sells or hosts LLM observability to other business units or customers must have counsel confirm the fit. The trade-off is strong standards alignment with a license that needs legal review. Read the license text directly before you rely on it.
Arize AX self-hosting as the retained path
If your need is a like-for-like enterprise platform rather than an open tool, Arize AX also has a self-hosted option that runs on Kubernetes in GCP, AWS, Azure, IBM Cloud, OpenShift or Rancher environments. Staying on this path keeps the existing data model and workflows while moving the hosting into your environment. The trade-off is that you keep the commercial relationship and its license terms. Ask Arize which self-hosted deployment, support and upgrade terms apply to your contract before comparing it with the open options.
Which open-source option covers each Arize capability
This table maps the main Arize capabilities to Langfuse, Opik and Arize Phoenix, with Arize AX's self-hosted option included for reference. Read each row as a starting point: where a cell says to confirm, check that feature against the project's current documentation before you commit to a migration plan.
| Capability | Langfuse | Opik | Arize Phoenix |
|---|---|---|---|
| Tracing and OpenTelemetry ingestion | Traces from SDKs and OpenTelemetry-compatible instrumentation; confirm OTLP endpoint details for your version | Tracing via SDKs and OpenTelemetry integration; confirm supported span attributes with the Opik README | Built on OpenTelemetry and OpenInference, so instrumented apps can send traces with minimal rework |
| OpenInference semantic conventions | Not a native requirement; mapping of OpenInference attributes should be tested on your traces | Confirm compatibility with OpenInference span attributes before migrating | Native fit, since Phoenix and Arize AX share the OpenInference standard |
| LLM evaluations | Evaluation scores and LLM-as-a-judge workflows; confirm which evaluators are built in | Evaluation metrics and test suites included in the self-hosted platform | Evaluation tooling included; confirm the evaluator library for your use case |
| Prompt management | Prompt versioning and management; confirm the current feature set | Prompt management included in the self-hosted platform | Confirm prompt management scope in current Phoenix docs; it may differ from Arize AX |
| Datasets and experiments | Dataset and experiment support; confirm how runs compare across versions | Datasets and experiment tracking; confirm comparison views in your version | Datasets and experiments supported; confirm parity with Arize AX experiment workflows |
| Online evaluation and annotation queues | Confirm whether online evaluation and annotation queues are available in your edition | Confirm online evaluation and annotation support against current docs | Confirm online evaluation and annotation queue support; treat as a possible gap |
| Dashboards and alerting | Dashboards available; confirm native alerting or plan external alerting through Prometheus or your monitoring stack | Dashboards available; confirm alerting options and any external integrations | Dashboards available; alerting usually runs through your existing monitoring tools, so confirm |
| Self-hosted deployment | Docker Compose for testing, Kubernetes with Helm for production; needs PostgreSQL, ClickHouse, Redis or Valkey, and S3 or blob storage | Full platform self-hostable without a commercial license, per the project README | Self-hostable; Elastic License 2.0 bars offering it to third parties as a hosted service |
| Arize AX self-hosted option (reference) | Not applicable | Not applicable | Arize AX self-hosts on Kubernetes in GCP, AWS, Azure, IBM Cloud, OpenShift or Rancher |
What the Elastic License 2.0 means for Phoenix
Phoenix is licensed under the Elastic License 2.0, and the license matters more than most tooling choices because it governs what you may do with the software, not only what it costs. The Elastic License 2.0 is not an OSI-approved open-source license, and it forbids offering the software to third parties as a hosted or managed service. For most teams the typical case is internal use: running Phoenix in your own infrastructure to trace and evaluate your own LLM applications. Read the Phoenix LICENSE file directly, since it is the controlling text, and have your legal team confirm that internal self-hosting fits your use.
The license becomes a decision point if you plan to resell Phoenix, embed it in a product you sell, or operate it as a managed observability service for customers. In those cases the hosted-service restriction applies, and a managed offering built on Phoenix would need a separate arrangement with the licensor or a different tool. Ask legal counsel to review the exact use case, including internal platform teams that serve several business units, since the boundary between internal and third-party use depends on how the service is structured. Document that review before rollout.
Langfuse and Opik differ in what their licenses permit. Code outside Langfuse's ee directories is MIT licensed, and the self-hosting documentation states that some advanced features need an enterprise license key, so confirm which features your team needs are in the open part. Opik is Apache-2.0 licensed, and its README states the full platform can be self-hosted without a commercial license. Neither license restricts offering the software to customers in the way Elastic License 2.0 does, which is a legal difference to weigh alongside features and operating cost. Confirm current terms with each vendor before you commit.
Which option fits by situation
Teams with residency or sovereignty requirements usually need traces, prompts and evaluation data to stay in their own cloud account, a data center or an air-gapped network. Langfuse and Opik both run inside your infrastructure, and Langfuse documents a Kubernetes deployment with Helm for production. Arize AX also has a self-hosted option that runs on Kubernetes in several cloud and private environments, so the decision often comes down to which stack your platform team can operate.
- Langfuse footprint: Plan for PostgreSQL, ClickHouse, Redis or Valkey, and S3 or blob storage alongside the application.
- Opik footprint: Confirm the server, web application and storage components against the Opik repository before sizing.
- Arize AX self-hosting: Confirm which Kubernetes environments and support terms apply to your contract.
- Phoenix in your network: Phoenix can run locally for internal teams, but its license limits offering it as a hosted service to third parties.
- Telemetry egress: Verify that no feature sends data outside your network by default.
Ask each vendor to document every outbound connection and where backups and logs are stored.
Legal and procurement teams often need a license that permits internal use, modification and redistribution without a usage negotiation. Opik is Apache-2.0 licensed, and its README states the full platform can be self-hosted without a commercial license. Langfuse is open core: code outside its ee directories is MIT licensed, while code inside them is under a separate commercial license and some advanced features need an enterprise license key.
- Opik: Apache-2.0 covers the full platform as described in its README.
- Langfuse: MIT applies outside the ee directories, so map which features you use against those directories.
- Phoenix: Elastic License 2.0 is source-available and is not an OSI-approved open-source license.
- Phoenix hosting limit: ELv2 forbids offering the software to third parties as a hosted or managed service, which matters if you resell an LLM platform.
- Feature gating: Confirm which enterprise features, such as SSO or audit logging, you need and whether they require a key.
Have counsel read the LICENSE file for the exact version you plan to deploy, since terms can change between releases.
Teams already on Arize AX often want to cut recurring subscription cost or reduce how much trace volume goes to a managed service. Because Phoenix and Arize AX are built on OpenTelemetry and OpenInference, instrumentation written for one can often be pointed at another with configuration changes rather than a rewrite. The main cost question is how much of the spend is platform fees versus the infrastructure and operations you would take on.
- Self-hosted costs: You pay for compute, storage, database services and the engineers who upgrade and back up the stack.
- Recurring versus one-time: Migration effort is largely one-time, while hosting and operations recur every month.
- Volume drivers: Trace retention, sampling rate and evaluation frequency change storage and compute costs most.
- Dual running: Plan a period where both platforms receive traces so you can compare results before cutting over.
- Quote request: Ask Arize for the self-hosted AX scope, support terms and license conditions in writing.
Confirm the exact contract terms for your current Arize AX agreement before planning a move.
Teams that want tracing and a gateway under their own control often pair Langfuse with LiteLLM. LiteLLM provides a self-hosted server with one OpenAI-compatible endpoint across 100+ providers, along with virtual keys, budgets, rate limits, load balancing, fallbacks and logging to Langfuse. This keeps routing, spend controls and traces in your environment without relying on a hosted proxy.
- Gateway features: Virtual keys, budgets, rate limits, spend tracking and fallbacks are part of the proxy.
- Observability link: LiteLLM can send logs to Langfuse, OpenTelemetry and Prometheus.
- Enterprise features: SSO and SAML, audit logs and multi-team management sit in the enterprise directory under a separate license.
- Two services to run: You operate both the gateway and the tracing platform, each with its own upgrades.
- Scale planning: Load test the gateway against your expected request volume before production.
Confirm which LiteLLM enterprise features you need and check the LICENSE file for the enterprise directory before you finalize the design.
What self-hosted Arize alternatives cost to run
This table separates the Arize AX subscription from the infrastructure, implementation, migration and support costs of running Langfuse, Opik or Phoenix yourself. Read each row for who is paid, whether the cost is one-time or recurring, and what moves it up or down. No prices are listed, so use the questions in the last row to compare written quotes.
| Cost component | Who is paid or who pays | One-time or recurring | What drives it up or down |
|---|---|---|---|
| Arize AX subscription or license | Arize, under your agreement with them | Recurring | Contract tier, volume terms and renewal terms. Ask Arize for the current pricing model in writing. |
| Phoenix or Opik software | No license fee for the open-source core (Opik is Apache-2.0 and Phoenix is Elastic License 2.0) | None for software | Whether you need features outside the open core. Confirm the license terms for your use case with counsel. |
| Langfuse enterprise license key | Langfuse, only if you need advanced features in the commercial directories | Recurring if required | Which advanced features your team needs. Confirm whether your required features need the key. |
| Kubernetes and cloud compute | Your cloud provider or data center team | Recurring | Trace volume, replica count and high availability design. Ask for a sizing estimate based on your expected volume. |
| Data stores: PostgreSQL, ClickHouse, Redis or Valkey, S3 | Your cloud provider, or your managed service vendor | Recurring | Trace volume and retention period, which grow storage and query load. Set retention early and review it quarterly. |
| Implementation and migration of instrumentation | Internal engineers or an implementation partner such as DeployOpen, under a written scope | One-time | Number of services and code paths sending traces. OpenTelemetry-based instrumentation can reduce rework when you move backends. |
| Upgrades, backups and support | Internal platform team or a retainer partner | Recurring | Release frequency, change control rules and whether you run high availability. Agree response expectations in the contract. |
| What to request in a written quote | Any vendor or partner you evaluate | Both | Ask for itemized scope, the license terms covering your use, sizing assumptions, retention settings, upgrade responsibilities and what is excluded. |
What you give up and how teams work around it
Moving from Arize AX to a self-hosted stack trades managed convenience for ownership. The cards below cover the gaps teams most often find after a pilot, and a practical workaround for each. Confirm current feature status with each vendor before you commit, because open-core boundaries move between releases.
Managed uptime and vendor support
Arize AX runs as a managed enterprise platform, so the vendor operates the service and its availability. With Phoenix or Opik on your own cluster, your team owns the database, storage, upgrades and incident response. Ask whether a support retainer from an implementation partner, or a support agreement with the vendor, covers the tracing path you depend on, and write down who gets paged when trace ingestion stops.
Enterprise SSO and audit features
Single sign-on, SAML and audit logging are often gated behind enterprise editions. Langfuse states that some advanced features need an enterprise license key, and Phoenix and Opik feature sets for identity and audit change over time. Confirm in writing which of these your identity and audit requirements need. A common workaround is an identity-aware reverse proxy in front of the UI, with access logs captured at the proxy layer.
Managed scale and operations
Managed platforms absorb trace volume growth by scaling their own infrastructure. Self-hosted Langfuse depends on PostgreSQL, ClickHouse, Redis or Valkey, and S3 or blob storage, and each component needs capacity planning, backups and monitoring. Plan for trace retention and storage growth early, and ask your platform team to load test ingestion at your expected peak before production cutover.
Built-in evaluators and dashboards
Managed products often ship ready-made evaluator templates and dashboards. Open-source tools cover tracing and evaluation, but the breadth of out-of-the-box evaluators and dashboard templates differs by project and version. Inventory the evaluators and views your team uses today, then check each one against the current open-source release. Gaps are usually filled with custom dashboards built on exported trace data and scheduled evaluation jobs.
Ownership of upgrades
With a self-hosted deployment, your team decides when to upgrade the tracing server, the database schema and the instrumentation libraries. Schema changes and breaking releases need a tested rollback path and a staging environment that mirrors production. Set a written upgrade cadence, pin versions in your Helm or Compose configuration, and budget engineering time for upgrades as a recurring cost rather than a one-off project.
How a migration off Arize runs, step by step
The sequence moves traces, prompts, evaluations and datasets from Arize into a self-hosted platform in stages, so each step ends with a check that the data and workflows match before the next one starts. The result is a documented cutover with Arize decommissioned and its data deletion confirmed in writing.
Inventory traces, prompts, evaluations, datasets and users
List every project, trace stream, prompt version, evaluation template, labeled dataset and user or team with access in your Arize workspace. Record which applications send traces, which OpenTelemetry or OpenInference instrumentation they use, and which dashboards or alerts depend on them. Assign an owner to each item. The step is complete when the inventory is signed off by the platform team and the application owners, and every item is marked keep, rebuild or retire.
Choose the target and confirm license terms
Compare Langfuse, Opik and Arize Phoenix against the inventory. Phoenix is licensed under the Elastic License 2.0, which is not OSI-approved and forbids offering the software to third parties as a hosted or managed service, so confirm with your legal team whether your use is permitted. Langfuse keeps code outside its ee directories under MIT and states that some advanced features need an enterprise license key. Opik is Apache-2.0 and its README states the full platform can be self-hosted without a commercial license. The step closes with a written decision that names the license terms reviewed.
Stand up the self-hosted stack in your infrastructure
Deploy the chosen platform in your own cloud account, data center or air-gapped network. Langfuse, for example, uses Docker Compose for testing and Kubernetes with Helm for production, and depends on PostgreSQL, ClickHouse, Redis or Valkey, and S3 or blob storage. Set up backups, encryption, identity integration, network boundaries and monitoring for those components as part of the build. The step is complete when the platform passes a health check, the backups restore in a test, and access is limited to the groups named in the inventory.
Redirect OpenTelemetry exporters in a pilot
Choose one non-critical application and point its OpenTelemetry or OpenInference exporter at the new endpoint, keeping the Arize exporter available for rollback. Because the instrumentation follows the same open standards, the change is usually limited to endpoint and credential configuration, but confirm that span attributes, token counts and parent-child structure arrive intact. Compare sample traces side by side in both systems. The pilot is complete when traces from the application render correctly and the team signs off on the field mapping.
Migrate evaluations and datasets
Export evaluation templates, labeled datasets and prompt versions from Arize and recreate them in the target platform. Rerun a sample of historical evaluations on the same records to confirm that scores agree within the tolerance the evaluation owners accept. Record any evaluator that depends on a vendor-specific feature and plan its replacement. The step is complete when the sampled rerun results are documented, and each dataset has a checksum or record count matching its source.
Run both platforms in parallel
Send production traces to both Arize and the new platform for a defined period agreed by the owners, and compare volume, latency of ingestion, dashboards, alerts and evaluation results. This is the phase that exposes gaps: missing span fields, dashboards that cannot be rebuilt, alerts that fire differently, or users who depend on features with no equivalent. Log each gap with an owner and a resolution. The step is complete when no open gap blocks a production workflow and the owners approve the cutover in writing.
Cut over to the self-hosted platform
Switch all production exporters, evaluation jobs and team bookmarks to the new platform, and announce the change to users with links to the runbook. Keep the Arize configuration in version control so the change can be reversed during a fixed rollback window agreed in advance. The step is complete when all production applications report to the new platform, alerts route to the on-call channel, and the rollback procedure has been tested once.
Decommission Arize and confirm data deletion
Export a final copy of the data your retention policy requires, revoke API keys and user access, and cancel the subscription or self-hosted contract. Ask Arize to confirm in writing how and when customer data is deleted, including backups, and keep that confirmation with the migration record. If you run Arize AX self-hosted, confirm the deletion steps for your own deployment. The step is complete when the written deletion confirmation is on file and the migration record lists every item from the inventory as migrated, rebuilt or retired.
Questions teams ask before replacing Arize
Can we run Arize Phoenix internally under the Elastic License 2.0?
Yes, for your own internal use, Phoenix can be run inside your organization, but the Elastic License 2.0 is not an OSI-approved open-source license and it forbids offering the software to third parties as a hosted or managed service. Read the license text with your legal team, especially if you plan to run Phoenix for internal business units that are billed back or for customers. If your requirement is a license that permits any use, consider Langfuse (MIT for code outside its ee directories) or Opik (Apache-2.0), and confirm which Langfuse features need an enterprise license key before you commit.
How long does a migration from Arize to an open-source platform take?
The duration depends on scope: how many applications send traces, how many evaluators and datasets you need to carry over, whether prompts are versioned in Arize, and how many environments must be parity-tested before cutover. A single service with simple tracing is a very different project from a multi-team estate with custom evaluations and alerting. Ask any implementation partner, including DeployOpen, for a timeline tied to a written scope rather than a generic estimate, and confirm which dashboards, alerts and retention rules must be reproduced.
What skills does our team need to run Langfuse or Phoenix in-house?
Plan for four skill areas. Kubernetes and Helm are needed for production deployments, since Langfuse documents Docker Compose for testing and Kubernetes with Helm for production. PostgreSQL, ClickHouse, Redis or Valkey, and S3 or blob storage are the stateful dependencies you will back up, monitor and upgrade. OpenTelemetry knowledge helps your engineers instrument applications and debug missing spans. Finally, someone needs to own evaluation and prompt workflows. Check each of these against your current staff before deciding who operates the platform.
Can our own engineers do the migration without outside help?
Often yes for a small, well-documented estate, particularly if your teams already run Kubernetes and PostgreSQL and the application code already emits OpenTelemetry-compatible traces. Harder cases include regulated environments that need documented controls, high trace volumes that stress ClickHouse, and teams without anyone who owns on-call for the data stores. Many organizations split the work: internal staff keep application instrumentation and evaluation logic, while an outside team plans the deployment, hardening, backup and documentation. DeployOpen works on fixed-scope engagements agreed in writing, and ongoing support is available as a retainer.
How does Arize AX's self-hosted option compare with the open-source tools?
Arize AX can be self-hosted on Kubernetes in GCP, AWS, Azure, IBM Cloud, OpenShift or Rancher environments, which keeps data in your infrastructure while preserving the managed product's feature set. The trade-off is that you stay on a commercial platform with its own licensing and upgrade path. Ask Arize which features, support levels and upgrade procedures apply to your self-hosted deployment, and compare them with the open-source platforms' licenses, enterprise add-ons and the operational work you would take on yourself.
What drives the total cost of an open-source LLM observability platform?
Software licensing is only one line. The main recurring costs are cloud or data center compute, storage for traces in ClickHouse and object storage, backup and retention, and the engineering time spent on upgrades, monitoring and on-call. One-time costs include migrating instrumentation, rebuilding evaluations and prompt workflows, and security review. Trace volume, retention period, the number of environments and the number of teams sharing the platform are the largest drivers. Any enterprise license key or commercial add-on should appear as its own line in the comparison.
What should we request in a written quote for a migration?
Ask for a written scope that lists the platforms in scope, the applications and environments to instrument, the evaluations, datasets and prompts to migrate, and the deliverables such as runbooks, backup procedures and architecture documents. Request the assumptions behind the timeline, the responsibilities split between your staff and the provider, the acceptance criteria, and the support options after go-live. Also ask how the provider handles data access, credentials and change control inside your environment. Quotes that cannot be tied to a written scope are hard to compare.
How DeployOpen scopes and hands over an Arize replacement
DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, including the tracing and evaluation stack behind an Arize replacement. Engagements are fixed-scope, with the scope, deliverables and timelines agreed in writing before work starts.
How we scope
- Inventory which Arize AX or Phoenix features your teams use, such as traces, datasets, evaluations and prompt tooling
- Confirm whether Phoenix's Elastic License 2.0 terms fit how you plan to host and offer the tool internally
- Agree in writing which trace sources, OpenTelemetry collectors and evaluation workflows are in scope
How we build
- Deploy the chosen platform, such as Langfuse, Opik or Phoenix, into your cloud account, data center or air-gapped network
- Set up the supporting services the platform needs, including PostgreSQL, ClickHouse, Redis or Valkey, and object storage
- Re-point OpenTelemetry-based instrumentation and test trace ingestion, evaluation runs and access controls against the new deployment
How we hand over
- Deliver runbooks for deployment, upgrades, backups, access control and incident handling in your environment
- Document which license terms, enterprise keys or paid features apply to each component, and who holds them
- Walk your platform and security teams through the running system and the evidence produced for compliance readiness
How we support
- Offer ongoing support, upgrades and continuous security testing as a retainer after the handover
- Plan platform version upgrades and backup restore tests on a schedule you approve in the written scope
- Ask any quote to itemize implementation, hardening, documentation, training and recurring support separately
