Langfuse vs Helicone: which to choose

Langfuse or Helicone: when each one fits the decision

A platform team that must self-host LLM observability usually narrows the choice to two questions: how the application will send telemetry, and how much the team trusts a tool that is now in maintenance mode. Langfuse fits teams that want SDK and OpenTelemetry instrumentation, with traces, prompt management and evaluations in one tool. Its core is MIT licensed, and the Langfuse documentation states that all core features and APIs are available in the open source version without limits. Enterprise features such as project-level RBAC, data retention policies, audit logs and SCIM need a license key, so check which of those controls your compliance team requires before you commit.

Helicone fits teams that want the fastest path to request logging, where changing the client's base URL to the Helicone gateway is the main integration step. Its repository is Apache-2.0 licensed, and the README also offers asynchronous logging through OpenLLMetry for teams that cannot route traffic through a proxy. The gateway adds routing and automatic fallbacks across 100+ models, which matters if you also want a single access point for model calls. Self-hosting still means running a Next.js frontend, a Cloudflare Workers logging proxy, the Jawn collection server, Supabase, ClickHouse and MinIO, so the operating footprint is not small.

The decision turns on three things. First, instrumentation method: if your developers can add an SDK or OpenTelemetry exporter, Langfuse keeps the telemetry path inside your code, while a proxy-first design puts every model call through another hop. Second, data path control: a gateway that sits in front of your model traffic is a new component in your data flow, so confirm where it runs, what it stores and who can reach it. Third, maintenance mode: Mintlify announced its acquisition of Helicone on March 3, 2026, and both companies say Helicone will receive security updates, bug fixes and new models. Its latest tagged GitHub release is v2025.08.21-1, so ask Helicone for its current release and support commitments in writing before you plan a multi-year rollout.

Which platform fits which team scenario

This table maps common team situations to the platform that fits better and the condition that decides it. Read each row as a starting point, then check the condition against your own architecture, timeline and compliance position before you choose.

Scenario	Better fit	Condition that makes it so
An existing OpenAI-compatible app needs request logging within a day	Helicone	The app can change its base URL to the Helicone gateway, and the team accepts that requests pass through a gateway it must host or trust. Confirm the proxy path against your data handling rules before routing production traffic.
A multi-service agent stack needs traces, nested spans and sessions	Langfuse	Services already emit traces through the Langfuse SDKs or OpenTelemetry. Helicone supports traces and sessions for agents, but the instrumentation path is a gateway change rather than span-level instrumentation across services.
Prompts, datasets and evaluations must live in one place	Langfuse	The team wants prompt management, evaluation and tracing in one open-source stack that it runs itself. Confirm which prompt and evaluation features your chosen edition includes, since some features need a license key.
A team already runs a Helicone deployment and wants to stay on it	Helicone, with a plan	The current deployment is stable and the team accepts maintenance-mode status. Plan a migration path now, because Mintlify has offered to help customers move to another platform.
A regulated team cannot accept a platform in maintenance mode	Langfuse	Your assessor or risk owner treats maintenance-mode software as a supplier risk. Langfuse is actively released (v4.63.0 published October 16, 2026, per its GitHub releases page), so confirm your own support and patch requirements with the vendor.
Team wants a gateway with routing and fallbacks across 100+ models	Helicone, or a dedicated gateway	Routing and fallbacks are the primary need. Helicone's gateway covers this, but Langfuse does not replace a gateway, so pair it with a gateway such as LiteLLM if routing is the main requirement.
Operators must run the stack with the least added complexity	Helicone, with caution	The team already operates Supabase, ClickHouse and MinIO, and accepts the Cloudflare Workers proxy in its design. Compare the component count with Langfuse, which runs web and worker containers backed by PostgreSQL, ClickHouse, Redis or Valkey and blob storage.

How each platform is built and what that means for operations

Both platforms keep their analytics in ClickHouse, so the database you size and back up is shared ground. The difference is in the rest of the stack: Langfuse runs two application containers beside its data stores, while a self-hosted Helicone deployment adds several more moving parts to every upgrade and incident.

