Arize Phoenix vs Langfuse vs Helicone: Which to Self-Host in 2026?

Last updated October 13, 2026. Licenses, self-host stacks, pricing, and ownership were checked against each vendor’s docs, GitHub, and pricing pages on that date.

Arize Phoenix vs Langfuse vs Helicone is the three-way shortlist most teams reach once they decide to self-host LLM observability instead of sending traces to a SaaS control plane. All three ship open code, Docker images, and a cloud alternative. They diverge on license, service count, and how you get data in.

This post is the deep self-host comparison. For the wider eight-tool shortlist, see our open source LLM observability guide. Placement is unpaid, per our editorial standards and disclosure policy.

It sits under the AgentOps tools map and next to our best AI agent observability tools roundup. We compare licenses, footprints, integrations, tracing depth, evals, prompts, cost tracking, cloud list prices, and who should pick which.

Arize Phoenix vs Langfuse vs Helicone: The Short Answer

Pick Phoenix if you want one container, OpenInference traces, and free unlimited self-host features under ELv2. Pick Langfuse if you want MIT-licensed core features with prompts, evals, and a production-grade multi-service stack. Pick Helicone if your SRE priority is a logging proxy with caching, rate limits, and a clear request bill.

	Arize Phoenix	Langfuse	Helicone
Center of gravity	Local-first tracing, evals, experiments	Traces + prompts + evals platform	AI gateway / proxy observability
License	Elastic License 2.0 (ELv2)	MIT core; Enterprise modules in ee/	Apache License 2.0
OSI-approved?	No (source-available)	Yes (MIT core)	Yes
Self-host footprint	1 app container + SQLite or Postgres	Web, Worker, Postgres, ClickHouse, Redis, S3	All-in-one image or Compose (Postgres, ClickHouse, MinIO)
Ingestion model	OpenInference / OTLP into Phoenix	SDK, OTel, LiteLLM proxy	Proxy / AI Gateway + SDK logging
Prompt management	Yes	Yes (versioning, cache, labels)	Yes (Playground, prompts)
Evals	Yes (datasets, experiments, judges)	Yes (online/offline, annotation queues)	Scores and datasets on cloud plans
Cost / cache / rate limits	Token cost on spans	Token and cost tracking	Gateway caching, rate limits, fallbacks
Cloud alternative	Arize AX (Free from $0 / 25k spans)	Hobby free; Core $29; Pro $199	Hobby free; Pro $79; Team $799
GitHub stars (Oct 13, 2026)	~11.8k	~35.7k	~6.2k
Owner	Arize AI	ClickHouse (acq. Jan 16, 2026)	Helicone Inc.

How We Compared These Three for Self-Host

We read each vendor’s self-host docs, license pages, pricing pages, and GitHub READMEs on October 13, 2026, and captured the pages we cite. The lens is operational: what you run, what you are allowed to run, how traces arrive, and what the cloud bill looks like if you skip self-host.

• Primary sources only: licenses and stack diagrams come from Phoenix, Langfuse, and Helicone docs.
• No paid bake-off: we did not load-test ingestion or judge accuracy, so there are no star ratings.
• Estimates are labeled: the 500k-span cost example uses published list prices plus stated infra assumptions.
• Related reading: the eight-tool open source LLM observability listicle covers these three among peers; this page goes deep on the three-way self-host choice.

License: ELv2 vs MIT Core vs Apache-2.0

License is the first filter for many SRE and legal reviews. Phoenix is ELv2, Langfuse core is MIT, and Helicone is Apache-2.0. That split decides whether you can offer the product as a managed service and how procurement classifies the code.

Phoenix under Elastic License 2.0

Arize documents Phoenix under the Elastic License 2.0, with free self-hosting on your own infrastructure and no feature gates, per the Phoenix license docs. The same page points at the GitHub LICENSE file for the full text.

ELv2 lets you use, modify, and redistribute with three hard limits: you may not offer Phoenix itself as a hosted or managed service that gives third parties substantial access to its features, you may not remove license notices, and you may not circumvent license-key protections. Internal commercial use of Phoenix inside your own products is allowed.

Langfuse: MIT core, Enterprise modules gated

Langfuse states that all product capabilities outside the ee/ folders are MIT licensed without usage limits, per its open source handbook and license-key docs. Enterprise self-host features such as SCIM, audit logs, data retention policies, and project-level RBAC need a commercial license key.

