Move from Arize AX to self-hosted Phoenix

Migrate from Arize AX to self-hosted Phoenix: what moves and what does not

Teams usually look at self-hosted Phoenix after an AX renewal, after hitting span or retention limits, or because a data residency rule requires traces to stay on a cluster they control. The move keeps your OpenTelemetry and OpenInference instrumentation, so application code that emits spans does not need to be rewritten. What changes is the backend, the storage you operate, and the support model: you replace AX's managed service with a Phoenix deployment you run, patch and back up. Platform or ML engineering usually does the work, with security sign-off on the network path, the storage encryption and the access model. Effort and risk depend mostly on how many projects send traces, how much history you need to keep, and whether you rely on AX features that Phoenix does not provide. Confirm those features with Arize before you commit.

Before you standardize on Phoenix, have legal or procurement review the Elastic License 2.0 terms. Phoenix is free to run for internal use, including on your own Kubernetes cluster, but the license bars offering it to third parties as a hosted or managed service. That matters if you plan to run Phoenix for other business units that are separate legal entities, for customers, or through a managed provider. The Phoenix license file is the text to review, and it is not OSI-approved. Ask your counsel whether that constraint fits your operating model, and record the decision alongside the architecture.

Plan the deployment around PostgreSQL as the metadata and trace store, running on Kubernetes with the database backed up and monitored like any other system of record. Decide who owns upgrades, since you will no longer receive them from Arize, and who answers when the instance is down. Check which AX capabilities your teams depend on, such as specific evaluation workflows, dashboards, SSO configuration or support terms, and confirm their Phoenix equivalents in the Phoenix documentation before you start. Ask your network team to confirm the ingress path and the authentication in front of the UI, because Phoenix's own access controls need to be paired with your identity layer.

Which Arize AX capabilities map cleanly to Phoenix

This table compares the main Arize AX capabilities with their counterparts in self-hosted Phoenix and marks each as clean, needs rework, or gap. Phoenix and AX share OpenTelemetry and OpenInference instrumentation, so most trace code can stay, but the rows marked gap or needing confirmation are where your team should check the Phoenix docs and ask Arize before committing. Read the status column as a planning signal, not a parity guarantee.

Capability	Arize AX	Self-hosted Phoenix	Status
Tracing ingestion	Receives OpenTelemetry and OpenInference spans from instrumented applications	Receives the same OpenTelemetry and OpenInference spans, so existing instrumentation code can usually stay	Clean
OpenTelemetry and OpenInference instrumentation	Built on the same open standards as Phoenix	Built on the same open standards, so instrumentation is portable between the two	Clean
Evaluations	Online evaluations and managed evaluator workflows in the AX interface	Phoenix offers its own LLM-based evaluations, but evaluator templates and scores need to be recreated and checked	Needs rework
Datasets and experiments	Managed datasets and experiments tied to the AX platform	Phoenix supports datasets and experiments; export and reimport of existing records should be tested with your data	Needs rework
Prompt management	Prompt management and playground inside AX	Phoenix includes prompt management; confirm its feature set against the AX features you use	Needs rework
SSO and access control	Enterprise identity and role controls in the managed platform	Confirm current authentication and role options in the Phoenix docs before relying on them for regulated access	Gap
Self-hosted deployment	Self-hosted AX on Kubernetes requires an Enterprise contract	Phoenix is self-hosted under the Elastic License 2.0 for internal use; you run and upgrade it yourself	Clean
Managed operations, enterprise support and plan-based retention	Vendor-managed hosting, support tiers and span-based retention by plan	No vendor-managed hosting or plan limits; your team owns storage, backups and upgrades	Gap

What the Elastic License 2.0 allows you to do with Phoenix

The Elastic License 2.0 (ELv2) lets you run Phoenix yourself for your own internal use, but it bars you from offering Phoenix to third parties as a hosted or managed service. For an internal platform team, that means you can deploy Phoenix on your Kubernetes cluster, point your instrumented applications at it, and let your own engineers, data scientists and reviewers use it without a separate license fee. The team should still document who uses the instance, which applications send traces to it, and whether any business unit, contractor or affiliate reaches it in a way that could count as service to someone outside the organization. Those answers decide whether the deployment stays inside the license.

A consultancy that installs and operates Phoenix for clients is in a different position. Running a Phoenix instance on behalf of a client, with the consultancy managing upgrades, access and availability, is close to the managed-service arrangement the license restricts. The usual approach is to have each client deploy and own its instance inside its own environment, with the consultancy providing implementation and support under a services agreement rather than operating a shared service. A SaaS vendor embedding Phoenix in its product has the most exposure, because exposing Phoenix features to its customers through its own product is the kind of third-party offering the license prohibits. Vendors in that position should evaluate Langfuse or Opik, which use licenses without this restriction.

