Langfuse vs Arize Phoenix: which to choose

Langfuse vs Arize Phoenix: which one fits your team

If your team is shortlisting self-hosted LLM tracing and evaluation tools, the first question is which license your use case can live with. Langfuse fits teams that want an MIT-licensed core with no feature limits in the open source edition, and that are ready to run a multi-service stack: a web and a worker container backed by PostgreSQL, ClickHouse, Redis or Valkey, and S3-compatible blob storage. Controls such as project-level RBAC, data retention policies, audit logs, server-side data masking and SCIM sit behind an Enterprise license key, so if those are mandatory, get the key requirements in writing before you commit.

Arize Phoenix fits teams that want a lighter footprint. Phoenix is licensed under the Elastic License 2.0, which is source-available rather than OSI-approved, and it starts on a file-based SQLite database by default, with PostgreSQL available through PHOENIX_SQL_DATABASE_URL or separate connection variables. Self-hosted authentication covers OAuth2, LDAP and local accounts with role-based permissions. Phoenix's self-hosting documentation says it is free to self-host with no feature limitations, so a single-node pilot can run with far fewer moving parts than a Langfuse deployment.

The decision turns on four questions. First, will anyone offer the tool as a hosted or managed service to third parties, since ELv2 forbids that. Second, does your team have the appetite to run and upgrade ClickHouse, which Langfuse requires for traces. Third, which enterprise controls, such as SCIM, masking or retention, are required by your auditors. Fourth, how traces are instrumented: Phoenix is built on OpenTelemetry and OpenInference, and Langfuse also documents OpenTelemetry support, so confirm that your SDKs and frameworks emit the spans each tool needs before you choose.

Which Langfuse vs Arize Phoenix scenario matches your team

This table maps six common buyer situations to the platform that fits each one better and names the condition that would flip the choice. Read each row against your own hosting, licensing and identity requirements, because the right answer depends on whether you need enterprise controls, a hosted offering for customers, or a lighter storage footprint.

Scenario	Better fit and reason	What would make the other option win
Single platform team with small trace volume	Phoenix is a good fit: it is free to self-host with no feature limits, starts on SQLite by default, and can run as one process without ClickHouse.	Langfuse wins if you expect volume growth or want its prompt, dataset and evaluation workflows, which need the web, worker, PostgreSQL, ClickHouse, Redis or Valkey and blob storage stack.
Regulated enterprise needing RBAC and audit logs	Depends on the edition. Langfuse keeps project RBAC, audit logs and retention behind an Enterprise license key; Phoenix lists OAuth2, LDAP and local accounts with role-based permissions in its self-hosting docs.	Confirm with each vendor which controls you need in writing. Phoenix wins if your required controls are covered by its free role model, and Langfuse wins if you need audit logs or retention policies under a license key.
Company offering LLM tooling to external customers	Langfuse is the safer choice for a multi-tenant service you operate, because Phoenix's Elastic License 2.0 forbids providing the software to third parties as a hosted or managed service.	Phoenix can still fit internal use or customer-hosted deployments, where you do not run it as a service for third parties. Ask counsel to review the license text against your offering.
Team already standardized on OpenTelemetry	Phoenix is a strong fit: it is built on OpenTelemetry-based tracing with OpenInference instrumentation, and the same instrumentation also works with Arize's managed platform.	Langfuse also supports OpenTelemetry, so the choice shifts to storage and features. Langfuse wins if you need its prompt management and enterprise features on the same instrumentation.
Team with no ClickHouse experience	Phoenix is easier to start with, since it runs on a file-based SQLite database by default and can use PostgreSQL instead of ClickHouse.	Langfuse self-hosting requires ClickHouse, and its v3 to v4 guide asks for ClickHouse 25.12 or later with roughly 3x disk headroom during backfills. Choose Langfuse only if you will staff ClickHouse operations or use a managed service.
Team needing SCIM provisioning	Langfuse is the platform to check first, because SCIM sits in its Enterprise license key features (org management API with SCIM).	Phoenix's self-hosting docs list OAuth2, LDAP and local accounts, not SCIM, so confirm directly with Arize whether it provisions users automatically. Phoenix wins only if LDAP or OAuth2 covers your provisioning and you do not need SCIM.

How Langfuse and Phoenix are built and what that means for operations

Langfuse and Phoenix take very different paths to a self-hosted deployment. Langfuse asks you to run several stateful services, while Phoenix can start from a single file-based database. The cards below set out each component or deployment choice and the operational work it creates, so you can match the footprint to the team that will run it.