You can run the same Docker images as Langfuse Cloud for free on the MIT core. Adding LANGFUSE_EE_LICENSE_KEY unlocks the Enterprise modules, per the license-key guide.

Helicone under Apache License 2.0

Helicone documents Apache License 2.0 on its open source page and GitHub README. Apache-2.0 is OSI-approved and permissive for use, modification, distribution, and patent grants, with the usual notice requirements and no SaaS-offering ban like ELv2.

For pure license freedom, Helicone and Langfuse MIT core clear more legal checklists than Phoenix ELv2. Phoenix still wins many teams on footprint and OpenInference depth once counsel accepts ELv2 for internal use.

Self-Host Footprint: One Container vs Full Stack

Day-two ops cost tracks the number of moving parts. Phoenix can start as a single process. Langfuse runs a multi-service architecture that matches its cloud. Helicone offers an all-in-one image plus a fuller Compose or Helm path.

Phoenix footprint

Phoenix is free to self-host with no feature limitations and can be fully air-gapped, per the self-hosting overview. The common path is one Docker image:

docker pull arizephoenix/phoenix
docker run -p 6006:6006 -p 4317:4317 -i -t arizephoenix/phoenix:latest

Port 6006 serves the UI and OTLP HTTP collector; 4317 is OTLP gRPC, per the Docker guide. Default storage is SQLite; set PHOENIX_SQL_DATABASE_URL for Postgres 14+ when you need multi-user production persistence.

Langfuse footprint

Langfuse self-host runs the same infrastructure as Langfuse Cloud: Langfuse Web and Langfuse Worker plus PostgreSQL, Redis/Valkey, ClickHouse, and S3-compatible blob storage, per self-hosting docs. ClickHouse is required for traces, observations, and scores; there is no alternate OLAP backend, per ClickHouse infra docs.

Docker Compose is fine for local testing. Production guidance points at Kubernetes Helm and cloud templates. Plan for five persistent dependencies, not one container.

Helicone footprint

Helicone ships an all-in-one image for quick starts and a Compose path for fuller stacks, per Docker docs. The all-in-one exposes the dashboard on 3000, Jawn API on 8585, and MinIO on 9080, with Postgres and ClickHouse inside the container.

docker pull helicone/helicone-all-in-one:latest
docker run -d --name helicone -p 3000:3000 -p 8585:8585 -p 9080:9080 \
  helicone/helicone-all-in-one:latest

