Open-source alternative to Arize prompt management

Which open-source tool replaces Arize prompt management and the playground?

If prompts live in Arize AX and a renewal, licensing review or residency rule is pushing you to move, Phoenix, Langfuse and Opik each cover prompt management and a playground when self-hosted, and the main difference between them is licensing. Phoenix is licensed under the Elastic License 2.0, which is source-available rather than OSI-approved and bars offering the software to third parties as a hosted service. Langfuse core is MIT licensed outside its ee directories, and Opik is Apache-2.0 with prompt management and a playground included in the self-hostable platform. Confirm the license terms against the current LICENSE file in each repository before you commit.

The prompt library itself is usually the easiest part to move. Exporting prompt text and variables is a small job compared with the work that follows. The hard part is keeping each prompt version linked to the traces it produced and the experiments that scored it. Check how each candidate stores a prompt version identifier on a span, whether labels such as production or staging can be promoted without a redeploy, and whether experiments can reference a specific version. In Langfuse, protected prompt labels are an Enterprise license key feature, so confirm whether your team needs that control before you plan the cutover.

DeployOpen plans and implements these platforms inside your own cloud accounts, data centers or air-gapped networks, and it can map your existing prompt versions, labels and experiment history to the target tool as part of a written, fixed scope. DeployOpen does not publish prices. A quote follows from the agreed scope, which should list the prompt count, the number of environments, the trace linkage you must preserve and any Enterprise features your governance model requires.

Mapping Arize prompt capabilities to open-source options

This table maps the prompt capabilities you use in Arize AX to Phoenix, Langfuse and Opik, with the license or plan that gates each one. Check each row against your own Arize AX prompt export, since a capability only replaces the original if it covers your versions, labels and access rules. The main takeaway: Langfuse's protected labels and project RBAC need an Enterprise license key, while Opik and Phoenix list prompt management as part of their self-hosted platforms.

Capability	Arize Phoenix (ELv2)	Langfuse (MIT core)	Opik (Apache-2.0)
Prompt versioning	Prompt management is listed in the README. Confirm version history and rollback in your build.	Confirm version history and rollback behavior in the release you deploy.	Prompt management is included in the self-hosted platform. Confirm version history in your deployment.
Labels and environments	Confirm whether labels can map to your AX tags or environments such as staging and production.	Labels are supported. Protected prompt labels require an Enterprise license key.	Confirm how labels or tags are assigned and promoted between environments.
Playground	Confirm playground availability for your Phoenix version before relying on it.	Confirm playground availability in the version you deploy.	A prompt playground is listed as a feature of the self-hosted platform.
Variables and templates	Confirm template syntax matches your AX prompts, which often need light rewriting.	Confirm variable syntax and how it is handled in SDK calls.	Confirm template syntax and variable substitution against a sample of your prompts.
Link to traces and experiments	Prompts, datasets and experiments sit in one tool. Confirm that each trace records the prompt version used.	Confirm the prompt version is attached to each generation in your SDK or OpenTelemetry setup.	Tracing, evaluations and prompts share one platform. Confirm the prompt version is recorded on each trace.
Access control	Supports OAuth2, LDAP and local accounts with role-based permissions.	Project-level RBAC roles require an Enterprise license key.	Confirm the workspace and role model in your deployment before granting edit rights.
Protected prompts	Confirm whether prompts can be locked against edits for production use.	Protected labels require an Enterprise license key.	Confirm whether edit locks exist. Do not rely on them until tested.
Audit trail of prompt changes	Confirm what change history is recorded and where it is stored.	Audit logs require an Enterprise license key.	Confirm change history and retention in your deployment.

Which option fits which prompt workflow