Before deployment, have your legal team review the ELv2 terms against your actual use, including internal users, contractors, client work and any product integration. Confirm the current LICENSE file in the Phoenix repository at the version you plan to deploy, since terms can change between releases and your records should reflect the text in force on your deployment date. Ask legal to record the conclusion and the scope it covers, so the decision can be revisited if your structure or customer base changes.

What data to export from Arize AX and which integrations to rebuild

Moving from Arize AX to self-hosted Phoenix touches four kinds of material: the data you have collected, the code that sends it, the people who reach it, and the checks that score it. Inventory each one before you provision Phoenix, because the export paths and their limits must be confirmed in Arize's current documentation before you plan around them.

Trace history worth keeping

Decide which production traces must survive the cutover, such as traces tied to incidents, customer disputes or model comparisons. Confirm with Arize which export paths exist for AX tracing data on your plan and how far back they reach. Record the retention window you had in AX so you can compare it with the storage you size for Phoenix, which you run on your own PostgreSQL instance.

Datasets and experiment baselines

Datasets and experiment results are the reference points you compare new prompts and model versions against. Export the example inputs, expected outputs and metadata, then confirm whether AX exports experiment runs with their scores or only the examples. Plan to re-run baseline experiments in Phoenix if the scores themselves do not come across.

Evaluation results and evaluator definitions

Separate the stored evaluation scores from the evaluator logic that produced them. Scores are historical records you may need for audits or trend charts. Evaluator definitions, including judge prompts and label rubrics, must be rewritten and tested in Phoenix, since a score from one judge model is not directly comparable with a score from another.

Prompt versions and their labels

Export every prompt version that is still in use, along with its labels and the traces that reference it. Without the link between a prompt version and its traces, you lose the ability to explain why an output changed. Check how Phoenix stores prompt versions in your deployment and recreate the current production labels before switching application code over.

Exporter endpoints and instrumentation

Every service that sends traces to AX has an exporter configuration pointing at Arize's endpoint with its own credentials. Inventory each one, including OpenTelemetry collectors, and repoint them to your Phoenix service. Because Phoenix is built on the same OpenTelemetry and OpenInference standards, the instrumentation code often stays in place while only the endpoint and credentials change.

SSO, access rules and alerting

Map who can view traces, datasets and evaluations in AX today, including SSO groups and any alert or notification channels tied to evaluation results. Recreate those rules in your own identity provider and confirm what access control Phoenix supports in your deployment. Alerts often depend on a specific score threshold, so rebuild them against the scores Phoenix now produces.

The migration sequence from inventory to decommissioning AX

This sequence moves tracing from Arize AX to self-hosted Phoenix without a blind cutover, so each service is switched only after Phoenix has shown it can receive, store and display its traces. Each step ends with a written output that the next step depends on.

Inventory instrumented services, prompts and evaluators
Platform engineering and the LLM application owners list every service that sends traces to AX, including the OpenTelemetry or OpenInference exporter settings, the environments and regions involved, and the prompts and evaluators that run against those traces. Add a retention requirement for each service, drawn from compliance and product owners, and note which AX datasets, experiments and annotations must be preserved. The output is an inventory register with one row per service, its exporter configuration, its owner and its retention needs. The step is done when every AX project in use appears in the register and the owners have signed off on it.
Stand up a pilot Phoenix deployment on Kubernetes
The platform team deploys Phoenix in the organization's own Kubernetes cluster and points it at a PostgreSQL database that the team operates or has agreed to operate, with backups defined before any production data arrives. Confirm the deployment settings, storage sizing and access controls against the current Phoenix documentation, since configuration details change between releases. Send a set of test traces from one non-production service and check that they appear, that evaluations can be run, and that users can reach the interface through the organization's chosen access path. The output is a pilot sign-off record listing the tested version, the database setup, backup and restore results, and any gaps against the inventory.
Run AX and Phoenix in parallel through a Collector
Deploy an OpenTelemetry Collector between the applications and both backends, configured to fan out each trace to AX and to Phoenix. This lets one service send to both systems without changing its application code, and it lets the team compare span counts, attributes and latency between the two backends. Review the Collector's configuration against the vendor-neutral security practices in the OpenTelemetry documentation, including how exporter credentials are supplied. Record every mismatch in span attributes, token counts or evaluator inputs in a parity log, and resolve each one before moving on. The output is a parity report that the application owners accept for each service in the register.
Cut over exporters one service at a time
For each service in the register, change the exporter endpoint and credentials so that traces go only to Phoenix, starting with a lower-risk service and ending with the most critical. Make each change in the service's normal deployment pipeline, so it can be rolled back to the previous exporter configuration in one step. Rebuild the evaluators and any saved prompt or dataset references in Phoenix before the cutover, and confirm that the service's dashboards and alerts still receive the data they need. The output is a cutover checklist per service, signed by its owner, that records the change, the verification results and the rollback path.
Archive AX history and decommission the subscription
Export the traces, datasets, experiments and evaluation results that the register marked for retention, using the export tooling Arize provides, and store them in the organization's own archive with checksums and an access log. Confirm with the compliance owner that the archive satisfies each retention requirement, and ask Arize in writing about the terms that apply to ending the subscription and deleting data. Once the archive is verified and no service still sends traces to AX, revoke AX credentials and close the Collector's AX exporter. The output is a decommissioning record that lists the archive location, the verification result, the credential revocation date and the contract closure confirmation.