Langfuse web and worker

Langfuse runs two application containers: Langfuse Web serves the UI and APIs, and Langfuse Worker processes events asynchronously. Ingestion load shows up mainly in the worker, so that is the container you scale first on CPU load. Under heavy ingestion, Langfuse suggests splitting web into separate ingestion and user interface deployments. Check how your team will size and monitor both containers before you commit to a single VM.

Langfuse data stores

A self-hosted Langfuse deployment depends on PostgreSQL for transactional data, ClickHouse for traces and analytics, Redis or Valkey for queues and caching, and S3-compatible blob storage. Langfuse documents Docker Compose on one VM for testing without high availability, and Kubernetes with Helm or Terraform for production. Confirm who operates each store, how each is backed up, and whether your team can run ClickHouse at the memory level the scaling guide describes.

Helicone's proxy and log path

Helicone's gateway is a Cloudflare Workers proxy, so every logged request passes through a component that is separate from the Next.js frontend and the Jawn log collection server. Teams that log asynchronously with OpenLLMetry avoid the proxy in the request path, but the rest of the logging stack remains. Ask who owns the Workers deployment in your environment, because it runs outside the cluster that holds your data services.

Helicone's application stack

A self-hosted Helicone deployment runs a Next.js web frontend, the Jawn log collection server and Supabase for the application database and auth. Supabase brings its own services and upgrade cadence, so authentication, database and application problems can look alike during an incident. Expect a longer upgrade path than Langfuse, and plan to test each layer separately after every change.

Shared ClickHouse analytics

Both platforms store analytics in ClickHouse, so a team that already runs ClickHouse for another workload gets a familiar operational target. The sizing, backup and version rules still differ between the two products. Langfuse's v3 to v4 guide requires ClickHouse 25.12 or later and advises about 3x disk headroom when backfilling historic data. Ask Helicone for its ClickHouse version and sizing expectations before you assume the two deployments are interchangeable.

Object storage and upgrade risk

Helicone uses MinIO for log object storage, while Langfuse uses S3-compatible blob storage that many teams already run. Each object store adds backup, retention and access-control work to the platform team. Helicone's latest tagged GitHub release is from August 21, 2025, so check which dependency versions your deployment will pin and who patches them while the project is in maintenance mode.

Capability comparison: tracing, prompts, evaluations and deployment

This table compares how Langfuse and Helicone capture traces, manage prompts and evaluations, and deploy on your own infrastructure. Read each row as a question to put to both vendors, and treat any cell marked to confirm as an open item for your own proof of concept.

Capability	Langfuse	Helicone
Tracing method	Instrumented through its SDKs and OpenTelemetry-based tracing, so spans are created inside your application code.	Logs requests by changing the client's base URL to the Helicone gateway, or through asynchronous logging with OpenLLMetry.
OpenTelemetry support	Documents OpenTelemetry-based ingestion. Confirm which span attributes and framework instrumentations your stack needs.	Supports OpenLLMetry for asynchronous logging. Confirm how it maps to your existing OpenTelemetry pipeline.
Prompt management and versioning	Includes prompt management in the MIT edition. Protected prompt labels are an Enterprise license feature.	Offers a prompt playground and prompt versioning deployed through the gateway. Confirm how this works if traffic bypasses the gateway.
Evaluations	Core evaluation features are part of the MIT-licensed codebase. Confirm the evaluation workflows you need against the current docs.	Listed features center on traces, sessions, cost and latency. Confirm whether evaluation tooling meets your requirements.
Cost and latency tracking	Available as part of observability. Confirm token and cost coverage for your model providers.	Listed as a core feature, with cost and latency tracking for requests routed through the gateway.
Self-hosted deployment options	Docker Compose on a single VM for testing (no high availability), and Kubernetes with Helm or Terraform on AWS, Azure and GCP for production.	Docker Compose setup for self-hosting. A production Helm chart for enterprise workloads is available by contacting Helicone.
Helm or Kubernetes path	Published Helm and Terraform-based paths on AWS, Azure and GCP. Confirm which fits your cluster standards.	Helm chart is offered on request for enterprise workloads. Confirm chart scope, support terms and version cadence before you plan.
Identity features	SSO and authentication are documented in the self-hosting guide. Project-level RBAC, audit logs and SCIM are Enterprise license features.	Identity and auth come from the Supabase application database. Confirm SSO, role and audit options for your deployment.
Maintenance status	Actively released, with v4.63.0 published on October 16, 2026 per its GitHub releases page.	Maintenance mode after Mintlify's acquisition announced March 3, 2026. Confirm the support scope you will receive.

