How to Self-Host Langfuse in 2026 - The Honest Setup Guide

Self-hosting Langfuse is the most common answer to “how do I get LLM observability without a per-trace bill.” And it is a good answer - the self-hosted build is free under MIT and genuinely feature-complete. But there is a gap between “free to self-host” and “easy to self-host,” and that gap is exactly where teams get burned.

This guide is the honest version. What you actually get, what infrastructure you need, where it breaks, and when you should just pay for cloud instead.

What you actually get for free

Start here, because it is the reason to bother. Most “open-source” observability tools hand you a hobbled core and gate the useful features behind a paid cloud. Langfuse does not.

In the self-hosted build, only three features are enterprise-gated - Organization Creators, the Instance Management API, and UI customization. Everything you actually need is free under MIT: tracing, evals, prompt management, human annotation queues, and RBAC. That is far more generous than LangSmith or Braintrust, where self-hosting is an Enterprise-only, contact-sales affair.

So the value is real. You run the actual product, on your own infrastructure, with your data never leaving your cloud. The catch is not the license. It is the operations.

Step 1: Understand the v3 architecture before you start

The single most important thing to know: Langfuse v3 is four services, not one. The old setup was “just Postgres.” That is gone.

The current stack needs:

1. Postgres for transactional data.
2. ClickHouse for analytics and the trace-query workload.
3. Redis for queuing and caching.
4. S3-compatible object storage for large payloads.

If you skip this and expect a single database, the deployment will confuse you fast. Every one of these is a service you stand up, connect and keep running. That is the real cost of self-hosting Langfuse in 2026.

Step 2: Stand up a Docker Compose instance to evaluate

For a first look, do not go straight to production. Run the whole thing locally.

Langfuse ships a Docker Compose configuration that brings up all four services on one machine. This is the right way to evaluate self-hosting - you see the real architecture, confirm your app can send traces, and click around the actual product without committing to a production topology.

Point your app at the local instance and send a few traces. Langfuse operates as an OpenTelemetry backend receiving traces on an OTLP endpoint at /api/public/otel, and it also has native SDKs for Python, JS/TypeScript, LangChain, LlamaIndex, the OpenAI SDK and the Vercel AI SDK. Wire up whichever matches your stack and verify traces land.

One integration detail to note now, before it bites you later: Langfuse supports OTLP over HTTP only - gRPC is not supported yet. If your OpenTelemetry exporter defaults to gRPC, switch it to HTTP or the traces will silently fail to arrive.

Step 3: Plan the production deployment

Docker Compose on one box is for evaluation. Production means running the four services with real durability and separation - which in practice means Kubernetes for most teams. Langfuse documents both Docker Compose and Kubernetes deployment paths.

At this stage, plan for:

• Persistence and backups for Postgres and ClickHouse. These hold your traces and your prompt history. Losing them loses your observability record.
• Object storage that is actually durable - real S3, GCS or MinIO with proper configuration, not a local volume.
• Monitoring the stack itself. You now operate four services, so you need to know when one is unhealthy. The irony of an unmonitored observability platform is not lost on anyone who has run one.

Step 4: Survive the ClickHouse migration

This is the step people underestimate, so I am giving it its own section.

The migration to the v3 ClickHouse architecture is where self-hosters get stuck. GitHub has a visible string of migration threads reporting memory errors, timeouts and duplicate-column errors, with some clusters needing auto-migration disabled and run manually. This is the single most-cited pain point in self-hosted Langfuse.

The way through it:

1. Do it on a staging copy first. Never run a schema migration against your only production data set as a first attempt.
2. Give ClickHouse enough memory. The memory errors in those threads are the recurring symptom. Under-provisioned ClickHouse is the usual root cause.
3. Be ready to disable auto-migration and run it manually if the automatic path stalls, which is what several affected clusters ended up doing.

None of this means the software is broken. It means a data migration across four services under load is hard, and you should treat it as a real project, not a checkbox.

Step 5: Know when to stop and pay instead

Here is the honest decision. Self-hosting Langfuse is free software, not free operations. If your team can run and maintain a four-service stack, it is the best deal in the category - the real product for the cost of infrastructure. If it cannot, the $29/mo Core cloud tier sidesteps the entire ClickHouse problem and is still dramatically cheaper than LangSmith at scale - Langfuse runs roughly $101/mo at 1M events versus LangSmith’s roughly $2,514/mo for comparable volume.

Self-host when you have data-residency requirements or enough scale that the per-trace cost genuinely hurts. Otherwise, a small team’s engineering time is worth more than the cloud tier, and the managed option is not a compromise on features.

If four services is too much: Opik

If the appeal of Langfuse is “open source I can self-host without losing features” but four services is more than you want to run, look at Opik. It is Comet’s Apache-2.0 platform, and Comet states the self-hosted build ships the full feature set with unlimited spans, members and retention and no gates - designed to self-host at Kubernetes scale without feature loss. The license is more permissive than most, and if you would rather have managed, Opik Pro cloud is $19/mo for 100k spans, the cheapest of the major platforms.

The one watch-out on Opik is per-seat pricing on the cloud as your team grows, so model that if you have a large team. But for the specific question “open source I keep every feature when I self-host, with fewer moving parts than Langfuse v3,” it is the cleanest alternative.

Bottom line

Self-hosted Langfuse is genuinely feature-complete and genuinely free - only three features are gated, and the rest is the real product under MIT. Go in knowing it is four services now, that the ClickHouse migration is the hard part, and that “free” means the software, not the ops time. Run it if you have the capacity. If you do not, the cloud tier is cheap enough that self-hosting to save money stops making sense.