Deploying Phoenix with PostgreSQL on Kubernetes

The target architecture for self-hosted Phoenix is a Phoenix deployment running in your own Kubernetes cluster, backed by a PostgreSQL database that you operate or procure, with ingress terminating TLS in front of the Phoenix service. Before you build anything, use the Arize Phoenix documentation as the reference and confirm with the project the current deployment manifests, the PostgreSQL versions it supports, and the sizing guidance for your expected trace volume. Those details change between releases, so do not copy values from older blog posts or internal wikis. Decide early who owns the cluster namespace, the database instance, and the certificate lifecycle, because those owners will each need to sign off on the design.

Plan secrets handling as a separate work item rather than an afterthought. The database credentials, any authentication settings for the Phoenix UI, and the TLS private key should come from your existing secrets manager or a Kubernetes secret store that your platform team already audits, not from values committed to a Helm values file. Confirm which environment variables or configuration keys the release you deploy reads for database connection and access control, and restrict who can read the resulting secrets. Ask your security team to review network policies so that only the ingress controller and instrumented workloads can reach the Phoenix endpoint.

Backups and upgrades need an explicit runbook. Because PostgreSQL holds the trace and evaluation records, schedule backups with point-in-time recovery if your database platform supports it, and test a restore into a separate namespace before you rely on it. For upgrades, pin the image version, read the release notes for schema migrations, take a fresh database backup, and roll forward in a staging cluster first. Confirm with the project whether downgrades are supported, since that determines your rollback plan. Several of these steps depend on your environment, so validate them with your own operations team before go-live.

What drives cost and duration of the move

This table lists the main factors that change the effort and cost of moving from Arize AX to self-hosted Phoenix, with how each one can be reduced. Phoenix has no usage fee in the facts supplied for this page, so the cost sits in infrastructure, staff time and any support you buy, and the table helps you ask the right questions in a quote.

Driver	Why it changes cost or effort	How to keep it down
Number of instrumented services	Each service that sends traces to AX needs its exporter repointed to Phoenix and tested, so effort grows with the service count.	Inventory every exporter first, group services by shared instrumentation library, and move one group at a time.
Volume of traces retained	Phoenix storage on PostgreSQL grows with retained spans, which drives database size, backup windows and query load.	Set a retention window before deployment, sample non-critical traffic, and size the database from a measured trace volume.
Evaluator and dataset rework	Evaluators, datasets and experiments built in AX do not carry over automatically, so each one must be recreated and checked against known results.	Export datasets and evaluation results first, prioritize the evaluators used in release gates, and retire unused ones.
SSO and access integration	AX users and roles must be mapped to access controls on your own Phoenix deployment, and the identity provider must be connected by your team.	Confirm with Arize which Phoenix authentication options your version supports, and agree the role model before go-live.
Kubernetes platform maturity	Phoenix runs on your cluster with PostgreSQL, so missing ingress, certificates, backup tooling or monitoring adds work before Phoenix itself is installed.	Check existing cluster standards, storage classes, backup and monitoring, and document gaps as separate scope items.
Elastic License 2.0 legal review	Internal use is permitted, but offering Phoenix to third parties as a hosted or managed service is not, so legal review time depends on how your business uses it.	Have counsel confirm the internal-use scope in writing and record the decision before the project starts.
Staff time for parallel run	Running AX and Phoenix side by side to compare traces and scores takes engineer and reviewer time for the overlap period.	Agree a fixed comparison period, define the trace and score checks in advance, and assign named reviewers.

How the move differs by team size and starting point