Langfuse core service set

A self-hosted Langfuse deployment runs two application containers, Langfuse Web for the UI and APIs and Langfuse Worker for asynchronous event processing. Both sit on PostgreSQL, ClickHouse, Redis or Valkey, and S3-compatible blob storage. Each of those backing services is a system you patch, back up, monitor and size. Before committing, confirm who on your team owns each one and how backups for ClickHouse and blob storage will be restored.

Langfuse Compose and Kubernetes paths

Langfuse documents Docker Compose on a single VM for testing, with no high availability, and Kubernetes with Helm or Terraform-based deployments on AWS, Azure and GCP for production. Compose is quick to stand up but does not meet a production availability target by itself. Kubernetes adds cluster operations to the scope. Ask your platform team which path matches the on-call model you already run before choosing.

Langfuse minimum resources

Langfuse's scaling guide lists minimums of 2 CPU and 4 GiB for web, worker and PostgreSQL, 1 CPU and 1.5 GiB for Redis or Valkey, and 2 CPU and 8 GiB for ClickHouse. It advises at least 16 GiB of ClickHouse memory for larger deployments. Budget these as recurring infrastructure cost, and expect ClickHouse to drive most of the sizing decision as trace volume grows.

Langfuse scaling and upgrade effort

Langfuse recommends scaling worker containers on CPU load and, under heavy ingestion, splitting langfuse-web into separate ingestion and user interface deployments. Minor updates within a major version apply database migrations automatically at startup, while major upgrades follow dedicated migration guides. The v3 to v4 guide requires ClickHouse 25.12 or later and advises about 3x ClickHouse disk headroom when backfilling historic data. Plan that headroom before you upgrade.

Phoenix SQLite default storage

Phoenix starts with a file-based SQLite database by default, so a first deployment needs no separate database service. That keeps the initial footprint small for evaluation or a single team. The trade-off is that you carry the file's backup, locking and growth limits yourself. Confirm the expected trace volume and whether more than one Phoenix process will write to the same store before relying on the default.

Phoenix PostgreSQL option

Phoenix also supports PostgreSQL through the PHOENIX_SQL_DATABASE_URL variable or separate connection variables. Moving to PostgreSQL moves storage into a database your organization may already operate, with its existing backup and high availability practices. Confirm with Arize which Phoenix versions and schema changes are supported on PostgreSQL, and how the database is migrated if you start on SQLite first.

Phoenix deployment targets

The Phoenix self-hosting docs list deployment by terminal, Docker, Kubernetes, Helm, AWS CloudFormation, Railway, Render, Google Cloud Run and Azure ARM templates. Because the same server runs on many targets, the choice follows your cloud and cluster standards more than the product. Keep the deployment target in your change process so that a move between targets does not also become a storage migration.

Phoenix resource minimums to confirm

The resource minimums for Phoenix were not part of the sources reviewed for this comparison, so do not size a Phoenix deployment from Langfuse's figures. Ask Arize for the CPU, memory and storage requirements for your expected trace volume, and for the recommended production topology. Request those figures in writing alongside the deployment target you plan to use, so your sizing can be checked against them.

What the Elastic License 2.0 limits for Phoenix and what the MIT core gives Langfuse

Phoenix is licensed under the Elastic License 2.0 (ELv2), which is source-available rather than an OSI-approved open source license. The license is clear on one point that matters for service providers: it forbids providing the software to third parties as a hosted or managed service. It also forbids circumventing license key functionality. Langfuse's core is MIT Expat licensed, with code inside its ee directories under a separate enterprise license, so the license boundary is drawn by directory rather than by the product as a whole.

Source-available: ELv2 lets you read, run and modify Phoenix, but it is not an OSI-approved open source license, so open source procurement policies may treat it differently.
Hosted service limit: Offering Phoenix to third parties as a hosted or managed service is prohibited under ELv2, which matters if you run it for customers or partners.
License key circumvention: ELv2 forbids bypassing license key functionality, which becomes relevant only if a feature is gated by a key.
MIT core: Langfuse's code outside the ee directories is MIT, and its LICENSE file sets out the boundary.
Enterprise directories: Code inside the ee, web/src/ee and worker/src/ee directories falls under a commercial license.

Have counsel read the Phoenix LICENSE file and the Langfuse LICENSE file against your planned deployment model before you commit.

Langfuse vs Arize Phoenix on tracing, evaluations and storage

