Langfuse
The Open-Source Observability Stack Building on an EU Compliance Story
The observability platform that trades agent-level trace depth for deployment simplicity and a GDPR compliance posture the alternatives cannot match.
The Arize Phoenix article I published two days ago made the case for deep agent tracing. I stand by every word of it. Phoenix is the right tool when your agents are complex enough that the trace tree is the only way to understand what happened. But not every team runs multi-step agents with tool calls and sub-agent invocations. Some teams run straightforward LLM calls wrapped in business logic, and what they need from an observability platform is not the deepest trace tree in open source but the fastest deployment path, a prompt management layer that works out of the box, and a compliance story that does not require a legal review before the first datasheet is signed.
Langfuse fills that slot.
The current version as of this writing is v3.212.0 for the self-hosted backend (released July 10, 2026) and v4.14.0 for the Python SDK. The star count sits at roughly 30.9k on GitHub, up significantly from the 8.5k I saw referenced in planning notes a few weeks ago. That velocity is real. Langfuse shipped three releases on July 10 alone, and the cadence has been consistent through 2026 dashboard widgets with copy-paste support, boolean score filtering, RBAC improvements, and a live-reasoning in-app agent assistant that was the highlight of the v3.210 release. The project is YC W23 and based in Berlin, which matters for the European compliance story I will get to in a moment.
The architecture difference from Phoenix is straightforward. Langfuse is built around a Postgres-backed web application with a straightforward Docker Compose deployment. You pull the compose file, set a few environment variables for your Postgres connection, and you have a working observability platform in under ten minutes. The dashboard gives you the standard trace view with spans for each LLM call and tool invocation. It is not the tree-depth trace that Phoenix provides. For a sequential chain of LLM calls with retrieval steps, it shows you the full picture. For a branching agent trajectory with retries and conditional sub-chains, the visualization is flatter and you have to reconstruct the order manually. That is the tradeoff.
Where Langfuse pulls ahead is the prompt management layer. Phoenix added prompt management in the v17.x series and it is functional, but it feels like a recent addition to an existing observability platform. Langfuse was designed from the beginning as a platform that covers the full lifecycle prompt development, versioning, deployment across environments, experiment comparison, and production monitoring. The dedicated prompt management workflow is deeper than anything Phoenix offers, and it integrates with the evaluation framework so that a prompt change produces a scored comparison against the previous version. For teams that iterate on prompts frequently and need to track which version is in production across multiple model providers, this alone is worth the evaluation time.
The evaluation layer is comparable to Phoenix in most dimensions. Langfuse supports LLM-as-judge evaluators that run asynchronously against completed traces, with relevance, toxicity, correctness, and hallucination detectors. The dataset management for running experiments is well designed you can define a dataset of prompts with expected outputs, run a prompt variant against it, and compare the results. The difference is that Langfuse does not have embedding-based drift detection. Phoenix can measure the distribution shift in trace embeddings between deployments and alert on semantic drift. Langfuse relies on evaluator score distributions for the same purpose. Both approaches work. Embedding-based drift catches subtle stylistic shifts that score-based detection can miss. Score-based detection is easier to interpret and debug.
The self-hosting story is one of the strongest arguments for Langfuse. The Docker Compose deployment is the simplest in the category. A single file, a Postgres instance, and a working dashboard. The Kubernetes Helm chart exists for production-scale deployments, but the truth is that most teams do not need it at the outset. Langfuse’s SaaS offering at cloud.langfuse.com is EU-hosted by default, with data residency in Frankfurt or Ireland depending on the plan. For teams covered by GDPR, that matters. Sending trace data to a US-based observability platform, even a self-hosted one, raises questions about sub-processors, data transfer mechanisms, and the legal basis for processing that most engineering teams do not have the legal staff to answer fully. Langfuse being EU-based with EU data residency as the default removes that conversation from the procurement process. It will not matter to every team. For European enterprises and any organization with GDPR-sensitive data, it is a meaningful advantage.
The license is MIT with an EE directory for enterprise features, which is the standard open-core model. The self-hosted community edition includes tracing, evaluation, prompt management, and the core dashboard. The enterprise edition adds SSO, audit logs, advanced RBAC, and dedicated support. The pricing for the cloud version is based on observations per month with a free tier that covers 50,000 observations. For a team that is still evaluating the category and wants to avoid a per-token pricing model that gets expensive fast, the free tier and the self-hosted option give meaningful flexibility.
The honest limitation beyond the shallower trace tree is that Langfuse does not have the integration surface that Phoenix provides through OpenTelemetry-native instrumentation. Phoenix speaks OTLP natively and ingests from any OpenInference-compatible source. Langfuse integrates with LangChain, LlamaIndex, OpenAI, LiteLLM, and the OpenAI SDK through dedicated instrumentation packages, but it does not ingest arbitrary OTLP spans. If your stack includes a framework without a dedicated Langfuse instrumentation package, you either build the adapter or pipe the data through a different path. For the frameworks that have native support, the integration is one import and one line of initialization code. The gap appears when you are running something outside the mainstream.
The other gap is the agent tracing issue I mentioned. Langfuse traces LLM calls and tool invocations, but it does not construct the tree view that shows an agent’s execution structure as a decision tree. A five-step agent with retries and conditional branches produces a flat list of spans that you must mentally reconstruct into the agent’s trajectory. For simple agents, this is not a problem. For complex ones, it is the difference between seeing what happened and understanding why it happened. If your agent architecture is complex enough to need the tree, Phoenix is the choice. If your agents are simple enough that a flat timeline tells you what you need to know, Langfuse delivers a better experience across every other dimension.
For teams operating under GDPR, Langfuse is not just a good option. It is the option that avoids a compliance conversation nobody wants to have. For teams that iterate on prompts frequently and want a platform where prompt management is a first-class feature, the same conclusion holds. For teams running complex multi-step agents who need the trace tree to debug production issues, the recommendation is Phoenix on the trace side and Langfuse on the prompt management and compliance side.
The split is not ideal. Nobody wants two observability platforms. But the tools in this category are still evolving, and the specialization between Phoenix’s trace depth and Langfuse’s deployment simplicity and compliance posture reflects a maturing market, not a failure of either project. Pick based on what your agents actually do today, and revisit the decision in six months when both platforms will have closed some of the gap.
If this was useful, forward it to one engineer who needs less noise in their feed.