A small team that already emits OpenTelemetry traces from its services has the shortest path. The instrumentation stays in place, so the work centers on pointing exporters at a self-hosted Phoenix instance, confirming that the attributes Phoenix reads are present, and deciding what AX-only work to leave behind. Most of the effort sits in the license conversation and in running one PostgreSQL database that someone owns.

Exporter change: Repoint the trace endpoint at your Phoenix deployment and confirm that spans arrive with the expected kinds and attributes before retiring the AX exporter.
Single deployment: Run one Phoenix instance backed by PostgreSQL, and schedule database backups from the first day of use.
License scope: Elastic License 2.0 permits internal use, but a small team that later sells access to its tracing as a service would fall outside it, so write down the internal scope now.
Lost AX features: Inventory the dashboards, views and workflows your team actually used in AX, then export or rebuild only those.

Before you commit, check which AX features your team opened in the last few months, because that list defines the real gap.

What usually goes wrong and how to prevent it

Most failed Phoenix migrations fail on paperwork, data or wiring rather than on the software itself. The six risks below cover licensing, history, instrumentation, storage, access controls and the period when two backends run side by side.

Treating ELv2 as open source

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. Teams that run Phoenix for internal engineering use are generally in bounds, but a product team that offers Phoenix dashboards to customers or partners may not be. Have legal review the intended use against the license text before you promise a deployment to anyone outside your organization.

Losing evaluator and dataset history

Phoenix can receive new traces immediately, but datasets, experiments and evaluation results built in AX do not move automatically. Export them before you cut over and record which evaluator template and model produced each score. Without that record, a score trend that crosses the migration date will not be comparable, and regressions will look like improvements or the reverse.

Instrumentation drift between services

When some services send spans to AX and others send them to Phoenix, traces split across two backends and no single view shows a request end to end. Pin the OpenTelemetry and OpenInference instrumentation versions per service, and route all exporters through one endpoint configuration. Check that trace IDs and span attributes match in both systems during the parallel run.

Under-sized PostgreSQL storage

Phoenix stores traces in PostgreSQL, so table growth follows span volume, payload size and retention. Estimate spans per day from your current AX usage, multiply by average payload size, and add headroom for indexes and backups. Ask your platform team to set storage alerts and a tested restore procedure before production traffic arrives, because a full volume stops ingestion without a clear error for users.

Unverified SSO parity

AX SSO, role mapping and workspace access do not carry over to a self-hosted Phoenix instance. Phoenix access controls and identity options must be checked against your identity provider rather than assumed from the AX configuration. List every group that uses AX today, test sign-in and role assignment for each one in staging, and document any group that will have no equivalent access before users lose it.

Running both backends without a retirement date

Running AX and Phoenix in parallel is useful for a short validation window, but it tends to continue indefinitely and doubles telemetry costs and review effort. Set a written retirement date for AX ingestion, a named owner for the decision, and a list of dashboards and alerts to rebuild before that date. Revoke AX API keys on that date so that services cannot keep sending data by accident.

Questions teams ask before moving from Arize AX to Phoenix

Is moving from Arize AX to self-hosted Phoenix cheaper?

It can be, but the answer depends on what you pay today and what you take on after the move. Phoenix is free to run internally under the Elastic License 2.0, so the recurring costs shift to infrastructure and operations: a Kubernetes cluster, a PostgreSQL database, storage, backups, monitoring and the engineering time to upgrade and support it. The main cost drivers are trace volume, retention period, high availability requirements and how many people carry on-call duty. Ask Arize for your current AX contract terms, including which plan covers span volume, retention, SSO and support. Then ask a provider for a written quote that lists each infrastructure component and the one-time migration work separately from the recurring run costs.

How long does a move from Arize AX to Phoenix take?

The duration depends mostly on the number of instrumented services and how far their tracing already follows OpenTelemetry and OpenInference, the standards Phoenix and AX both use. Services that already export through those standards mainly need their exporter endpoints repointed and tested. Other drivers include how ready your Kubernetes platform is, how much historical data you need to keep or export, how many evaluators and datasets must be rebuilt, and whether you run AX and Phoenix in parallel for a period. Confirm the expected timeline with Arize and in your own environment, and ask for it to be stated as a milestone plan in the written scope before work starts.

What does a Phoenix migration need from our internal engineers?

Three groups of staff carry most of the work. Platform engineers need working knowledge of Kubernetes, ingress, persistent storage, secrets handling and PostgreSQL operations, including backups and restores. Application teams need to change exporter configuration and verify that spans arrive with the attributes their dashboards and evaluators depend on. Evaluation owners need to recreate evaluators, datasets and review workflows and confirm that scores still mean the same thing. Security and legal reviewers should also check the Elastic License 2.0 terms against your use. Ask who on your side will own each group before the engagement starts, since unclear ownership is the most common cause of delay.

