Langfuse: product and architecture
This Langfuse review looks at an LLM engineering platform whose main commercial argument is one you can act on: you can run the whole thing yourself, from one container, for nothing. Langfuse connects tracing, prompt management, datasets, experiments, and evaluation into one loop, and sells a hosted version of the same software. We evaluated it against its documentation, its published pricing, its GitHub repository, and the adoption signals we collect weekly.
Overview
Langfuse is published by ClickHouse, Inc. and was a YC W23 company before that acquisition. Our 14 September 2026 snapshot recorded about 34,800 GitHub stars, roughly 17.6 million pulls of the langfuse/langfuse container image, and 771 votes on its Product Hunt launch. The SDKs are separately busy — about 5.3 million weekly PyPI downloads and 1.7 million weekly npm downloads — though those are client installs rather than platform adoption, and we record them in that lane. The v4.38.0 release landed on 17 September 2026.
The vendor states 21 of the Fortune 50 as users, 90 billion observations a month, and 100,000 engineers. Those are unverified vendor figures; the container pull count is the number we can stand behind, and it is consistent with widespread self-hosting rather than cloud-only use.
Its market position is the open-source default for LLM observability. The audience is engineering teams who want the whole loop in one product and want the option to keep their trace data inside their own network.
Key Features and Architecture
Langfuse is a server plus SDKs, and the server is the product. Tracing captures hierarchical traces — every model call, tool invocation, and retrieval step in a tree rather than a flat log — filterable by user, session, cost, latency, or custom metadata. The hierarchy is what makes an agent debuggable: a flat log tells you the answer was wrong, a trace tree tells you which retrieval returned nothing.
Prompt management separates prompts from code, with one-click deployment and rollback. This is the feature that moves prompt changes out of the release cycle, and the rollback is the part that matters when a change goes wrong at 2am.
Evaluation offers LLM-as-a-judge, heuristic functions, and human review, and can run evaluators against production data as well as inside an experiment. That is the distinction worth noticing: scoring live traffic is a different capability from scoring a fixed test set, and it is what turns production into a source of test cases.
Datasets and experiments close the loop. A trace that went wrong becomes a dataset row, the dataset becomes an experiment, and the experiment scores a candidate prompt or model before it ships.
Instrumentation is OpenTelemetry-based, so an application already emitting OTel spans can send them here, and a framework such as PydanticAI or LiteLLM can log to Langfuse without a bespoke integration.
Deployment is the differentiator. The server runs from a container image, and the same software serves Langfuse Cloud. That symmetry is unusual — many open-core products self-host a reduced build — and it is why the self-hosted path is credible rather than a trial.
Ideal Use Cases
Four situations favour Langfuse. The first is data residency. If prompts and completions contain material that cannot leave your network, a platform you run from one image with no reduced feature set is close to unique in this category, and it is the strongest single reason to choose it.
The second is teams that want the whole loop in one tool. Tracing in one product, prompts in a second, and evals in a third is a common and painful arrangement, because the trace that reveals the problem is not in the system that tests the fix.
The third is cost and latency analysis at the trace level. Filtering by cost and latency with custom metadata is how you find the one feature responsible for a bill, and that question arrives for everyone eventually.
The fourth is a framework-agnostic estate. OTel-based instrumentation and integrations across the common frameworks mean Langfuse does not require you to standardise on one agent library first.
Do not choose Langfuse if you want evaluation to be the centre of the workflow rather than one stage of it — Braintrust is built the other way round, starting from evals and adding observability. It is also the wrong answer if nobody will operate the self-hosted deployment and Cloud is ruled out, because a self-hosted platform is a database and a service to keep healthy. And if you only need request logging and cost tracking in front of a proxy, Helicone is less to adopt.
Pricing and Licensing
Self-hosting is free. The Hobby cloud tier is also free, with 50,000 units a month and 2 users. Paid cloud tiers are Core at $29/month, Pro at $199/month, and Enterprise at $2,499/month, each including 100,000 units a month with unlimited users. Usage above the included allowance is $8 per 100,000 units, falling to $7 above 1 million, $6.50 above 10 million, and $6 above 50 million. A Teams add-on is $300/month.
The graduated overage is the part to model, because units rather than traces is the billing measure and a single agent run can produce many. Estimate your unit volume from a week of real traffic before choosing a tier; the jump from $29 to $199 is about features and support, but the line that actually moves is the overage.
The licensing needs stating precisely. The repository's LICENSE is a split: the core is MIT and an ee/ directory is separately licensed for commercial features. GitHub cannot resolve that to a single SPDX identifier and reports it as unresolved, which means an automated open-source check — including ours — cannot confirm the product is OSI-licensed without a human reading the file. If your procurement runs such a check, expect to have that conversation.
Against the alternatives: Braintrust is hosted-first with a hybrid data plane rather than a full self-hosted build; Helicone is Apache-2.0 and Freemium; Arize Phoenix is free but source-available rather than open source. Langfuse is the only one of the four whose full server is free to run yourself under a licence whose core is MIT.
Strengths & Trade-offs
Pros
- The self-hosted server is the same software as the cloud product, run from one container image, at no cost.
- Tracing, prompt management, datasets, experiments, and evaluation in one loop, so the trace that shows the problem is in the tool that tests the fix.
- Evaluators run against production data as well as test sets, which turns live traffic into a source of test cases.
- OpenTelemetry-based instrumentation, so existing spans and common frameworks work without a bespoke integration.
- Published, graduated overage pricing, so the cost of growth is knowable in advance.
Cons
- The repository LICENSE is a split rather than a single identifier, so automated open-source checks report it as unresolved and a human has to read the file.
- Billing is in units rather than traces, and one agent run can produce many — the cost is hard to predict before you measure.
- Self-hosting is free but not effortless: it is a service and a database to keep healthy, and at scale that is a real operational commitment.
- Evaluation is one stage of the loop rather than its centre, which suits observability-first teams and frustrates evaluation-first ones.
- The vendor's adoption figures are unverified, so judge it on the trace data you generate rather than on the headline numbers.