This table compares Langfuse and Arize Phoenix on license, instrumentation, evaluations, storage, authentication and governance features that matter when you run either one in your own infrastructure. Read each row as a question to answer for your own deployment, since a few cells are marked for confirmation rather than filled with unverified detail. The main takeaway is that Phoenix's license limits hosting as a service, while Langfuse's core features are MIT licensed, and the enterprise governance features in Langfuse sit behind a license key.

Capability	Langfuse	Arize Phoenix
License	MIT Expat for the core repository, with a separate enterprise license for the ee directories	Elastic License 2.0 (source-available, not OSI-approved), which forbids offering Phoenix to third parties as a hosted or managed service
OpenTelemetry and OpenInference support	OpenTelemetry tracing documented; confirm the exact SDK and instrumentation coverage in Langfuse's OpenTelemetry guide	OpenTelemetry-based tracing with OpenInference instrumentation, which the README says also works with Arize AX
Evaluations	Supported in the open source edition; confirm the current evaluator types and how they run in your version	LLM-based evaluations listed in the README; confirm which evaluators and judge models you need
Versioned datasets and experiments	Confirm dataset versioning and experiment comparison behavior against the current docs	Versioned datasets and experiments listed in the README
Prompt management	Supported; protected prompt labels are an Enterprise license key feature	Prompt management listed in the README; confirm version and access controls
Remote MCP server	Confirm availability before relying on it	Remote MCP server listed in the README
Self-hosted storage	Two containers (web and worker) with PostgreSQL, ClickHouse, Redis or Valkey and S3-compatible blob storage	Single service with a file-based SQLite database by default, with PostgreSQL as an option
Default database	Not applicable, since Langfuse expects PostgreSQL and ClickHouse from the start	SQLite
PostgreSQL support	Required for transactional data; PostgreSQL 15 or later for the v3 to v4 upgrade path	Supported through PHOENIX_SQL_DATABASE_URL or separate connection variables
Authentication options	Single sign-on and authentication options are documented; confirm which providers your edition supports	OAuth2, LDAP and local accounts
RBAC	Project-level RBAC roles require an Enterprise license key	Role-based permissions in self-hosted deployments; confirm the role model against your needs
Audit logs and SCIM	Audit logs and the org management API with SCIM require an Enterprise license key	Confirm whether audit logs or SCIM provisioning are available in your deployment

How authentication and SSO differ in self-hosted deployments

Phoenix ships its own sign-in options, and Langfuse gates its identity controls behind a license key. Self-hosted Phoenix supports OAuth2, LDAP and local accounts with role-based permissions, according to the Phoenix self-hosting docs. Langfuse's authentication and SSO documentation covers how sign-in is configured on a self-hosted instance, but project-level RBAC roles, audit logs, the org management API with SCIM and the instance management API are listed as Enterprise license key features. An identity team should therefore treat the two products as different starting points: Phoenix's access model is available as shipped, while Langfuse's advanced access controls depend on whether a license key is purchased.

Before you choose, put the same questions to both vendors in writing. Ask which identity providers each one supports for sign-in, and whether the list is covered by the open source edition or only by a paid tier. Ask how group or role claims from your provider map to application roles, and whether mapping is automatic or must be maintained by hand. Ask how deprovisioning works: whether a user removed from your directory loses access at once, whether existing API keys or sessions survive, and whether SCIM is the only automated route. For Langfuse, confirm directly with the vendor whether any SSO feature you need sits in the open source edition, since the free plan and the Enterprise key list do not answer that for every feature.

Confirm these answers against a test instance before you commit to either product. Run a sign-in with your real identity provider, remove a test user, and check how long access takes to end and which artifacts remain. Record which roles you need for trace viewers, prompt editors and administrators, and check whether each product can express them without manual steps. If your policy requires automated joiner and leaver processes, plan for that work in the scope of either deployment, because the answer determines whether an Enterprise license key or a custom integration is part of the cost.

What drives the running cost of each platform

Running cost for either tool is mostly staff time and infrastructure, not license fees. Phoenix self-hosting carries no license fee, while Langfuse adds data services and optional Enterprise features that change the bill. The cards below separate what you pay once from what recurs, and what to request in a quote.

Multi-service infrastructure footprint

Self-hosted Langfuse runs a web container, a worker container, PostgreSQL, ClickHouse, Redis or Valkey and S3-compatible blob storage. Langfuse's scaling guide sets minimum resources of 2 CPU and 4 GiB for web, worker and PostgreSQL, and 2 CPU and 8 GiB for ClickHouse, with at least 16 GiB of ClickHouse memory for larger deployments. Phoenix defaults to a single service with file-based SQLite, so its footprint starts much smaller. Ask your team to model trace volume against the ClickHouse memory guidance before sizing.