Phoenix is the closest match for teams that already instrument with OpenTelemetry and OpenInference and want to keep Arize's instrumentation while running the tool themselves. Its README lists prompt management alongside tracing, versioned datasets and experiments, so prompts, traces and evaluation runs live in one self-hosted service. The trade-off is licensing. Phoenix is licensed under the Elastic License 2.0, which allows internal self-hosting but forbids offering the software to third parties as a hosted or managed service, and it is source-available rather than OSI open source. The self-hosting docs state there are no feature limitations, license fees or usage limits, and that prompts and traces stay in your infrastructure, including air-gapped deployments. Components to plan for include a SQLite default for small installs and PostgreSQL through PHOENIX_SQL_DATABASE_URL for production, plus OAuth2, LDAP or local accounts with role-based permissions. Relative to Arize AX, confirm which prompt and playground features in AX your team uses today, because the open-source feature set may not match them one for one.

Best fit: teams standardizing on OpenTelemetry and OpenInference that accept ELv2 for internal use.
Licensing: source-available, so legal review is needed if you ever plan to offer it as a managed service to customers.
Components: the Phoenix service with SQLite or PostgreSQL, deployed by Docker, Kubernetes or Helm.
Access control: OAuth2, LDAP or local accounts with role-based permissions.
Gap to check: compare the playground and prompt workflow you use in AX against Phoenix's current features.

Confirm the playground behavior and prompt versioning you depend on with a Phoenix trial before you plan the cutover.

How to keep prompt versions tied to traces and experiments

A trace or experiment result is only useful if you can tell which prompt version produced it. Once prompts move from Arize AX to a new platform, the question changes from "what did this prompt return?" to "which prompt name, version and label was live when this span ran?" Without that link, a regression in production cannot be traced back to a prompt change, and a score in an experiment cannot be compared fairly across prompt revisions. Decide the linkage before you repoint any exporter, because it is much harder to reconstruct history afterward.

The usual pattern is to write the prompt name and version or label onto every span as metadata or attributes. With OpenTelemetry, that means custom span attributes set by your instrumentation. With each platform's SDK, it means the metadata or tags the SDK accepts on a trace or an experiment run, or the prompt reference the SDK fetches at runtime. Phoenix, Langfuse and Opik each have their own conventions for these keys, and they can differ from the attribute names you used with Arize. Treat the key names in this section as a design choice to confirm, not a fixed standard, and check them against each platform's current documentation and your own instrumentation code before you rely on them.

After the move, validate the link with a short test set: run a known prompt version, confirm the trace shows the expected name and version, change the label, rerun, and check that the new spans carry the new value. Then compare one experiment run from the old platform with a rerun on the new one to confirm the scores can be grouped by prompt version. Record the results as migration evidence. Plan for the prompt versions that exist only in the Arize playground or in application code, since those need an explicit export or re-creation step. Have your team confirm each platform's version and label semantics before cutover, especially how labels such as production move between versions.

Running prompt management beside the rest of your LLM stack

Prompt management rarely runs alone. It sits between your gateway, identity provider, tracing, evaluators and CI, and each link can drift once Arize AX is gone. The cards below cover the parallel concerns to settle before cutover, and each one should be confirmed against the current docs of the products you choose.

Keep one call path through the gateway

Route every application call through a single gateway, such as LiteLLM, so prompt versions, model choice and logging are decided in one place. LiteLLM documents logging to Langfuse, Datadog, OpenTelemetry and Prometheus, but the exact callback names and fields change between releases. Confirm the integration in the current LiteLLM and Langfuse docs before you rely on it, and test that the prompt version reaches the trace. Bypassing the gateway breaks the link between a prompt and its traces.

Align SSO and roles with the identity provider

Decide who can edit prompts, who can promote a version to production and who can only read. Self-hosted Langfuse documents SSO and authentication options, but project-level RBAC roles and protected prompt labels need an Enterprise license key. Phoenix supports OAuth2, LDAP and local accounts with role-based permissions. Map each role to a group in your identity provider and test that removing a user there also removes access to the prompt tool.

Feed evaluators from the same trace IDs

Evaluation scores are only useful when they point at the trace and prompt version that produced them. Export the trace ID and prompt name and version into each evaluation run, whether you use Langfuse, Phoenix or Opik metrics. Check that OpenTelemetry spans from your instrumentation carry the attributes your evaluators read, because a missing attribute produces scores with no prompt context.

Separate CI prompt tests from production labels