Why SDK tracing and base URL logging change your code differently

Base URL logging is the faster route to first data. You point the client's base URL at the Helicone gateway and requests are logged without restructuring the calling code. The trade-off is architectural: every model request now passes through a proxy in your request path, and that proxy becomes a dependency for availability, latency and data handling. In a self-hosted Helicone deployment, the README places a Cloudflare Workers proxy in the logging path, so confirm where that component runs, what it can see and whether it can stay inside your network boundary. Teams whose provider agreements or internal policies restrict routing prompts through third-party infrastructure should settle this before any code change.

Langfuse instrumentation, through its SDK or OpenTelemetry, adds span code at each call site, so it takes more engineering work up front. In return, model traffic goes directly from your application to the provider, and trace data goes to your own Langfuse web and worker containers. This matters most for multi-step agents. Retrieval, tool calls and sub-agent steps need parent and child spans so a reviewer can see which step produced a bad answer and what it cost. Helicone also offers traces and sessions for agents, and its README describes asynchronous logging through OpenLLMetry as an alternative to the gateway. Confirm whether that path captures the nesting your agents need. For a single-provider chat workload with simple calls, the gateway path may be enough.

Before choosing, run a short inventory. Count the call sites, list every provider and note which requests carry regulated or confidential data. If any of those requests cannot pass through a proxy you operate, the gateway route is off the table for those paths, and the SDK or OpenTelemetry becomes the default. Also weigh vendor direction. Mintlify announced its acquisition of Helicone on March 3, 2026, and both companies describe Helicone as continuing in maintenance mode, with security updates, bug fixes and new models still shipping. Mintlify's announcement says it will help customers move to another platform. Ask for those migration terms in writing before you commit to either path.

What the licenses and paid editions cover for each platform

Langfuse is open core. Its repository is MIT Expat licensed except for content in the ee/, web/src/ee/ and worker/src/ee/ directories, which falls under a separate enterprise license. Langfuse states that all core features and APIs are available in the MIT-licensed open source version without limits, and self-hosted deployments run the same codebase as Langfuse Cloud.

MIT core outside the ee directories: Code outside those three directories is MIT licensed, so teams can run tracing, evaluations and prompt management in their own infrastructure without a license key for that code.
Core features without limits: Langfuse says the open source edition includes all core features and APIs without limits, which covers the day-to-day tracing and evaluation work most teams start with.
Enterprise-key features: 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 need an Enterprise license key, as does the instance management API.
Support tier: The Self-Hosted Enterprise plan is custom-priced and adds a named support engineer, solutions architect access and a support SLA.

Before you assume the open source edition meets your controls, list which key-gated features your policies require, such as retention, audit logging or SCIM provisioning, and confirm them against the license key documentation.

What Helicone's maintenance mode means for teams choosing or leaving it

Helicone is no longer in active feature development, and that changes the risk calculation more than any feature comparison does. Mintlify announced on March 3, 2026 that it is acquiring Helicone. Both companies say Helicone will continue in maintenance mode, with security updates, bug fixes and new model support still shipping, and Mintlify has offered to help customers move to another platform. Read that as a commitment to keep the current product safe and working, not as a roadmap. Ask Helicone or Mintlify in writing which security fix commitments and response expectations apply to your deployment, and whether the self-hosted Docker Compose setup and the Helm chart offered on request are covered by the same maintenance terms.