Data platform operations skills

Langfuse places ClickHouse and PostgreSQL in your operating scope, so someone on your team must handle backups, upgrades, storage growth and failover for both. Phoenix can run on SQLite for a small team, and PostgreSQL is an option when you need a shared database. Confirm whether your platform team already runs ClickHouse in production. If not, budget for that learning curve or ask a services provider to cover it in writing.

Enterprise license and support tiers

Self-hosted Langfuse is free to run in its MIT edition, but project-level RBAC, data retention, audit logs, server-side masking and SCIM need an Enterprise license key. Langfuse's self-hosted pricing page lists a custom-priced Self-Hosted Enterprise plan with a named support engineer and a support SLA. Phoenix is free to self-host with no feature limitations and no license fees. Ask the Langfuse sales team for the key's fee, renewal terms and whether the SLA covers ClickHouse incidents.

Major version upgrade requirements

Langfuse applies minor updates within a major version automatically at startup, but the v3 to v4 guide requires ClickHouse 25.12 or later, with 26.4 recommended, PostgreSQL 15 or later and Redis 7.0 or later. It also advises about 3x ClickHouse disk headroom when backfilling historic data. Plan that disk capacity and a staging rehearsal before you upgrade. Phoenix self-hosting has no equivalent data model migration described in the supplied sources, so confirm its upgrade path against its releases before comparing effort.

External services and retainers

Most implementation work is fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. Ongoing support, upgrades and continuous testing are available as retainers. A one-time fixed-scope deployment and hardening project is separate from a recurring retainer that covers upgrades and monitoring. For either tool, ask for the deliverables list, the handover of runbooks, and which upgrades and incidents the retainer covers. DeployOpen does not publish a price list, so request a written quote built from your scope.

Moving traces, prompts and datasets between Langfuse and Phoenix

This sequence lets a team move LLM tracing from Langfuse to Phoenix, or back, with a clear record of what transfers as-is, what is rebuilt and what still needs confirmation with each vendor before cutover.

Inventory current instrumentation and integrations
List every service that sends traces today and record how each one does it: Langfuse SDK calls, Langfuse-specific integrations, or OpenTelemetry exporters. Note which spans carry OpenInference attributes, since Phoenix uses OpenInference instrumentation. Engineering owns this list, and it is done when every trace source has one owner and one instrumentation method written down. Teams that already emit OpenTelemetry spans will find the least rework, because those spans can be sent to both tools.
Decide which history must survive the move
Agree with product, evaluation and compliance owners which traces, scores, prompt versions and datasets must remain queryable after cutover, and for how long. Retention rules in your own policy, not in either tool, set this boundary. Record the decision in a short written list so later steps have a clear target. The output is a signed-off list of data classes marked keep, archive or drop, with the owner for each.
Export or re-create datasets and prompts
Ask each vendor, in writing, which export formats and APIs exist for datasets, prompt versions and evaluation results. The supplied research does not confirm a direct migration path between Langfuse and Phoenix, so treat any transfer as unverified until the vendor confirms it. Where no export exists, re-create the most important datasets and prompt versions in the target tool from your own source files. Done means each item on the keep list has either a verified export or a documented re-creation step with an owner.
Rebuild evaluators, dashboards and access controls
Evaluators, dashboards, alerts, role assignments and access groups do not carry over automatically on the basis of anything in the supplied facts, so plan to rebuild them in the target tool. Phoenix supports OAuth2, LDAP and local accounts with role-based permissions, while Langfuse project-level RBAC roles and SCIM provisioning sit behind an Enterprise license key, so map each existing role to what the target edition provides. The output is a rebuilt-items register with an owner and a check that each evaluator produces the same scores on a sample of recent traces.
Run both tools in parallel during cutover
Send traces to the existing tool and the new tool at the same time, using OpenTelemetry exporters where possible so no service is changed twice. Compare span counts, latency attributes and evaluation scores between the two for a representative window of production traffic. Confirm that the new store's storage and resourcing hold up, since Phoenix can run on SQLite by default and PostgreSQL is available for larger deployments. Done when the two stores agree within the tolerance your team sets in advance.
Switch instrumentation endpoints service by service
Change each service's exporter or SDK endpoint to the new tool, one service at a time, starting with the lowest-risk workload. Keep the old endpoint configuration in version control so it can be restored quickly. Each switch is confirmed when the new tool shows traces for that service with the expected attributes and the old tool shows no new data from it. Track the switched services on the inventory from step one.
Verify evaluations and reporting on the new store
Run the rebuilt evaluators against live and historical samples on the new tool and compare results with the old tool's outputs for the same inputs. Check that any compliance or review reports that depend on evaluation history can still be produced from the new store. Sign-off belongs to the evaluation owner and the compliance lead together. The check is complete when discrepancies have been explained or fixed and the report owners have accepted the output.
Retire the old store under a written plan
Once every service has switched and the keep list is verified, set a read-only period on the old tool and confirm with the vendor how data is exported and deleted, including backups and any data stored in your own infrastructure. Decommission the old database and blob storage only after the retention decisions from step two are satisfied. The closing check is a signed decommission record listing what was archived, where it sits, and who approved its deletion.