Run prompt regression tests in CI against a test dataset and a candidate version, and only move the production label after the tests pass. Keep the test artifacts and the production label in separate namespaces so a failing branch cannot overwrite the version live users receive. Record which CI run approved each promotion, since that approval is part of your change evidence.

Keep prompt data in one infrastructure boundary

A self-hosted prompt store only keeps prompts in your environment if the gateway, tracing and evaluation services also run there. Check where each component sends data, including any control plane or telemetry endpoint, and whether it runs in air-gapped mode if you need it. Write the data flow down so the security review covers every hop, not only the prompt database.

Moving prompt versions out of Arize AX

This sequence moves your production prompts, their version history and their labels from Arize AX into a self-hosted store, and proves that new traces still link back to the exact prompt version that produced them. The result is a prompt library you control, with a verified cutover and a documented record of the AX prompts you retired.

Inventory prompts, versions and live usage
Have the engineer who owns the LLM application list every prompt template in Arize AX, along with its version history, the variables each template expects and the application code paths that fetch it. Mark which version is live in production and which one staging uses, since those are the labels you must reproduce. The step is done when you have a spreadsheet or file with one row per prompt, version and consuming service, reviewed by the product owner who signs off on which versions matter.
Export prompts from Arize AX
Export the inventory from AX using the Arize tooling for prompts, or copy each template by hand if the number of prompts is small enough to review line by line. Save the exported text, variable names and metadata in version control so that the source is preserved after the move. Confirm the export against the AX interface for a sample of prompts, checking that the text matches character for character, including system messages and template syntax. The step is done when every inventoried version exists in your repository with a matching checksum or reviewed diff.
Recreate prompts in the target platform
Create the prompts in your chosen self-hosted platform, whether Phoenix, Langfuse or Opik, and import versions in their original order so the history reads the same way. Assign labels that mirror production use, for example a production label on the version currently serving traffic and a staging label on the candidate. Check the platform's own documentation for how labels and versions are represented, since the names and behavior differ between tools. The step is done when a test fetch by label returns the expected text for each prompt.
Repoint the application to the new prompt store
Change the application so it fetches prompts from the self-hosted store by name and label, not from AX, and keep the AX fetch path behind a configuration flag so you can switch back during the test window. Make sure the code records the prompt name and version on each generation, because that metadata is what links traces to prompt versions later. Run the unit and integration tests for the affected services. The step is done when a staging build fetches every prompt from the new store and passes its existing tests.
Verify trace linkage in staging
Send representative staging requests through each prompt path and open the resulting traces in the new platform. Confirm that each generation shows the prompt name, the version and the label that were used, and that experiments or evaluation runs reference the same version. Compare a sample of outputs against the AX baseline to catch template or variable differences. The step is done when every prompt path produces traces with the correct version attached and you have a written record of the checks performed.
Document playground sessions
Playground sessions in Arize AX are usually ad hoc experiments and generally do not transfer as objects into another platform. Before cutover, ask the team members who used the playground to save the prompt text, model settings and a short note on the conclusions of each useful session in your repository or wiki. Confirm with your platform vendor whether any session or playground history can be imported, and record the answer. The step is done when the useful sessions are preserved as documents and the open questions are written down.
Cut over and retire AX prompts
Switch production to the new prompt store during a window agreed with the application owners, then watch the first production traces for missing version metadata or unexpected outputs. Keep the AX fallback flag available until the owners accept the new traces. Once acceptance is recorded, remove the AX fetch path, archive the exported prompt history and retire the prompts in Arize AX according to your contract and data retention obligations. The step is done when production traces link to prompt versions in the new platform and the AX prompt retirement is recorded.

What do teams ask before moving prompt management?

What does it cost to run open-source prompt management after leaving Arize?

The software itself has no license fee in the options covered here, so cost comes from the components you run and the people who run them. Recurring costs are the compute and storage for the platform, the databases it depends on, backups, and the staff time for upgrades and on-call. One-time costs are the export, re-linking prompts to traces, and testing. Phoenix self-hosting is documented as free with no usage limits. Langfuse self-hosting requires PostgreSQL, ClickHouse, Redis or Valkey, and S3-compatible storage, and Opik requires ClickHouse, MySQL and Redis. Ask any partner for a quote that lists each component, who pays for it, and which items recur. DeployOpen quotes follow from a written scope.