Check release activity yourself before you commit. The latest tagged release supplied for the Helicone GitHub repository is v2025.08.21-1, published on August 21, 2025, which is well before the acquisition announcement. Tagged releases are not the whole picture, since the company says it still ships fixes and models, so review the commit history and open security advisories on the Helicone releases page and the repository, and confirm with your own platform team how a fix would reach your instance. If your deployment pulls from a branch rather than a tag, plan for that choice explicitly.

Teams that can accept this include those with a stable, narrow use case: logging requests through the gateway, tracking cost and latency, and running a bounded prompt playground, with a security team willing to patch a self-hosted stack on its own schedule. Teams that cannot accept it are those that need evaluations, dataset workflows and a roadmap they can plan around, or that run Helicone in a regulated environment where an unpatched component creates an audit finding. For those teams, the migration decision is a question of how much of their traffic and prompt history depends on the gateway base URL, and that is where a Langfuse self-hosting overview is the natural next read to scope the move.

What drives the running cost and implementation effort of each

Both platforms store analytics in ClickHouse, so that database appears in both budgets, but the rest of the footprint differs. A self-hosted Langfuse deployment runs a web and a worker container on top of PostgreSQL, ClickHouse, Redis or Valkey, and S3-compatible blob storage. Helicone runs six components, and the proxy layer is the part to confirm before you size anything.

Langfuse application tier: The scaling guide lists minimum resources of 2 CPU and 4 GiB for web, worker and PostgreSQL, and 1 CPU and 1.5 GiB for Redis or Valkey.
ClickHouse sizing: The same guide lists 2 CPU and 8 GiB as the minimum for ClickHouse, with at least 16 GiB of memory for larger deployments.
Helicone six-component stack: A Next.js web frontend, a Cloudflare Workers proxy for logging, the Jawn log collection server, Supabase for the application database and auth, ClickHouse for analytics and MinIO for log object storage.
Proxy placement: Confirm with Helicone which parts of the logging path you run inside your network and which depend on Cloudflare, because that changes your data residency review.
Deployment shape: Langfuse documents Docker Compose on a single VM for testing without high availability, and Kubernetes with Helm or Terraform for production.

Ask each vendor for a resource table tied to your expected event volume and retention period, and ask Helicone whether its enterprise Helm chart covers the same six components.

How to move from Helicone to Langfuse, or the reverse, in order

This sequence lets a team change its LLM telemetry path without losing track of production traffic, so the new platform is proven on real requests before the old one is switched off.

