Which Arize option fits your team, and what the decision turns on
Arize AX fits teams that want a managed platform with vendor support and plan-based limits on spans and retention, while Phoenix fits teams that want to run the same OpenTelemetry and OpenInference instrumentation on their own infrastructure with no usage limits. The choice usually turns on three questions: whether you need the managed platform and vendor support that come with AX, whether your team can operate PostgreSQL and Kubernetes (or another supported host) day to day, and whether the Elastic License 2.0 terms fit how you plan to use the software, especially if you intend to offer it to customers or other third parties as a hosted service. Phoenix's self-hosting docs describe no feature limitations, no license fees and no usage limits, so the cost question moves from span allowances to the infrastructure and staff time you put behind it.
Start by checking which AX features your team actually uses today. Confirm with Arize which AX capabilities, such as its enterprise access controls, support terms and online evaluation features, your contract covers and which of them have a Phoenix equivalent. Then check your plan's span allowance and retention window, and whether your renewal would add an Enterprise self-hosted AX deployment, which the Arize AX on-premise overview describes as running on Kubernetes. Ask your procurement team to put the Enterprise self-hosted quote and the Phoenix operating model side by side, so the comparison covers the same scope.
Next, map the operating work you would take on with Phoenix. Phoenix runs on SQLite by default and supports PostgreSQL through PHOENIX_SQL_DATABASE_URL or separate connection variables, so decide early which database your platform team will back up, patch and monitor. Confirm that the authentication options (OAuth2, LDAP or local accounts with role-based permissions) match your identity provider and access policy. For the license, have counsel read the Phoenix LICENSE file against your roadmap: internal use is the common case, but a plan to resell access to Phoenix or run it as a managed service for other companies is the point where Elastic License 2.0 becomes a blocker.
Which option fits each buying scenario
This table pairs common buying scenarios with the option that fits best and the condition that decides it. Read each row against your own requirements, and confirm current AX plan terms, span allowances and self-hosting eligibility with Arize before you decide.
| Scenario | Better fit | Condition that makes it the better fit |
|---|---|---|
| Span overages on a managed AX plan | Phoenix, self-hosted | Your trace volume or retention need exceeds what your AX plan includes, and you can run a database and storage yourself. Confirm current span limits with Arize. |
| Strict data residency mandate | Phoenix, self-hosted, or AX self-hosted | Traces and prompts must stay in your own region or data center. Phoenix keeps data in your infrastructure, while AX self-hosting requires an Arize Enterprise arrangement to confirm. |
| Air-gapped network with no internet access | Phoenix, self-hosted | Phoenix documentation states it self-hosts free, including air-gapped deployments. Mirror images and plan evaluator model access offline. |
| Team that wants vendor-run support and SLAs | AX managed or AX self-hosted | Your organization needs a contractual support commitment from the vendor. Phoenix is free to self-host, but support and SLAs must come from your own team or a partner such as DeployOpen under a written scope. |
| Platform team already runs Kubernetes | Phoenix on Kubernetes or AX self-hosted | Your team already operates clusters and can manage the Phoenix Helm chart with PostgreSQL. AX self-hosting also runs on Kubernetes, but its availability depends on your Arize agreement. |
| Offering LLM tracing to customers as a service | Neither Phoenix nor AX self-hosted without legal review | Phoenix's Elastic License 2.0 forbids providing it to third parties as a hosted or managed service. Confirm the commercial terms of AX with Arize, or choose an Apache-2.0 or MIT option with your counsel. |
| Internal use with no license fees and OSI license required | Phoenix only if ELv2 is acceptable | Internal self-hosting of Phoenix is permitted under ELv2. If your policy requires an OSI-approved license, consider Opik (Apache-2.0) or Langfuse (MIT core). |
How hosting and data control differ between AX and Phoenix
In the managed AX platform, Arize operates the application, the storage and the infrastructure that hold your traces, prompts and datasets. Your applications send telemetry to Arize's endpoints, and your team manages projects, users and evaluations through the vendor's interface. Where that data sits, who can sign in and how long history is kept are set by your plan and contract, so these points should be confirmed in writing before you design controls around them.
- Where data lives: Traces, prompts, datasets and evaluation results are stored in Arize's cloud. Ask which region your workspace uses and whether prompts and dataset contents follow the same region as spans.
- Identity: Sign-in and single sign-on depend on your AX plan. Confirm whether SSO and role-based access are included in your contract before you build access reviews around them.
- Retention and allowances: Span allowances and retention windows vary by plan. Get the current terms from your order form, since they determine how much history you can query and export.
- Evidence you produce: You collect the vendor's security documentation and contract terms, then record your own user lists, access reviews, data-flow diagrams and a description of what each application sends.
Before approval, check the region, identity tier and retention period against your data classification.
The self-hosted AX option runs the platform on Kubernetes inside your environment. Arize's on-premise overview lists GCP, AWS, Azure, IBM Cloud, OpenShift and Rancher as target environments. Trace, prompt and dataset data stays in clusters and storage you operate, but the deployment still carries Arize's software, upgrade cycle and support relationship, and it is offered under an enterprise arrangement that you should confirm with the vendor.
- Where data lives: Trace, prompt and dataset stores sit in your cluster and the storage services you attach. Confirm which databases and object stores the deployment requires and where backups are written.
- Platform targets: The on-premise overview names the supported environments. Confirm the supported Kubernetes versions and distributions for your estate before scheduling a build.
- Identity: Confirm with Arize which identity integrations exist in the self-hosted build, under which contract tier, and whether they match your central identity provider.
- Upgrades and support: Ask who applies vendor releases, how upgrades are tested, and which support tickets your team can open against the self-hosted stack.
- Evidence you produce: Your team owns cluster hardening, network policy, image provenance, patch records and access logs for the namespaces that run AX. Vendor documentation supports the vendor side only.
Ask for the support boundary and upgrade process in writing before you estimate internal effort.
Phoenix runs wherever you deploy it. The self-hosting docs state that traces, prompts and data stay in your infrastructure, including air-gapped deployments, and that self-hosting carries no feature limitations, license fees or usage limits. By default Phoenix stores data in a file-based SQLite database, which suits evaluation and small installs. For production, PostgreSQL is supported through PHOENIX_SQL_DATABASE_URL or separate connection variables.
- Where data lives: Traces, prompts, datasets and experiments are stored in the database and file system you configure. Back up that database on a schedule, and test restores. With the default SQLite file, the data is a single file on the host.
- Identity: OAuth2, LDAP and local accounts are supported, with role-based permissions. Map those roles to your identity groups and test that removing a user revokes access.
- Deployment choices: Phoenix can be deployed from a terminal, Docker, Kubernetes, Helm, several cloud templates and other options. Choose the method that matches your hosting controls and record the choice in your configuration baseline.
- License terms: The Elastic License 2.0 permits internal self-hosting but bars offering Phoenix to third parties as a hosted or managed service. Have legal review any customer-facing use.
- Evidence you produce: You own the records for access, configuration, backups, restore tests and vulnerability management of the host and database. DeployOpen can prepare controls and evidence for an assessment, but independent auditors and certification bodies issue any report.
Confirm the database choice, identity mapping and restore test in your environment before moving to production.
Capabilities side by side: AX and Phoenix
This table compares the capabilities named in the Arize AX and Phoenix documentation, row by row. Where a capability depends on your AX plan or Phoenix documentation is silent, the cell tells you what to confirm with Arize or in a pilot. Both products share OpenTelemetry and OpenInference instrumentation, so the main differences are usually plan limits, operating model and support.
| Capability | Arize AX (managed) | Arize Phoenix (self-hosted) |
|---|---|---|
| Instrumentation | Built on OpenTelemetry and OpenInference, the same open standards as Phoenix | Built on OpenTelemetry and OpenInference; the same instrumentation works with AX |
| Tracing | Managed tracing; confirm span handling and retention for your plan | OpenTelemetry-based tracing stored in your own infrastructure |
| LLM evaluations, datasets and experiments | Offered; confirm which evaluators, dataset and experiment features your plan includes | LLM-based evaluations, versioned datasets and experiments listed in the README |
| Prompt management | Confirm availability, versioning and playground details with Arize for your plan | Prompt management listed in the README |
| Remote MCP server | Not covered in the documentation reviewed; confirm with Arize | Remote MCP server listed in the README |
| Deployment targets | Self-hosted on Kubernetes in GCP, AWS, Azure, IBM Cloud, OpenShift or Rancher | Terminal, Docker, Kubernetes, Helm, AWS CloudFormation, Railway, Render, Cloud Run, Azure ARM |
| Default and supported databases | Managed backend; confirm storage design and sizing with Arize | SQLite by default; PostgreSQL via PHOENIX_SQL_DATABASE_URL or separate connection variables |
| Air-gapped networks | Confirm self-hosted air-gapped support and terms with Arize under your contract | Docs state air-gapped deployments are supported; test image mirroring in a pilot |
| Usage limits | Span allowances vary by plan; confirm current limits and overage terms before committing | Docs state no feature limitations, license fees or usage limits for self-hosting |
What the Elastic License 2.0 allows Phoenix to do for your team
Phoenix is source-available under the Elastic License 2.0, not an OSI-approved open source license. The license lets your own teams run Phoenix on infrastructure you control, including for internal use across business units, and the Phoenix self-hosting docs say it is free to self-host with no feature limitations, no license fees and no usage limits. What it forbids is providing the software to third parties as a hosted or managed service, and circumventing license key functionality. Read the Phoenix LICENSE file directly before you write the decision into an architecture document, because the license text governs and this page is not a legal interpretation.
The line matters most for vendors, managed service providers and SaaS companies that embed tracing for their own customers. If your product exposes Phoenix to customer tenants, or your team operates it on behalf of another organization, you are offering it to third parties, which the license bars. For illustrative purposes, an internal platform team that runs one Phoenix instance for its own engineers is in a different position from a consultancy that runs one instance per client. Ask legal counsel to confirm which of your deployment patterns fall inside the internal-use grant before you migrate.
For comparison, Langfuse's core is MIT licensed outside its ee directories, and Opik is Apache-2.0 licensed, with its README stating the full platform can be self-hosted without a commercial license. Both are OSI-approved, so their terms do not restrict hosting models in the same way. If you expect to offer tracing as a service to others, or want a license your procurement team recognizes as open source without qualification, those options are worth evaluating alongside Phoenix. Whichever you choose, document the license, the version you deploy and the review date, and recheck the terms when you upgrade.
What drives the cost of AX versus self-hosted Phoenix
The two options price differently: Arize AX is a subscription tied to plan, span allowances and retention, while Phoenix carries no license fee and no usage limits, so its cost sits in infrastructure, people and upgrades. The cards below separate what recurs from what is paid once, and what a quote would need to reflect.
AX subscription and plan limits
Arize AX is priced through its plan terms, and span allowances and retention periods vary by plan. Your span volume per month and the retention window you need decide which tier fits. Ask Arize for the current plan terms in writing, including overage handling, and confirm whether SSO and data residency sit in the tier you are considering.
Enterprise terms for self-hosted AX
Running AX on your own Kubernetes cluster is a separate arrangement from the managed service. The on-premise overview covers GCP, AWS, Azure, IBM Cloud, OpenShift and Rancher environments, but the commercial terms for that option must come from Arize. Ask whether the license, support and upgrade path are included, and what your own cluster, storage and staffing must cover.
Phoenix license at no fee
Phoenix has no license fees and no usage limits according to its self-hosting docs, with no feature limitations on self-hosted use. Its license cost is zero, so the budget question shifts to the infrastructure and people that run it. Confirm with your legal team that the Elastic License 2.0 terms fit your intended internal use before you treat the zero fee as the full cost.
Infrastructure for Phoenix
Recurring infrastructure includes compute for the Phoenix service, PostgreSQL storage for traces, prompts and datasets, and backups. Phoenix starts on SQLite by default, but production use typically calls for PostgreSQL through PHOENIX_SQL_DATABASE_URL. Storage grows with trace volume and retention, so size it from your own span counts rather than a vendor estimate.
Platform engineering and operations
Someone on your team owns deployment, access control, monitoring, backup restores and capacity planning. This is a recurring internal cost that replaces the managed service's operations work. Estimate it from the number of engineers who will carry the on-call and upgrade duties, and compare it with the subscription fee you would otherwise pay.
Upgrades and frequent releases
Phoenix ships often: arize-phoenix v20.23.0 was published on October 16, 2026, with multiple releases per week. Each upgrade needs a test cycle, a rollout plan and a check of dependent evaluators and integrations. Budget a recurring slice of engineering time for this, and ask whether a DeployOpen retainer would cover upgrades and continuous testing.
One-time migration work
Migration costs are paid once: repointing OpenTelemetry and OpenInference exporters, exporting history, recreating datasets and evaluators, and retraining reviewers on the new interface. These costs depend on how many projects, evaluators and dashboards you run. Ask any implementation partner for a fixed-scope written plan that lists each item, so you can separate the one-time effort from the recurring run cost.
Support and quote inputs
Phoenix has no vendor support contract, so support is either internal or bought separately, such as a DeployOpen retainer. A DeployOpen quote follows from written scope: the number of environments, data volume, SSO and residency requirements, and whether testing or training is included. Share these inputs to compare fairly with the current AX plan terms.
What a move from AX to self-hosted Phoenix involves
The sequence moves your traces, datasets, evaluators and access model from Arize AX into a Phoenix instance you run, with both systems operating in parallel before AX is retired. Each step closes with a check that tells you whether the next one can start.
Inventory what AX holds today
Someone on the platform or ML team lists the projects and trace volumes you want to keep, the datasets and experiments with their versions, the online and offline evaluators, the prompts in use, and the users and roles with access in AX. Retention needs are written down per data type, because your own policy, not the vendor's default, should set how much history comes across. The step is done when the inventory is reviewed by the data owner and every item has a keep, recreate or retire decision.
Confirm export options with Arize
Before building anything, ask Arize in writing what your plan and contract allow you to export, in what format, and at what volume, covering traces, datasets, evaluation results and prompts. Also confirm whether any AX features you rely on have no self-hosted equivalent in Phoenix. The step is done when the answers are on file with the owner of the migration and any gaps are assigned to a decision.
Stand up Phoenix on your target platform
The platform team deploys Phoenix on the chosen target, which the Phoenix self-hosting docs list as terminal, Docker, Kubernetes with Helm, or one of several cloud templates. For production, set PHOENIX_SQL_DATABASE_URL to a PostgreSQL database instead of the default file-based SQLite, and place the instance behind TLS and your network controls. The step is done when the UI loads, a test trace is stored in PostgreSQL, and a backup of that database has been restored successfully in a test environment.
Map identity and roles to Phoenix
The security or identity team chooses how users sign in: OAuth2, LDAP or local accounts, as the Phoenix self-hosting docs describe. Map each AX role to a Phoenix role-based permission, removing accounts that no longer need access and deciding who administers the instance. Local accounts need a documented password and offboarding process. The step is done when an access review signed off by the data owner lists every account and its permission, and a test user confirms the expected access.
Repoint OpenTelemetry and OpenInference exporters
Engineers change the exporter endpoint in each application from AX to Phoenix. Because the same OpenTelemetry and OpenInference instrumentation works with both products, the application code usually stays the same, but the endpoint and any credentials change. Many teams send traces through an OpenTelemetry Collector, which lets you change the destination in one place and add authentication to outgoing requests. The step is done when a sample request from each service appears as a trace in Phoenix with the expected attributes.
Recreate datasets, evaluators and prompts
The evaluation owner rebuilds or imports the datasets that were exported in step one, then recreates each evaluator using Phoenix's LLM-based evaluations and checks that its prompts and judge model produce the scores you expect. Prompt versions are rebuilt in Phoenix's prompt management and linked to the traces they produced. Any human review step that relied on AX features without a Phoenix equivalent needs its own tooling. The step is done when a reference set of evaluations gives results that the evaluation owner has reviewed against the AX results.
Run both systems in parallel
Traces are sent to AX and Phoenix at the same time for a period the team sets, so engineers can compare trace completeness, evaluation scores and dashboard views. The team logs every gap, such as missing attributes, delayed evaluations or access problems, and assigns an owner to each one. The step is done when the open gap list is empty or each remaining item has an agreed workaround and the business owner accepts it.
Cut over and retire AX
The team switches all remaining exporters to Phoenix, moves the ongoing evaluation jobs, and archives the AX exports and access records according to the retention decisions made in step one. Only after the archive is verified does the team cancel or downgrade the AX subscription, which should be confirmed in writing with Arize against the contract terms. The step is done when no production service sends data to AX, the archive is verified, and the cancellation is confirmed by Arize.
Questions buyers ask before choosing AX or Phoenix
How much effort does self-hosting Phoenix take, and what does it need from my team?
Self-hosting Phoenix is free of license fees, with no feature limits and no usage limits, according to the Phoenix self-hosting docs, so your costs are the infrastructure and the people who run it. Phoenix can run from a terminal, Docker, Kubernetes with Helm, or several cloud templates. It starts on SQLite by default, so a production setup usually means PostgreSQL through PHOENIX_SQL_DATABASE_URL, plus backups, upgrades and access control. Your team needs someone comfortable operating a stateful service and a Kubernetes or container platform. Phoenix ships releases several times a week, so plan a standing owner for upgrades. Confirm the sizing for your trace volume with your own load tests, since the docs do not give a fixed capacity figure.
Can my own team complete the migration from Arize AX to Phoenix without outside help?
Often yes, if your team already runs Kubernetes and PostgreSQL and the application uses OpenTelemetry and OpenInference instrumentation. Phoenix is built on the same instrumentation as AX, so the trace code usually needs only an endpoint change. The harder work is outside the instrumentation: exporting history, rebuilding datasets, evaluators and prompt versions, and confirming that AX features you use have a Phoenix equivalent. Many teams handle this in-house for a small set of services and bring in help for the evaluation and access-control rework. Test the exporter change in a non-production environment before cutting over production traces.
How long does a migration take, and what drives the duration?
No fixed duration is supplied for this migration, so treat any number you hear as an estimate to verify. The main drivers are the number of applications emitting traces, how many evaluators and datasets must be recreated by hand, the depth of your SSO and role model, and whether you need historical data moved. Environments with strict change control, air-gapped networks or multiple regions take longer because each deployment needs approval and testing. Ask any provider for a written plan with phases, dependencies and acceptance tests before you agree on a date.
Can I offer Phoenix to my customers as a managed service under the Elastic License 2.0?
No. The Elastic License 2.0 forbids providing Phoenix to third parties as a hosted or managed service, according to the Phoenix LICENSE file. Using Phoenix to run your own internal LLM tracing, including for your own products, is a different case, and the license permits internal self-hosting. If your business model involves giving customers access to a Phoenix instance, get written legal advice before you build it, and consider Apache-2.0 or MIT alternatives such as Opik or Langfuse, whose licenses are different. The license also forbids circumventing license key functionality, so review the full text with counsel.
Does Phoenix support single sign-on, and what does the setup involve?
Self-hosted Phoenix supports OAuth2, LDAP and local accounts with role-based permissions, according to the Phoenix self-hosting docs. That covers most corporate identity setups that expose OAuth2 through an identity provider. Confirm that your provider's OAuth2 flow and group claims map to the Phoenix roles you need, and test with a small group before rollout. If your requirement is SAML-only or a specific enterprise SSO feature, check the current Phoenix documentation for that exact protocol, because the supplied facts do not confirm SAML support. Your identity team should also decide how local break-glass accounts are protected.
Does Arize AX have a self-hosted option, and what does it require?
Yes. Arize AX has a self-hosted option that runs on Kubernetes in GCP, AWS, Azure, IBM Cloud, OpenShift or Rancher environments, according to the Arize AX on-premise overview. It is part of the enterprise offering, so you will need to confirm the plan, license terms and support scope in writing with Arize. Compared with Phoenix, self-hosted AX brings a larger platform and its own operating requirements, while Phoenix is free to self-host. Ask Arize for the current system requirements, upgrade process and which AX features are available in your self-hosted deployment.
What does a DeployOpen engagement cover, and how is it scoped?
DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure, including cloud accounts, data centers or air-gapped networks. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. Ongoing support, upgrades and continuous testing are available as retainers. DeployOpen does not publish a price list, and a quote follows from the written scope. DeployOpen prepares systems and evidence for compliance assessments but does not issue audit reports or certifications. Ask for the written scope to name the environments, data sources, evaluators and handover tasks.
How DeployOpen helps you evaluate, implement or migrate
DeployOpen is a Chainscore Labs company that plans, implements, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure. For Arize AX vs Arize Phoenix, we start by settling which deployment model, license terms and data controls your organization needs before anything is installed.
How we scope
- We confirm which Arize AX plan, span volume and retention you use today, and which features you rely on.
- We document your residency, SSO, access control and air-gap requirements before comparing Phoenix with other self-hosted options.
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before any work starts.
How we build
- We deploy Phoenix or another chosen platform in your cloud account, data center or air-gapped network, with PostgreSQL or SQLite as your standards require.
- We re-point existing OpenTelemetry and OpenInference exporters and test trace capture from your production services.
- We review the Elastic License 2.0 terms against your internal use and third-party service model with your legal team.
How we hand over
- You receive written architecture, configuration, access and runbook documentation for the environment we built.
- We provide a tested backup and restore procedure and a documented upgrade path for the chosen release line.
- We prepare evidence of controls for your compliance assessors, though independent auditors and certification bodies issue any audit report.
How we support
- Ongoing support, upgrades and continuous security testing are available as retainers after handover.
- Retainers can cover tracking of new Phoenix releases, patching, and checks that the license terms still fit your use.
- Ask us to confirm support scope, response expectations and upgrade responsibilities in the written agreement before you sign.