Can we run the Phoenix migration without outside help?

Yes, if your team already runs Kubernetes and PostgreSQL in production and has hands-on experience with OpenTelemetry. The harder parts are usually the operational ones that follow the first deployment: backup and restore testing, upgrade procedures, access control, network policy, monitoring of the tracing stack itself, and written runbooks. Teams that lack capacity for those tasks often bring in an implementation partner for a fixed scope. DeployOpen plans, implements, hardens, backs up, upgrades and documents self-hosted open-source platforms inside the client's own infrastructure, and most engagements are fixed-scope with deliverables and timelines agreed in writing. Ongoing support is available as a retainer.

Can we offer Phoenix to our clients as a hosted service under the Elastic License 2.0?

No, the license does not allow it. The Elastic License 2.0 that covers Phoenix forbids providing the software to third parties as a hosted or managed service, so running Phoenix for clients as a service sits outside the terms. Using it internally for your own applications is the use the license is built around. Installing Phoenix inside a client's own environment for that client's internal use is a different arrangement that needs a reading of the license terms against your exact model. Read the LICENSE file in full and have your legal counsel confirm any client-facing arrangement before you commit to it. If you need a managed offering for clients, consider an alternative with a license that permits it.

Do SSO and access controls match Arize AX after the move?

Not necessarily, so confirm this before you plan the cutover. AX is a managed enterprise platform, and its SSO, role management, residency options and support tiers are tied to the contract and plan you hold. Phoenix is an open-source tracing and evaluation tool, and its authentication and access model should be checked against the version you plan to deploy. Ask Arize which AX features your current contract includes, then verify each one against the Phoenix documentation. For any gap, decide whether to close it at the ingress layer, through your identity provider, or by accepting the difference. Document that decision, because auditors will ask how access to trace data is controlled.

Which AX features do we lose when we move to Phoenix?

Start with the features that your team uses every week, then check each one against Phoenix before you commit. Phoenix covers tracing and evaluation built on OpenTelemetry and OpenInference, but AX also includes managed operations, enterprise support and plan-based features that vary by contract. Build a list from your AX usage: online evaluations, datasets and experiments, prompt tooling, alerting, retention settings, user management and any integrations your dashboards rely on. Mark each item as available, available with changes, or lost. Share the list with Arize and with the teams that own those workflows, so that losses are accepted by someone who understands their impact.

What does running Phoenix on Kubernetes with PostgreSQL involve?

Running Phoenix with a PostgreSQL backend means your team owns the database as well as the application. Plan for persistent volumes, a backup schedule with tested restores, connection limits, and a way to apply database upgrades without losing trace data. Decide early whether you need high availability for the database and the Phoenix pods, and how traffic reaches them through ingress and TLS. Confirm the supported PostgreSQL versions and the storage settings in the Phoenix self-hosting documentation before you size the cluster. Keep the trace pipeline in mind too: an OpenTelemetry Collector between your services and Phoenix can add batching and retry behavior, and its configuration should follow the vendor's security guidance.

How DeployOpen scopes and runs a Phoenix migration

DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure. For a move from Arize AX to self-hosted Phoenix, we start with a written scope that separates the instrumentation you keep from the managed features you give up, then build and hand over the deployment in your environment.

How we scope

Inventory which Arize AX features your teams use today and mark which ones Phoenix does not replace
Confirm your Kubernetes cluster, PostgreSQL, ingress, storage and identity setup before any build work
Record the Elastic License 2.0 use case in writing, including internal use only and no offering to third parties
Agree deliverables, timelines and exclusions in a fixed-scope written document before work starts

How we build

Deploy Phoenix on your Kubernetes cluster with PostgreSQL as the backing store in your own accounts
Repoint existing OpenTelemetry and OpenInference exporters to the self-hosted Phoenix endpoint
Configure access controls, network policies and secrets handling to match your internal security standards
Test trace ingestion, evaluation runs and retention settings against a representative set of your workloads

How we hand over

Document the architecture, configuration, exporter changes and the list of AX features no longer available
Provide runbooks for upgrades, database backups, restores and routine health checks
Walk your platform and security teams through the deployment and the licensing boundaries
Deliver evidence of configuration and testing that your internal auditors can review, without us issuing any attestation

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover
Retainers can cover Phoenix version upgrades, PostgreSQL maintenance and exporter changes as your services evolve
Ask any provider to confirm the Phoenix release, Kubernetes version and database version they will target
Ask how changes to the Elastic License 2.0 terms or Phoenix features would be assessed under your retainer