Where self-hosted Langfuse and Phoenix projects usually run long

The longest part of a self-hosted Langfuse project is usually the data platform, not the observability tool itself. A production Langfuse deployment runs Langfuse Web and Langfuse Worker alongside PostgreSQL, ClickHouse, Redis or Valkey, and S3-compatible blob storage. Each of those needs a sized instance, backups, network paths and an owner. The Langfuse scaling guide lists minimums of 2 CPU and 4 GiB for web, worker and PostgreSQL, 1 CPU and 1.5 GiB for Redis or Valkey, and 2 CPU and 8 GiB for ClickHouse, with at least 16 GiB of ClickHouse memory for larger deployments. Docker Compose on one VM is documented for testing and lacks high availability, so plan the Kubernetes path early if the instance will hold production traces. Also plan major version upgrades as separate work. The v3 to v4 guide requires ClickHouse 25.12 or later, PostgreSQL 15 or later and Redis 7.0 or later, and advises about 3x ClickHouse disk headroom when backfilling historic data. Confirm current versions against the Langfuse upgrade guide before you set a date.

Phoenix is faster to stand up, but its decisions still take time. A single Phoenix service can run from a terminal, Docker or Kubernetes, and it starts on a file-based SQLite database by default. Moving to PostgreSQL through PHOENIX_SQL_DATABASE_URL or the separate connection variables is a decision to make before trace volume grows, because it changes backup and retention ownership. Authentication is the other common delay. Self-hosted Phoenix supports OAuth2, LDAP and local accounts with role-based permissions, so the identity team must choose the provider, map roles and approve group membership before users can log in. Across both tools, the usual delays are the same: storage and network approvals, instrumentation rollout across services that each need OpenTelemetry or OpenInference configuration, evaluation design that someone must own, and access control reviews of who can see prompts and traces. Timelines for either tool should come from a written scope that names these items, which is how DeployOpen engagements are set up before work starts.

Langfuse vs Arize Phoenix questions buyers ask before hiring help

How much effort does self-hosting Langfuse take compared with Phoenix?

Phoenix is the lighter install, and Langfuse is the heavier one that gives you more moving parts to run. Phoenix starts with a file-based SQLite database by default and can also use PostgreSQL, so a pilot can run as a single service. Self-hosted Langfuse runs a web and a worker container backed by PostgreSQL, ClickHouse, Redis or Valkey and S3-compatible blob storage. Langfuse's scaling guide lists minimum resources of 2 CPU and 4 GiB for web, worker and PostgreSQL, 1 CPU and 1.5 GiB for Redis or Valkey, and 2 CPU and 8 GiB for ClickHouse. Effort rises with trace volume, the number of stores you back up and whether you run Kubernetes. Confirm sizing against your expected ingestion volume before you commit to a design.

What skills does the team need to run either tool in-house?

Both tools need someone who can operate containers, manage databases and handle secrets, but Langfuse adds ClickHouse and object storage to that list. For Phoenix, a team comfortable with Docker or Kubernetes, PostgreSQL and an OpenTelemetry-instrumented application can usually cover the work. For Langfuse, the team also needs to plan ClickHouse capacity, handle the Redis or Valkey queue and run S3-compatible storage with backups. Langfuse's v3 to v4 guide requires ClickHouse 25.12 or later, PostgreSQL 15 or later and Redis 7.0 or later, so someone must track those prerequisites during upgrades. Ask your provider to name which of these skills it covers and which it expects you to supply.

Can one engineer run Langfuse or Phoenix alone?