Docs note that Jawn no longer proxies LLM traffic on /v1/gateway/*; run the AI Gateway alongside for proxying. Persist volumes for Postgres, ClickHouse, and MinIO in production, and restrict port 8585, per the same Docker page.

Integration Model: OpenInference vs SDK vs Proxy

How traces enter the system shapes app changes, network topology, and failure modes. Phoenix leans on OpenInference over OpenTelemetry. Langfuse mixes SDKs, OpenTelemetry, and optional LiteLLM proxy logging. Helicone is built as a gateway that sits on the request path.

Phoenix: OpenInference and phoenix.otel

Phoenix is built on OpenTelemetry and OpenInference instrumentation, per Phoenix docs. The common Python setup registers a tracer with auto-instrumentation:

from phoenix.otel import register

tracer_provider = register(
    project_name="my-llm-app",
    auto_instrument=True,
)

Point PHOENIX_COLLECTOR_ENDPOINT at your self-hosted instance (default http://localhost:6006), per setup-using-phoenix-otel. Install OpenInference instrumentors for OpenAI, LangChain, and peers. Spans leave the app over OTLP; the app does not have to proxy user traffic through Phoenix.

Langfuse with SDKs and OpenTelemetry

Langfuse supports native SDKs (Python, JavaScript), OpenTelemetry for Java/Go/custom stacks, LiteLLM proxy-based logging, and a public API, per Cloud plan features and OpenTelemetry docs. Self-host uses the same ingestion paths against your own base URL.

SDK-first instrumentation keeps the control plane off the hot path for user tokens. Proxy logging via LiteLLM is available when you already terminate providers at a gateway.

Helicone: gateway and request logging

Helicone’s product center is an AI gateway and logging proxy: point clients at Helicone, keep provider keys server-side, and get request/response logs, cost, caching, and rate limits. Self-host docs separate the dashboard/Jawn API from the AI Gateway process, per Docker and self-host overview.

If your SRE mental model is “terminate LLM calls at a proxy,” Helicone matches that topology. If your model is “emit OTLP from the app,” Phoenix or Langfuse fit with less path coupling.

Tracing, Evals, Prompts, Cost, and Gateway Controls

Feature depth is closer than marketing pages suggest. The differences that matter for self-host are where each product spends engineering time.

Capability	Phoenix	Langfuse	Helicone
Trace / span UI	Strong (sessions, projects)	Strong (traces, sessions, users)	Strong (requests, sessions, users)
Agent graphs	OpenInference agent spans	Agent traces and graphs	Sessions / custom properties
Prompt management	Prompt iteration in product	Versioning, cache, labels, playground	Prompts + playground on plans
Evals / experiments	Datasets, experiments, judges	Online/offline evals, annotation queues	Scores and datasets (plan-gated on cloud)
Token / cost tracking	On spans	Token and cost tracking	Cost-first request analytics
Caching	App-side / not a gateway cache	Prompt cache (server + client)	Gateway prompt caching
Rate limits / fallbacks	Not a proxy feature	Ingestion and API rate limits	Custom rate limits, automatic fallbacks
Auth on self-host	OAuth2, LDAP, local accounts	SSO options; EE for org SSO features	Auth in all-in-one; harden for prod

Tracing depth

All three store hierarchical spans with model metadata. Phoenix’s OpenInference conventions make agent, chain, and tool spans consistent across frameworks. Langfuse emphasizes sessions, users, and multi-modal attachments via S3. Helicone emphasizes the full HTTP request/response body store in object storage for cost and debugging.

Evals and prompt management

Langfuse and Phoenix both treat datasets, experiments, and LLM-as-judge workflows as first-class. Langfuse Cloud plans advertise human annotation queues and prompt release management, which also exist on self-host for MIT-core features, per Langfuse OSS notes. Helicone’s gateway strengths (cache, rate limit, fallback) matter more than offline experiment UX for many buyers.

For a broader eval-platform shortlist outside this self-host trio, see AI agent evaluation tools and Braintrust vs Maxim vs Galileo.

Cost tracking, caching, and rate limits

Helicone documents gateway prompt caching and custom rate limits, plus automatic fallbacks on paid cloud plans. That is the product’s edge when the alert you care about is dollars per minute, ahead of span latency alone.

Langfuse and Phoenix track tokens and cost on generations. They do not replace an edge gateway for multi-provider failover. Teams often run Helicone or another gateway in front and still export traces to Langfuse or Phoenix.

ClickHouse Owns Langfuse: What Changes for Self-Host

ClickHouse acquired Langfuse on January 16, 2026, per the Langfuse announcement and ClickHouse blog. Both posts state that Langfuse stays open source and self-hostable, with no planned licensing changes, and that Langfuse Cloud keeps the same endpoints.

For self-host buyers, the practical effect is roadmap alignment with ClickHouse, which Langfuse already required as its OLAP store. MIT core, Docker images, and the Helm path remain the documented path. Re-check the license-key page before assuming Enterprise modules stay optional forever.

Cloud Pricing as the Alternative to Self-Host

Self-host saves SaaS margin and keeps data in-VPC. Cloud saves on-call time. Use list prices as a sanity check before you staff a ClickHouse cluster for a side project.

Phoenix / Arize AX

Self-hosted Phoenix has no license fee. Managed cloud sits under Arize AX. AX Free lists $0 with 25k spans/month, 1 GB ingestion, 15-day retention, and unlimited users and evals, per arize.com/pricing. Paid AX tiers raise span volume and retention; enterprise can be SaaS or self-hosted AX.

Langfuse cloud plans

Hobby is free with 50k units/month, 2 users, and 30-day access. Core is $29/month with 100k units included and unlimited users. Pro is $199/month. Enterprise starts at $2,499/month.

Extra units are graduated from $8/100k down to $6/100k at high volume, per langfuse.com/pricing. A billable unit is a trace, observation, or score.

Helicone cloud plans

Hobby includes 10k requests/month, 1 GB storage, and 1 seat. Pro is $79/month with unlimited seats. Team is $799/month with 5 organizations, SOC-2 and HIPAA callouts, and a dedicated Slack channel.

Usage-based charges apply above included requests and storage, per helicone.ai/pricing. Public pages do not spell out every overage rate in one table, so treat large-volume Helicone cloud quotes as sales-assisted.

Worked Cost Example: 500,000 Spans a Month

Assumptions (AgentStack estimate): 500,000 spans/observations per month, one production region, 30-day retention, a three-person platform team, and no Enterprise SSO add-ons. We map one Langfuse “unit” roughly to one observation for order-of-magnitude math.

Option	Monthly money out	What you pay for	Hidden cost
Phoenix self-host	~$40 to $80 infra	1 to 2 small VMs + disk; license $0	You own upgrades and backups
Langfuse Cloud Core	~$61 (500k units)	$29 + ~$32 usage (400k overage at $8/100k)	Data leaves your VPC
Helicone Cloud Pro	$79 + usage	Base Pro; request overages if above plan	Gateway becomes a dependency
Langfuse self-host	~$150 to $350 infra	Web/Worker + CH + PG + Redis + object storage	ClickHouse on-call
Helicone self-host	~$60 to $180 infra	All-in-one or Compose on a mid VM	Gateway + auth hardening

Cloud Langfuse Core can beat a naive Langfuse self-host bill at half a million units if your ClickHouse time is expensive. Phoenix self-host stays the cheapest path when one container is enough and ELv2 is acceptable.

Phoenix vs Langfuse for Self-Host

Phoenix vs Langfuse is the most common pairwise fork once Helicone’s gateway model is off the table. Phoenix wins on day-one ops. Langfuse wins on license purity and product breadth at cloud parity.

Start Phoenix with a single docker run and SQLite, then move to Postgres when multiple users need durable shared state. Start Langfuse knowing you will stand up ClickHouse even for modest production traffic, per ClickHouse requirements.

Instrumenters differ too. Phoenix pushes OpenInference semantic conventions through phoenix.otel helpers. Langfuse meets you with first-party SDKs and an OpenTelemetry path that many polyglot shops already use. If your stack is Python-heavy with LangChain or LlamaIndex, both work; Phoenix often feels faster to first trace.

Prompt and eval depth favor Langfuse when several product managers edit prompts in the UI and annotation queues matter. Phoenix covers datasets and experiments well for engineering-led loops. Legal teams that require OSI-approved licenses usually stop at Langfuse MIT core or Helicone Apache-2.0 and skip Phoenix ELv2.

Langfuse vs Helicone for Self-Host

Langfuse vs Helicone is a platform-versus-gateway decision. Langfuse is where you analyze and improve agents. Helicone is where you terminate and meter provider calls.

Self-host Langfuse when traces, prompt versions, and eval scores need one system of record with MIT core. Self-host Helicone when caching, rate limits, and fallbacks must sit on the hot path, per caching and rate-limit docs.

Ops shape differs. Langfuse asks you to run ClickHouse, Postgres, Redis, and object storage as explicit services. Helicone’s all-in-one image collapses that for small installs, then expands again for Helm at enterprise scale. Neither removes the need for backups and auth hardening.

Many mature orgs run both: Helicone (or another gateway) in front for cost control, Langfuse behind for evals and prompt releases. That pattern also appears in our Langfuse vs LangSmith vs Braintrust discussion when teams separate gateway traffic from experiment stores.

Phoenix vs Helicone for Self-Host

Phoenix vs Helicone rarely ends as a pure swap. Phoenix is a collector and UI for OpenInference spans. Helicone is a request proxy with an observability UI.

Pick Phoenix when app code emits OTLP and you refuse a proxy hop. Pick Helicone when every token should pass a controllable edge.

License-wise both are usable for internal commercial products, though Helicone’s Apache-2.0 is simpler for redistribution questions than Phoenix ELv2, per Helicone OSS and Phoenix license pages. Footprint-wise Phoenix stays smaller if you skip gateway duties.

Cost signals differ. Phoenix attaches token cost to spans for analysis. Helicone optimizes the live bill with cache hits and rate policies.

If finance asks why the OpenAI invoice spiked at 02:00, Helicone’s request timeline is usually the faster answer. If an agent loop took 40 tool calls, Phoenix’s span tree is usually clearer.

Day-Two Ops: Alerts, Retention, Backups, and Upgrades

Self-host success is less about the demo and more about the pager. Treat each stack like a small data service, not a disposable sidecar.

• Retention: set explicit trace retention early. Phoenix documents retention policies on self-host. Langfuse OSS keeps data until you add retention policies (Enterprise) or prune yourself. Helicone cloud plans advertise retention windows; self-host retention is yours to enforce on ClickHouse and object storage.
• Backups: snapshot Postgres (and Phoenix SQLite/Postgres volumes) on a schedule. For Langfuse and Helicone, also backup ClickHouse and the blob bucket that holds raw payloads.
• Upgrades: pin image tags in production. Phoenix, Langfuse, and Helicone all publish frequent releases; floating latest is fine for labs and risky for shared prod.
• Auth: turn on SSO or at least disable open signup on any dashboard reachable beyond localhost. Helicone Docker docs call out manual email verification and organization setup on the all-in-one image.
• Alerts: page on ingest lag, disk, and error budgets, ahead of model quality scores alone. A silent collector is worse than a noisy eval.

Air-gapped Phoenix is explicitly supported with no outbound dependency on Arize, per self-hosting docs. Langfuse can run without internet with optional LLM gateway access for playground and judges. Helicone self-host keeps logs local; still plan egress if the gateway must reach providers.

Migration and Dual-Run Patterns

Most teams should dual-run for one or two weeks before cutting over. Emit the same traffic to the candidate self-host and to your current SaaS or logging path, then compare span counts, cost totals, and time-to-first-trace.

• From SaaS Langfuse to self-host Langfuse: same SDKs, new base URL and keys. Export prompts and datasets you still need; do not assume historical cloud traces move for free.
• From Phoenix notebook to Phoenix Docker: change the collector endpoint and keep OpenInference packages pinned.
• From direct provider calls to Helicone: switch base URLs and headers first in staging. Confirm cache keys and rate policies before production.
• From LangSmith or another closed SaaS: use our LangSmith alternatives notes for mapping concepts, then decide whether self-host is mandatory or whether Cloud Core/Pro is enough.

Do not delete the old sink until dashboards, alerts, and on-call runbooks point at the new one. Keep a one-week rollback: DNS or env flag back to the previous collector.

Who Should Pick Phoenix, Langfuse, or Helicone

Match the tool to the job and the ops budget, not to GitHub star count alone.

• Choose Phoenix when you want the smallest self-host footprint, OpenInference/OTLP ingestion, and free unlimited features under ELv2. Ideal for research clusters, air-gapped labs, and teams already close to OpenInference.
• Choose Langfuse when you need MIT core, prompt management, evals, and a stack that mirrors Langfuse Cloud. Ideal when ClickHouse is already familiar and you may buy Enterprise modules later.
• Choose Helicone when the control point is the LLM request path: multi-provider routing, cache hits, rate limits, and cost dashboards. Ideal for platform teams that already run an AI gateway.
• Still comparing SaaS-first stacks? See Langfuse vs LangSmith vs Braintrust and LangSmith alternatives.
• Building agents? Pair any of these with guidance from our AI agent frameworks pillar.

Self-Host Decision Checklist

Print this list and score each tool with your SRE and app owners in the room. The first tool that clears every hard gate usually wins.

• License gate: Must the license be OSI-approved? If yes, drop Phoenix ELv2 unless counsel signs off for internal-only use.
• Topology gate: Must LLM traffic terminate at a proxy? If yes, shortlist Helicone (or another gateway) before collectors.
• Footprint gate: Can you operate ClickHouse this quarter? If no, prefer Phoenix or Helicone all-in-one over full Langfuse prod topology.
• Product gate: Do PMs need prompt versioning and annotation queues in-product? If yes, bias to Langfuse.
• Signal gate: Do you need OpenInference span kinds for agents and tools? If yes, bias to Phoenix.
• Cost gate: Is the painful number the SaaS invoice or the on-call load? Cloud Core/Pro can beat a thin self-host team on total cost.
• Escape hatch: Keep one week of dual-run and a written rollback. File issues with vendors via GitHub when docs drift; link them from our contact page if AgentStack should update this comparison.

For the broader open-source field beyond these three, return to the open source LLM observability listicle. For category context inside AgentOps, stay on the Agent Observability hub.

Related AgentStack Guides

Helicone can also sit in the request path. For a pure gateway shortlist of Portkey, LiteLLM, and OpenRouter, see Portkey vs LiteLLM vs OpenRouter.

Helicone also runs as an AI gateway. If routing, budgets, and failover matter more to you than tracing, compare it with eight other options in our LLM gateways guide.

This comparison sits in the Agent Observability topic under AgentOps. Start from the AgentOps tools map, then drill into best AI agent observability tools or the open source LLM observability shortlist. Questions or corrections: contact us.

FAQ: Arize Phoenix vs Langfuse vs Helicone