Can you standardize on Arize Phoenix as a free replacement for Arize AX?
Internal self-hosting of Arize Phoenix is permitted under the Elastic License 2.0 (ELv2), but offering Phoenix to third parties as a hosted or managed service is barred. ELv2 is source-available, not an OSI-approved open-source license, so Phoenix is not the right fit where policy requires OSI-approved software. Before you standardize, have legal read the Phoenix LICENSE file against your actual use, and confirm the license terms that apply to the release you deploy, since the license text is the authority, not this summary.
For a company running Phoenix for its own engineers, traces and prompts on its own infrastructure, the license is usually not a blocker. The Phoenix self-hosting docs describe it as free to self-host with no feature limitations, license fees or usage limits, and state that data stays in your infrastructure, including air-gapped deployments. The restrictions bite in narrower cases: a managed observability service you sell to customers, a platform team that exposes Phoenix as a shared service to other companies, or any attempt to bypass license key functionality. Note that the ELv2 terms are not the same as the restrictions in Arize's own AX contract, so review both if you hold one.
Choose Phoenix for internal use when the decision is about cost and control. Choose Langfuse (MIT core) or Opik (Apache-2.0) when the license must be OSI-approved, when you may offer the tool to customers or affiliates as a service, or when a procurement policy lists ELv2 as unacceptable. Langfuse keeps enterprise features behind a separate license key, so confirm which features your rollout needs before you commit. The sibling topics on migrating to each option cover the technical steps.
What the Elastic License 2.0 requires you to respect
Phoenix is free to self-host, but its license is Elastic License 2.0, not an open-source license approved by the OSI. The cards below cover the decisions that follow from that difference, from internal use to hosted offerings and license key functionality. Whether these terms fit your specific use is a question for your counsel.
Internal self-hosting is permitted
The ELv2 terms allow your organization to run Phoenix on infrastructure it controls for its own internal use. The Phoenix self-hosting docs say traces, prompts and data stay in your infrastructure, including air-gapped deployments. Confirm that your intended use is internal, such as your own engineering teams tracing your own LLM applications, before standardizing on it.
No fees, feature or usage limits
The Phoenix self-hosting docs state that self-hosting carries no license fees, no feature limitations and no usage limits. Your cost is the infrastructure you run and the people who operate it. Ask whether any future Phoenix release changes these terms, since the license governs the software you download and the docs describe the current position.
No hosted service for third parties
ELv2 bars offering Phoenix to third parties as a hosted or managed service. This applies if you plan to sell or provide Phoenix-based tracing to customers, partners or affiliates outside your organization. Internal teams and contractors working for you are a different case, so have counsel confirm how your engagement model is classed before you build a managed offering on it.
Do not circumvent license key functionality
ELv2 forbids circumventing license key functionality. Phoenix's self-hosting terms do not depend on a paid key, but if you modify the code to bypass any key-based control in a future release, you would breach the license. Keep Phoenix builds unmodified in this respect, and record any patches you apply so an audit can show their scope.
ELv2 is not OSI-approved
ELv2 is source-available, which means you can read and run the code, but it is not an open-source license approved by the Open Source Initiative. Procurement and open-source policies written around OSI-approved licenses may classify Phoenix differently. Check your internal policy, and compare with MIT-licensed Langfuse or Apache-2.0 Opik if your policy requires OSI approval.
Counsel interprets the terms
This page summarizes the license terms and the Phoenix docs. It does not give legal advice, and the license text governs. Ask your legal team to review the LICENSE file against your planned deployment, customer relationships and any downstream use, and to confirm the version of the license that applies to the Phoenix release you adopt.
What Phoenix self-hosting allows inside your organization
The Phoenix self-hosting docs say you can run Phoenix for free, 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. That is the position most teams rely on when they standardize on Phoenix internally. The ELv2 restriction that matters is narrower: it bars offering Phoenix to third parties as a hosted or managed service, and it also bars circumventing license key functionality. Running Phoenix for your own engineers, products and customers' data processed on your systems is a different question from selling access to Phoenix as a service, so confirm with counsel which side of that line your structure falls on, especially if you operate for external clients.
Deployment routes include the terminal, Docker, Kubernetes, Helm, AWS CloudFormation, Railway, Render, Google Cloud Run and Azure ARM templates. For anything beyond a pilot, the decision is the database. Phoenix starts with a file-based SQLite database by default, which suits a single developer machine. For shared environments, set PostgreSQL through PHOENIX_SQL_DATABASE_URL or the separate connection variables described in the configuration docs, and confirm that your backup, restore and high availability approach covers that database. Check the exact variable names against the Phoenix configuration docs before you write deployment manifests.
Access control is the other place to make decisions early. Self-hosted Phoenix supports OAuth2, LDAP and local accounts with role-based permissions, so you can map it to your existing identity provider rather than issuing standalone credentials. Decide which roles reviewers, engineers and read-only stakeholders need, and test that trace visibility matches your data classification rules before any production data arrives. Ask your security team whether local accounts are permitted at all in your environment, and document the identity source you chose for audit purposes.
How Phoenix, Langfuse and Opik differ on licensing and self-hosting
This table compares the license, OSI status, restrictions and self-hosting requirements of Arize Phoenix, Langfuse and Opik. Read the rows on hosted-service rights and enterprise features first, because they decide whether a free self-hosted deployment fits your use case.
| Aspect | Arize Phoenix | Langfuse | Opik |
|---|---|---|---|
| License | Elastic License 2.0 (ELv2) | MIT for core code; separate commercial license for ee directories | Apache-2.0 for the full platform |
| OSI-approved open source | No | Not applicable | Yes |
| What the license bars | Offering Phoenix to third parties as a hosted or managed service, and circumventing license key functionality | Nothing for core features; ee directories need the commercial license | No restriction on hosting in the license terms; confirm details in the LICENSE file |
| Self-hosting feature limits | None stated: free to self-host with no feature limitations, license fees or usage limits | Core features and APIs unlimited; RBAC, audit logs, SCIM, retention and data masking need an enterprise key | Full platform self-hostable without a commercial license |
| Self-hosting needs | SQLite by default; PostgreSQL optional; Docker, Kubernetes, Helm or other supported templates | PostgreSQL, ClickHouse, Redis or Valkey and S3-compatible storage; Docker Compose for tests, Kubernetes for production | Docker Compose for local use, Kubernetes with Helm for production; ClickHouse, MySQL and Redis |
| Access controls self-hosted | OAuth2, LDAP and local accounts with role-based permissions | Basic access included; project RBAC and SCIM require an enterprise key | Confirm role and SSO options for your version in the docs |
| Trade-off to weigh | Free internal use, but a commercial hosting offer built on Phoenix is out of bounds for you | Enterprise features cost extra and the commercial terms apply to ee code | Permissive license, but you size and operate ClickHouse storage yourself |
When the Elastic License 2.0 difference actually matters
For most internal platform teams, the Elastic License 2.0 difference rarely changes the decision. Illustratively, a platform team that runs Phoenix on its own cluster for its own engineers, with traces and prompts staying in its infrastructure, is using the software in the way the license permits for internal self-hosting. The ELv2 restriction targets offering Phoenix to third parties as a hosted or managed service. Before standardizing, confirm with counsel that internal use by employees and contractors fits your reading of the license, and record that conclusion alongside the Phoenix version you deploy, since releases ship several times a week.
The picture changes when the same deployment becomes a product. Illustratively, a company that plans to sell LLM observability to customers, or to host Phoenix for a group of subsidiaries that are separate legal entities, is offering the software to third parties as a managed service, which the license bars. The same applies to a shared service that bills other business units on a chargeback basis if counsel views that as third-party provision. In these cases, Langfuse under MIT or Opik under Apache-2.0 avoids that restriction for the core platform, subject to the separate enterprise directories in Langfuse and the licensing of any enterprise features you adopt.
A procurement or policy rule that requires OSI-approved licenses is a separate test that applies even when no hosting is planned. Illustratively, if your open-source policy lists approved licenses, Phoenix may fail that check regardless of how you use it, because ELv2 is source-available rather than OSI-approved. Ask your policy owner which category applies before the pilot, not after. Similarly, a vendor-neutral platform team that may later offer tracing as a shared service should weigh that option now, because moving from Phoenix to another tool later means re-pointing instrumentation and rebuilding history. Confirm the scope of every scenario with counsel and your procurement team before you commit.
How to deploy Phoenix internally without breaching the license
This sequence takes an internal team from a license check to a running, access-controlled Phoenix deployment that stays inside the organization's boundary and within the internal-use terms of the Elastic License 2.0.
Confirm the internal-use scope in writing
Legal or compliance counsel reads the Elastic License 2.0 terms against your plan, then records in writing that Phoenix will serve only your own staff and internal applications, not customers or other third parties. Include who owns the deployment, which business units use it and whether any contractor will operate it. Keep the memo with the architecture record. It is done when counsel has signed off on that scope and the owner has accepted it.
Choose the deployment target
The platform team selects the runtime inside your own cloud account, data center or air-gapped network. Phoenix's self-hosting docs list terminal, Docker, Kubernetes, Helm and several cloud templates, and Kubernetes with Helm is the usual choice for production. Confirm the cluster, ingress and storage classes exist before you start. It is done when the target and its namespace are documented and the deployment is planned against your own network boundary.
Move storage from SQLite to PostgreSQL
Phoenix starts with a file-based SQLite database by default. Your platform engineers provision a PostgreSQL instance inside the same boundary, then point Phoenix at it with the PHOENIX_SQL_DATABASE_URL variable or the separate connection variables described in the configuration docs. Set backups and encryption at rest through your database standard. It is done when Phoenix starts, writes a test trace to PostgreSQL and the backup job restores that record in a test environment.
Configure authentication and role-based access
The identity team connects Phoenix to OAuth2 or LDAP, or uses local accounts where directory integration is not possible. Map directory groups to Phoenix roles so that engineers, reviewers and administrators get only the permissions they need. Remove default or shared accounts. It is done when a test user from each group signs in through the intended method and an unauthorized account is refused access to project data.
Instrument applications with OpenTelemetry and OpenInference
Application teams point their OpenTelemetry exporters at your internal Phoenix collector endpoint and use OpenInference instrumentation for LLM framework spans. Keep the endpoint address on your internal network and avoid any exporter setting that sends data to an external Arize service. The same instrumentation can later target Arize AX, so the choice stays reversible. It is done when a sample request appears as a trace in your internal Phoenix UI.
Keep the deployment inside the boundary
Network and security engineers restrict egress so the Phoenix service, its database and its storage can reach only approved internal addresses. Document that the deployment is not offered to customers, partners or other external parties as a hosted or managed service, which the Elastic License 2.0 forbids. Confirm with counsel that any managed or consulting arrangement keeps the software under your control. It is done when the network policy, the scope memo and the service inventory all describe the same deployment.
Check release notes before each upgrade
Before you upgrade, the platform owner reads the release notes on the Arize-ai/phoenix releases page, which publishes frequent releases. Check schema or configuration changes, test the new version against a copy of the PostgreSQL database and record the version you run in production. Keep the license file of each version on record, because terms can differ between releases. It is done when the upgrade has passed a staging test and the change record names the release reviewed.
What do buyers ask before standardizing on Phoenix?
Is self-hosting Arize Phoenix free for internal use?
Yes, according to Phoenix's self-hosting documentation, Phoenix is free to self-host with no feature limitations, no license fees and no usage limits. The docs also state that traces, prompts and data stay in your infrastructure, including air-gapped deployments. The Elastic License 2.0 in the repository permits internal use, so the question for counsel is not whether your own staff can run it but whether any use falls outside internal use. Confirm the current LICENSE file in the version you deploy, because the license text governs, not the marketing page.
Can we offer Phoenix to our customers as a hosted service?
No. The Elastic License 2.0 forbids providing the software to third parties as a hosted or managed service. If your product exposes Phoenix tracing or evaluation to customers, or runs Phoenix for other companies as a managed offering, you are outside the license. Internal use by your own teams, including tracing your own LLM applications for your own business, is a different case. Ask counsel to review how any customer-facing feature touches Phoenix before you build on it, since the boundary depends on how the service is delivered.
Is the Elastic License 2.0 an open-source license?
No. The Elastic License 2.0 is source-available, and it is not approved by the Open Source Initiative as an open-source license. That matters if your policy requires OSI-approved licenses for production dependencies, or if procurement uses an approved-license list. The practical differences show up in the restriction on hosted services and the license key provisions, which prohibit circumventing license key functionality. Licenses such as the MIT license used by Langfuse's core code and the Apache-2.0 license used by Opik are OSI-approved, so they may pass a policy that Phoenix does not.
How much effort does a Kubernetes deployment with PostgreSQL take?
Phoenix starts with a file-based SQLite database by default, and it supports PostgreSQL through the PHOENIX_SQL_DATABASE_URL variable or separate connection variables, according to its configuration docs. Effort is driven by your existing platform: whether you have a Kubernetes cluster with Helm, a managed PostgreSQL service, secrets handling, ingress with TLS, backups and monitoring. The Phoenix self-hosting docs list Helm as a supported method. The duration of this work depends on those prerequisites and on your change control, so ask for a written scope that names each of these items rather than relying on a general estimate.
What does Phoenix cost to run beyond the software itself?
The software carries no license fee under the self-hosting docs, so the recurring cost is the infrastructure and the people who run it. Plan for compute and managed or self-run PostgreSQL, storage that grows with trace volume, backups, monitoring and the time your platform team spends on upgrades. Self-hosted Phoenix supports OAuth2, LDAP and local accounts with role-based permissions, so identity integration is a setup cost rather than a subscription. Ask any implementation partner for a quote that lists each component, who pays for it and which items recur monthly versus once.
Can DeployOpen document our Phoenix license position and run the deployment?
DeployOpen plans, implements, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure, so a deployment and its runbook can be part of a fixed-scope engagement with written scope, deliverables and timelines. DeployOpen does not provide legal advice on license terms, so the interpretation of the Elastic License 2.0 for your use should come from your counsel. The engagement can record how Phoenix is deployed, which features are used and where data is kept, which gives counsel a factual basis for their review.
When does the license difference matter enough to choose Langfuse or Opik?
It matters most when a policy requires OSI-approved licenses, when a product team might host tracing for customers, or when counsel is uncertain about the boundary of internal use. Langfuse's core features are under the MIT license except for enterprise directories, and Langfuse states that all core features and APIs are available in the open-source version without limits. Opik is Apache-2.0 and its README states the full platform can be self-hosted without a commercial license. If your use is clearly internal and your policy accepts source-available licenses, Phoenix remains a valid choice. Confirm the license terms with counsel before standardizing.
What reviewers ask to see for license compliance
Reviewers rarely stop at the phrase "free to self-host." They ask for a record that ties the Elastic License 2.0 text to how Phoenix is actually deployed, used and compared with other options. The six items below form that record and can be kept current without legal specialists on every change.
License text reviewed and retained
Keep a dated copy of the LICENSE file from the exact Phoenix source your team deploys, with the reviewer's name and the date of review. The Elastic License 2.0 is short, but its two key restrictions, no offering to third parties as a hosted or managed service and no circumvention of license key functionality, are what reviewers will look for. Ask counsel to confirm how those terms apply to your organization's structure.
Written internal-use scope
Write a short statement that names who uses Phoenix, which business units and which applications send traces to it, and that the service is run for internal engineering and evaluation work only. Phoenix's self-hosting docs describe free use with no feature limits, but the license governs use, so the scope document should say what the instance is not used for, such as serving paying customers.
Deployed version and release record
Record the exact Phoenix version or container image digest in each environment, along with the date it was deployed and who approved it. Phoenix ships multiple releases per week, so a dated inventory shows which build reviewers evaluated and whether later builds were reviewed against the same terms. Confirm the release notes for any change to licensing or the README before upgrading.
Access list and role assignments
Export the user list from the Phoenix instance and map each account to its role. Self-hosted Phoenix supports OAuth2, LDAP and local accounts with role-based permissions, so the record should state which identity source is authoritative and who can create or remove accounts. A reviewer will also ask whether any external party, such as a consultant or customer, holds an account.
Record of hosted or customer-facing use
Keep a log of every proposal to expose Phoenix outside the company, including a customer-facing dashboard, a partner portal or a managed instance run for another business. Each request should be checked against the hosted-service restriction before work starts, and the outcome recorded. This is the item most likely to surface a problem, so reviewers expect it to be explicit even when the answer is that no such use exists.
Decision record against OSI-licensed options
Document why Phoenix was chosen over options under OSI-approved licenses, such as Langfuse's MIT-licensed core or Opik's Apache-2.0 platform, and what each option requires. Note the trade-offs in features, retention tooling and support, and state the conditions that would trigger a review, such as a need to offer the tool to third parties. Ask the platform team to confirm current licensing for each option at decision time.
How to choose between Phoenix, Langfuse and Opik
If your use is internal and OSI-approved licensing is not a requirement, Phoenix is the most direct choice: it is free to self-host with no feature limits, and its OpenTelemetry and OpenInference instrumentation matches what Arize AX uses, so your exporters and span conventions carry over. If you may later offer the tool to customers or partners as a hosted service, or if your procurement or open-source policy requires an OSI-approved license, Phoenix under the Elastic License 2.0 is the wrong default. Put that question to legal and procurement before standardizing, not after the first rollout.
For OSI-license needs, the two alternatives differ in what you run. Opik is Apache-2.0 across the server, web application, tracing, evaluations and prompt management, and its Docker Compose and Helm paths keep the license question simple. Langfuse core is MIT, but code in its ee directories and the enterprise-key features listed in the Langfuse self-hosting documentation sit under a separate commercial license, so confirm which features your team actually needs before assuming full openness. Each option has a different cost shape: self-hosted Langfuse requires you to operate ClickHouse, PostgreSQL, Redis or Valkey and S3-compatible blob storage, and Opik relies on ClickHouse, MySQL and Redis. Phoenix's default SQLite can be replaced with PostgreSQL, which is a smaller footprint for low trace volumes. Your costs are mostly your own infrastructure and the engineers who run it, and those scale with trace volume and retention.
Before you decide, run a short proof of concept against your real trace volume and retention period, and confirm three things with each vendor: the license terms for every component you will deploy, which features sit behind an enterprise key, and whether the release cadence and upgrade path fit your change process. DeployOpen can plan and implement the chosen deployment against a written scope, but the licensing determination should come from your legal counsel.
How DeployOpen deploys self-hosted LLM tracing under license constraints
DeployOpen treats the Elastic License 2.0 as a scoping question before any installation work starts. We confirm how the license applies to your internal use, your hosting model and any customer-facing service, then deploy Phoenix inside your own infrastructure with the controls your compliance team needs.
How we scope
- Written scope confirms whether Phoenix serves internal teams only or any third party, which the Elastic License 2.0 treats differently.
- We map trace sources, prompts, datasets and users so the deployment boundary and data handling are explicit before build.
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work begins.
How we build
- We deploy Phoenix on your Kubernetes, Docker or other chosen environment, with PostgreSQL configured through the documented connection variables.
- We wire OpenTelemetry and OpenInference exporters from your applications and test that traces and evaluations land in your infrastructure.
- We configure OAuth2, LDAP or local accounts with role-based permissions, then test access controls against your identity requirements.
How we hand over
- You receive architecture documentation, configuration records and a written statement of the license terms that our scope assumed.
- We document the license key and circumvention boundaries so your engineers know which changes the Elastic License 2.0 prohibits.
- We walk your team through backup, upgrade and evidence steps, and prepare controls for your compliance assessor. We do not issue audit reports or certifications.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers, so Phoenix versions can be reviewed as releases ship.
- Before any upgrade or licensing change, we re-check the license text and your intended use against the agreed scope.
- Confirm with your legal counsel whether your planned use, including any customer-facing service, fits the Elastic License 2.0 before go-live.