One engineer can run a Phoenix pilot alone, and a single engineer can often keep a small Langfuse Docker Compose test environment going. Production Langfuse is harder to cover with one person because Langfuse documents Docker Compose on a single VM only for testing, with no high availability, and recommends Kubernetes with Helm or Terraform for production. Plan for a named backup operator, on-call coverage for the worker queue and a regular upgrade window. The real constraint is bus factor, not installation time. Decide who owns backups, restore tests and version upgrades before the first production trace arrives.

Can we offer Phoenix to our customers as a hosted service under ELv2?

No, not without a separate commercial arrangement with Arize. Phoenix is licensed under the Elastic License 2.0, which forbids providing the software to third parties as a hosted or managed service and forbids circumventing license key functionality. ELv2 is source-available rather than OSI-approved open source. Internal use by your own teams, including self-hosting in your own infrastructure, is the scenario the license is built around. Langfuse's MIT-licensed code outside its ee directories has no such restriction, but you should still have counsel review any hosted offering against both licenses. Ask your legal team to confirm the terms before you design a customer-facing product.

When do we need a Langfuse Enterprise license key?

You need a Langfuse Enterprise license key only when you want features that sit behind it. The MIT-licensed open source edition includes all core features and APIs without limits. The key unlocks project-level RBAC roles, protected prompt labels, data retention policies, audit logs, server-side data masking, UI customization, organization creators, and the org management API with SCIM and the instance management API. Those features matter most to regulated teams that need access control, retention enforcement and audit evidence. Langfuse's self-hosted pricing page describes a custom-priced Self-Hosted Enterprise plan, so ask for a written quote tied to the specific features you need.

How long does a typical self-hosted rollout take?

The duration depends on the written scope, and no supplied figure applies to every deployment. A rollout's length is driven by the number of environments, the identity integration, whether you run Kubernetes or a single VM, how many applications instrument traces and how much data migration is involved. A Phoenix pilot with a single instrumented service will usually take less time than a production Langfuse deployment with SSO, retention rules and backup testing. Ask the provider to list milestones, acceptance criteria and the client actions each milestone depends on, then compare timelines against that list rather than a generic estimate.

How hard is it to switch between Langfuse and Phoenix later?

Switching is most practical if you instrument with OpenTelemetry and OpenInference from the start, because both tools accept that tracing data. Phoenix states that the same OpenTelemetry and OpenInference instrumentation works with both Phoenix and Arize's managed platform. Langfuse also documents OpenTelemetry tracing. The harder part is historical data, prompts, datasets and evaluation results, which each tool stores in its own model. Plan an export path for datasets and evaluations, and test a restore into the target tool before you retire the old one. Ask any provider to price the migration as a separate written scope.

What should we ask for in a quote for either tool?

Ask for a written scope that names each deliverable, the environments covered and the client actions required. Request a breakdown of who does each task: architecture, deployment, identity integration, backup and restore testing, upgrades and documentation. Ask whether the quote covers a fixed scope or a retainer for ongoing support and upgrades, and what is one-time versus recurring. Confirm which licensed features, such as the Langfuse Enterprise key, are priced separately and which vendor subscriptions you buy directly. Finally, ask what is excluded, how changes to scope are priced and what evidence you will receive at handover.

How DeployOpen helps choose, implement or migrate LLM observability

DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure. For Langfuse vs Arize Phoenix, we start from your license constraints, tracing standards and storage requirements, then work through the deployment in your environment.

How we scope

Written scope fixes which observability platform, environments, instrumented applications and integrations are covered
We confirm license fit, including whether any hosted or managed use is planned for Phoenix under ELv2
We agree which Langfuse features need an Enterprise license key before work starts
Engagements are fixed-scope, with deliverables and timelines agreed in writing up front

How we build

We deploy the chosen stack in your cloud account, data center or air-gapped network
For Langfuse, we size PostgreSQL, ClickHouse, Redis or Valkey and blob storage against your trace volume
For Phoenix, we choose SQLite or PostgreSQL storage and configure OAuth2, LDAP or local accounts
We instrument sample applications with OpenTelemetry and OpenInference and test evaluations and datasets

How we hand over

You receive documentation covering architecture, configuration keys, access roles and upgrade steps
We run a handover session so your platform team can operate tracing, evaluations and backups
Data residency, retention and where traces, prompts and blobs are stored are recorded in writing
Runbooks cover version pinning, major upgrade paths and rollback for your chosen platform

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover
Retainers can cover tracking of new releases, schema migrations and security patch review
We can prepare evidence about your observability setup for compliance assessments, though auditors issue the reports
Confirm response expectations and any support SLA in the written retainer before you commit

Langfuse vs Arize Phoenix