How long does a prompt management migration take?

The duration depends on how many prompts, versions and labels you have, how many applications call them through the SDK or API, and whether prompts are linked to datasets and experiments. Prompt versions are usually the quick part, while repointing applications and proving that old experiments still resolve to the right prompt text takes longer. Infrastructure setup depends on whether you deploy on Kubernetes with Helm or on a single host for testing. No timeline is given here because none is supplied for this migration. Ask for a written scope with deliverables and dates before work starts.

Can our internal engineers move prompts without an outside partner?

Yes, a team with container and database experience can do most of the work, provided it has time for the platform setup and cutover testing. The open-source options are self-hostable without a commercial contract for the core features, so the main question is capacity, not licensing. Teams that stay in-house usually need someone who owns the Kubernetes or Docker deployment, someone who knows the database dependencies, and someone who can run upgrades. A partner is useful when the team lacks that capacity or needs a fixed-scope, documented handover. Be clear about which parts you will own after go-live.

What does the migration need from platform engineers, prompt owners and evaluators?

Each group has a different job. Platform engineers deploy the stack, size the databases, configure authentication and backups, and manage upgrades. Prompt owners confirm which prompt versions are current, which labels mean production, and which versions must stay reproducible for past experiments. Evaluators confirm that scores and datasets still mean the same thing after the move, and they rebuild any evaluators tied to a prompt. Ask for named owners in each group before scope is agreed, because gaps in prompt ownership usually cause more delay than gaps in infrastructure.

Does the Elastic License 2.0 on Phoenix block our use case?

It depends on how you use it. The Elastic License 2.0 that covers Phoenix permits self-hosting for internal use, but it forbids providing the software to third parties as a hosted or managed service, and it is source-available rather than OSI open source. If you run Phoenix only for your own teams, the license is generally not an obstacle, but a product that gives customers access to a hosted Phoenix instance would be. Prompt management in Langfuse (MIT, outside its ee directories) or Opik (Apache-2.0) avoids that question. Have your legal team read the license file before choosing.

What happens to prompt history and experiment links after the move?

Prompt text and version history need to be exported and recreated in the new platform, and the link between a prompt version and the traces and experiments that used it must be rebuilt, not assumed. Check whether each target keeps version identifiers and labels in a form you can map back to your Arize records. Confirm this with a test migration of a small set of prompts before cutover, and keep the source records until old experiments can be reproduced in the new system.

Is a self-hosted prompt store secure enough for regulated data?

A self-hosted platform keeps prompts and traces in your infrastructure, which is the main reason teams choose it. Security then depends on how you configure access and hosting. Phoenix supports OAuth2, LDAP and local accounts with role-based permissions. Langfuse lists project-level RBAC, protected prompt labels and audit logs among features that need an Enterprise license key, so confirm which controls you need before you choose. Compliance readiness work, such as documenting controls and evidence, is separate from any audit, and independent auditors issue reports. Confirm your requirements with the vendor and your own security team.

When licensing and prompt governance change the choice

Phoenix is source-available, not OSI open source. Phoenix is licensed under the Elastic License 2.0, which allows you to self-host it for internal use but forbids providing it to third parties as a hosted or managed service. If your team runs prompts and traces for internal applications, that terms may be acceptable. If you plan to offer an LLM-backed product to customers on a Phoenix instance you operate, or you expect a managed-service arrangement with a partner, have counsel read the license against that plan before standardizing on it. Langfuse core is MIT licensed outside its ee directories, and Opik is Apache-2.0 across its server, UI and prompt management, so neither carries that restriction. Confirm the current terms directly with each vendor and in each repository's LICENSE file, because licensing can change between releases.