Inventory every base URL and gateway dependency
List each service, script, notebook and agent that sends requests through the Helicone gateway or logs through its asynchronous path, including the base URL, API key location and any Helicone-specific headers. Engineering leads own this list, with input from the teams that run each service. It is done when every client that touches Helicone appears on one list with its owner, and when the team has checked each one for prompt playground use, prompt versioning deployed through the gateway, and any routing or fallback rules that depend on Helicone. Those features do not carry over automatically, so note them as rebuild items.
Choose SDK or OpenTelemetry instrumentation for each service
Decide, service by service, whether to instrument with the Langfuse SDK or send OpenTelemetry traces to Langfuse, using the Langfuse OpenTelemetry guide to confirm the supported path for each language and framework. Services that already emit OpenTelemetry spans are usually simpler to point at Langfuse, while services that call the model provider directly through the Helicone base URL will need code changes to their client setup. The output is a short written decision per service, signed off by the platform owner, so that no service moves on an unstated assumption.
Stand up the Langfuse stack beside Helicone
Deploy self-hosted Langfuse in your own environment, running the web and worker containers with PostgreSQL, ClickHouse, Redis or Valkey and S3-compatible blob storage, and check sizing against the Langfuse scaling guide before loading traffic. Helicone keeps running during this step. Platform engineers own the deployment, and the check is a working Langfuse instance that accepts a test trace from each instrumentation method chosen in the previous step. Confirm the ClickHouse version against the current upgrade guide before you pick a starting release.
Run both paths in parallel on a non-production route
Send a non-production route, such as a staging service or one internal tool, through both paths at once: the existing Helicone base URL for the live call and Langfuse instrumentation on the same call. Compare request counts, token and cost fields, latency and error traces between the two systems for a agreed test window. Application owners and the platform team review the mismatches. The step is complete when the differences are explained, such as provider-side model naming or fields Helicone computed that Langfuse derives differently, and the team accepts the Langfuse view for those services.
Move production services and accept or backfill history
Cut production services over one at a time, changing each client's base URL or instrumentation and keeping a rollback path to the previous configuration. Decide whether to backfill historic Helicone data into Langfuse or to accept a history gap. Backfilling requires an export from Helicone, and the Langfuse v3 to v4 guide notes that backfilling historic data needs about 3x ClickHouse disk headroom, so size storage before you start. The output is a record of each cutover and a written decision on history, which the audit or compliance owner should review if logs are used as evidence.
Rebuild dashboards, evaluations and alerts
Recreate the cost, latency and error dashboards, the evaluation runs, and the alerts that the team relied on in Helicone, using Langfuse's own dashboards, scores and prompt management. Prompts and request records can move only to the extent you can export them, so check what the Helicone export provides before assuming any prompt history is available. The check is that each alert fires in a test and that each evaluation produces scores on a sample of recent traces, with the owning team signing off.
Retire the Helicone path and keep an exit record
After every service has run on Langfuse for the agreed period and the rebuilt alerts are confirmed, remove the Helicone base URLs and keys from configuration, shut down the Helicone deployment, and store the export, the cutover log and the decision record with your change records. Mintlify has said it will help customers move to another platform, so ask Mintlify directly what assistance is available and what it covers. Helicone's latest tagged release is v2025.08.21-1, so confirm whether you need to patch the existing deployment before the shutdown date you set.

Questions buyers ask before choosing or moving

Does a self-hosted Langfuse deployment need a license key?

No. Core features and APIs are available in the MIT-licensed open source edition without limits, so a self-hosted deployment does not need a key for them. A key is required for specific features: project-level RBAC roles, protected prompt labels, data retention policies, audit logs, server-side data masking, UI customization, organization creators, the org management API with SCIM and the instance management API. Map these against your access control, retention and audit requirements before you design the deployment. Ask the vendor which of them your use case depends on and what happens to a running instance if the key is removed. The license key documentation lists the current features.

How long does moving from Helicone to Langfuse take?

No duration is fixed by the platforms, so any timeline should be written into an agreed scope. The main drivers are the number of services sending traffic, whether each one only changes its base URL or needs SDK or OpenTelemetry instrumentation, how much historic log data you need to carry over, and how many prompts and evaluations must be recreated. Helicone's proxy model can start logging after a base URL change, while Langfuse tracing that captures agent steps may need instrumentation in application code. Ask for a plan that lists each service, its instrumentation method, the data you will keep, and the cutover and rollback steps. DeployOpen's fixed-scope engagements agree scope, deliverables and timelines in writing before work starts.

Will Helicone's maintenance mode slow down security patches?

Helicone and Mintlify say the project continues in maintenance mode, with security updates, bug fixes and new models still shipping. Confirm which branch or release channel carries those fixes, because Helicone's latest tagged GitHub release is v2025.08.21-1, published on August 21, 2025. If you run from the main branch, decide how you will pull, test and deploy updates. Ask whether security advisories are published in advance, what response window applies to critical issues, and whether the enterprise Helm chart you obtain by contacting Helicone receives the same fixes as the Docker Compose setup. Your team or a retainer still has to patch Supabase, ClickHouse, MinIO and the Cloudflare Workers proxy in your environment. Mintlify has offered to help customers move platforms, so ask for those terms in writing. See Mintlify's announcement.

What does the team need to run self-hosted Langfuse?

Plan for six components: Langfuse Web, Langfuse Worker, PostgreSQL, ClickHouse, Redis or Valkey, and S3-compatible blob storage. Langfuse documents Docker Compose on a single VM for testing, without high availability, and Kubernetes with Helm or Terraform on AWS, Azure and GCP for production. The 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. Your team needs container operations, PostgreSQL and ClickHouse administration, backup and restore, and object storage skills. Confirm these figures against the scaling guide before you size hardware, and test restores before go-live.

Can our team handle the migration without outside help?

Yes, if your engineers already run the database and container stack and have the capacity to own it. Frame the decision around skills and time: who operates ClickHouse and PostgreSQL, who instruments each service, who owns upgrades, and who writes the runbook. Langfuse says updates within a major version apply database migrations automatically at startup, but major upgrades follow dedicated guides. The v3 to v4 guide requires ClickHouse 25.12 or later (26.4 recommended), PostgreSQL 15 or later and Redis 7.0 or later. DeployOpen plans, implements, integrates, hardens, backs up, upgrades and documents self-hosted platforms inside your own infrastructure, and offers ongoing support and upgrades as retainers. Build an internal plan for the same scope, then compare it with a written quote.

What drives the cost of this move and running both platforms?

Cost has four components, and each is paid to a different party:

Infrastructure you run: VMs or Kubernetes nodes, ClickHouse memory and disk, PostgreSQL, Redis or Valkey, backups and object storage. These recur every month.
Software licensing: Langfuse's open source edition has no license fee, and its Self-Hosted Enterprise plan is custom-priced. Helicone's repository is Apache-2.0, and its enterprise Helm chart is obtained by contacting Helicone.
Staff time: instrumentation, migration, testing, upgrades and on-call coverage.
Outside services: a fixed-scope implementation quote, plus an optional retainer for ongoing support.

Ask each quote for line items by component, marked one-time or recurring, with the traffic volume it assumes. Langfuse's v3 to v4 guide advises about 3x ClickHouse disk headroom when backfilling historic data, which can change infrastructure cost sharply.

Does Langfuse replace Helicone's gateway features too?

Not necessarily. Helicone's README describes a gateway that gives access to 100+ models through the OpenAI API, with routing and automatic fallbacks, and it deploys prompt versioning through that gateway. The Langfuse material covered here describes tracing, evaluations and prompt management, and does not describe a request gateway, so confirm that capability with the vendor before you assume it. If your applications depend on Helicone for routing or fallbacks, plan a separate gateway component and test its failover behavior. List every Helicone feature your teams use, including the base URL pattern, cost tracking, sessions and prompt playground, and map each one to where it will live after the move.

How DeployOpen helps you choose, implement or migrate

DeployOpen plans and implements self-hosted Langfuse inside your own cloud accounts, data centers or air-gapped networks, and can help you assess Helicone or move off it. Work starts with a written scope so the choice between SDK tracing and a gateway is settled before any infrastructure is built.

How we scope

Confirm which application paths need tracing and whether they call models through SDKs, OpenTelemetry or a gateway.
Document the self-hosted footprint: web, worker, PostgreSQL, ClickHouse, Redis or Valkey and blob storage.
Agree in writing whether Enterprise license features such as RBAC, retention or SCIM are in or out of scope.

How we build

Deploy Langfuse with Docker Compose for testing or Kubernetes for production, in your own environment.
Instrument applications with the Langfuse SDK or OpenTelemetry, and test prompt management and evaluations against real workflows.
Where migrating from Helicone, map its base URL logging and prompt versions to Langfuse traces and prompts, then test both in parallel.

How we hand over

Deliver architecture notes, configuration records, backup and upgrade procedures for each stateful component.
Document the decisions on licensing, data residency and which features rely on the MIT edition versus a license key.
Walk your operations and security teams through runbooks for scaling, major version upgrades and retiring the old logging path.

How we support

Offer ongoing support, upgrades and continuous testing as a retainer after handover.
Plan major upgrades, such as the Langfuse v3 to v4 migration, with a dedicated test environment and checked backups.
Review the setup again when Helicone's maintenance status or your data requirements change.

Langfuse vs Helicone