Some governance controls in Langfuse need an enterprise license key. Self-hosted Langfuse requires an enterprise license key for project-level RBAC roles and protected prompt labels, among other features. Protected labels matter most for prompt governance because they can restrict who may move a production label to a new prompt version, which is the control that prevents an untested prompt from reaching live traffic. Audit logs, data retention policies and SCIM provisioning also sit behind the key. Ask your security and compliance leads which of these controls an auditor or internal policy will expect, then check whether Phoenix's role-based permissions and Opik's access model cover the same decisions. Where they do not, the enterprise key or a compensating process becomes part of the cost comparison.

Write the governance requirements down before choosing. List who may create prompt versions, who may promote a version to production, how changes are reviewed and how long version history must be retained. Then test each candidate in a non-production instance by attempting an unauthorized promotion and checking whether the trace and experiment record still shows which prompt version ran. Ask each vendor for its current licensing and feature matrix in writing, and record the answers with the date. A decision made on the license and the required controls is easier to defend at renewal than one based only on the playground interface.

Risks to plan for during the prompt move

Moving prompts is less about copying text than about keeping each prompt version linked to the traces, playground sessions and evaluation runs that depend on it. The four risks below are where that link tends to break, and each one has a control you can put in place before cutover.

Silent drift between prompts and traces

After the move, a trace may show a prompt name without recording which version actually ran, especially if application code fetches the latest version by default. Pin each service to an explicit version or label, and record the version identifier as a span attribute so every trace can be read against the exact text that produced it. Check a sample of migrated traces in the new tool before you retire the old one, and confirm with the vendor how each platform records version identifiers on spans.

Lost playground history

Playground sessions, the trial prompts and model comparisons that product and domain experts build up, usually live in the commercial tool's UI and are not included in a trace export. Before cutover, have each team save its working prompts as versioned entries and write down which model, parameters and test inputs were used. Treat playground history as a sign-off artifact, not a convenience, and assign an owner to confirm nothing important stayed behind.

Unprotected production labels

A label such as production that moves a prompt version can change live behavior with one edit, so it needs the same change control as code. In self-hosted Langfuse, protected prompt labels are an Enterprise license key feature, so confirm whether your edition includes them before you rely on them. Where they are not available, restrict who holds prompt-editing roles and require a review step for any change to a production label.

Evaluation scores that no longer match

Scores from an evaluation run only mean something for the prompt version that was tested. If a prompt is edited after an experiment, the dataset and score history can appear to describe a version that no longer runs. Store the prompt version, model and evaluator version with every experiment, and block promotion of a label until a run exists for that exact version. Confirm how each target tool links experiments to prompt versions before you rebuild your evaluation history.

How DeployOpen scopes and delivers a prompt management move

DeployOpen plans, implements, integrates, documents and supports self-hosted open-source platforms inside your own infrastructure, so prompt management and the playground move from Arize AX to a platform you control. We start by inventorying the prompts, versions, labels and experiments that depend on Arize today, then agree the scope in writing before any work begins.

How we scope

Inventory every prompt, version, label and playground workflow currently used in Arize AX, with the owners of each.
Choose between Phoenix, Langfuse and Opik for prompt management based on your licensing, residency and support requirements.
Write the scope, deliverables and timeline in a fixed-scope agreement before work starts, with no price list to read first.

How we build

Deploy the chosen platform in your cloud account, data center or air-gapped network, with its database and storage dependencies.
Recreate prompt versions and labels, and link each prompt version to the traces and experiments that use it.
Test playground runs, prompt retrieval from application code and trace linkage against the prompts you inventoried.

How we hand over

Document the deployment, prompt naming conventions, access roles and the steps to publish a new prompt version.
Provide the configuration and runbooks your platform team needs to operate the instance and rotate its credentials.
Confirm with you which Arize features are retired, and which evidence and records you keep for your own reviews.

How we support

Support upgrades and migrations of the platform, including database changes between major versions, as agreed in scope.
Offer ongoing support, upgrades and continuous testing as a retainer after the handover.
Ask your platform team to confirm licensing terms and any enterprise features with the vendor before go-live.

Open-source alternative to Arize prompt management and playground