Langfuse cost of ownership and editions

The core of Langfuse is free to run. The repository is MIT Expat licensed, and Langfuse states that all core features and APIs are available in the open source version without limits. Self-hosted deployments run the same codebase as Langfuse Cloud, so tracing, prompt management, evaluations and the public API do not need a license key. The exception is a set of directories: content under the ee/, web/src/ee/ and worker/src/ee/ paths falls under a separate enterprise license. Your legal and procurement teams should read the LICENSE file in the repository and treat those directories as a different license category when they review the codebase.

Several controls need an Enterprise license key. The list includes project-level RBAC roles, protected prompt labels, data retention policies, audit logs, server-side data masking, UI customization, organization creators, the organization management API with SCIM, and the instance management API. For a regulated team, the access and data-handling items usually drive the decision. Project-level roles determine who can change prompts or view traces in each project. Retention policies and server-side masking control how long sensitive prompt and trace content persists. Audit logs record who did what. If your design depends on any of these, the Enterprise key is a requirement, not a convenience.

The Self-Hosted Enterprise plan is a separate purchase from the license key discussion above. Langfuse's self-hosted pricing page describes it as a custom-priced plan that adds a named support engineer, solutions architect access and a support SLA. The price comes from a quote, and the page does not publish a figure. Ask the vendor whether the plan bundles the license key or whether the key is sold separately, what the SLA response targets are, and whether the solutions architect time is capped. These answers change the recurring cost more than the feature list does.

Before you budget, confirm the current feature list against Langfuse's license key documentation. Feature gates move between releases, and an item that is free today may be gated later, or the reverse. Check the list against the specific version you plan to deploy, since the release you will run may differ from the one you test. Also confirm how the key is issued, how it is validated in an air-gapped network, and what happens to gated features if the key expires. Record the answers in your design file so the audit team can trace which controls depend on a commercial license.

Plan for more than one application container before you estimate anything else. A self-hosted Langfuse deployment runs two application containers, Langfuse Web, which serves the UI and APIs, and Langfuse Worker, which processes events asynchronously. Around them sit four data components: PostgreSQL, ClickHouse, Redis or Valkey, and S3-compatible blob storage. Each one is something your team or your partner must provision, secure, back up and upgrade inside your own infrastructure, so each one appears in the cost model. Ask your team to name the owner, the hosting option and the backup method for every component before the budget is set.

The documented minimums in Langfuse's scaling guide are 2 CPU and 4 GiB of memory for Langfuse Web, Langfuse Worker and PostgreSQL, 1 CPU and 1.5 GiB for Redis or Valkey, and 2 CPU and 8 GiB for ClickHouse. The guide also says larger deployments should give ClickHouse at least 16 GiB of memory. Treat these numbers as a floor that lets the stack start and stay within its documented requirements, not as a sizing for your workload. Trace volume, retention, the number of concurrent users and the number of projects all push the real requirement upward, and none of them is covered by the minimums.

The deployment target changes the cost more than the component list does. Langfuse documents Docker Compose on a single VM for testing, and it states that this setup has no high availability. That is a reasonable way to evaluate the product, but a single VM carries one failure domain, one disk and one set of backups that you must manage yourself. For production, Langfuse documents Kubernetes deployments with Helm or Terraform on AWS, Azure and GCP. Kubernetes adds control plane fees, load balancers, node pools, managed or self-run data stores and monitoring, so the recurring infrastructure line rises even before any workload grows.

Production cost rises with the choices you make inside that cluster. Running more than one replica of Web and Worker increases compute and makes the replica count a recurring line item. Langfuse recommends scaling Worker containers based on CPU load, and under heavy ingestion it recommends splitting langfuse-web into separate ingestion and user interface deployments, which means two deployments to size, observe and roll out. Backups of PostgreSQL, ClickHouse and blob storage need their own storage, retention periods and restore tests. Ask your team to confirm, in writing, the replica count per component, whether ingestion and UI are split, and the backup retention each environment requires before you request a quote.

Use the minimums to rule out undersized hardware, then size each component from your own trace volume, retention and concurrency with a load test in a non-production environment. Ask any partner to show that sizing method, the assumed trace volume, and which managed services they propose versus self-run services. Confirm with Langfuse the current minimums for your release, since the scaling guide is the authoritative source and figures can change between versions. A quote that lists only the minimums, without the replica plan, backup design and storage growth assumptions, does not yet describe the infrastructure you will run.

Most of the recurring Langfuse ownership cost sits in a small set of activities, and the split between your team and a partner should be decided per activity rather than for the platform as a whole. Day-to-day operations, meaning watching the Langfuse Web and Langfuse Worker containers, the PostgreSQL and ClickHouse instances, Redis or Valkey and the blob bucket, is usually the work teams keep in-house, because it runs every day and depends on knowing your alerting, on-call rota and change windows. It needs Kubernetes operations skills if you run the Helm or Terraform deployments, plus working knowledge of the data stores. Owning the trace schema for your applications and the prompt conventions your engineers follow is also best kept internal, since those decisions reflect how your product teams work.

Access reviews belong with your identity and security owners. Who holds Langfuse roles, which projects they can reach and who can manage the instance are decisions that tie into your joiner, mover and leaver process. Where you use project-level RBAC, protected prompt labels, audit logs or the SCIM-based org management API, those are Enterprise license features, so confirm with Langfuse whether your edition covers them before you assign the review to a role. Identity administration skills are needed here, and the review should be repeatable on a schedule you can show an assessor.

Several activities are often outsourced because they are infrequent, specialized or easy to get wrong once. Cost modeling, the initial architecture and the ClickHouse sizing exercise all depend on your expected trace volume, retention and query patterns, and they benefit from someone who has sized these stores before. The same applies to upgrade planning and execution. The v3 to v4 path, for example, requires specific ClickHouse, PostgreSQL and Redis versions and a backfill with extra disk headroom, and the Helm chart must move from v1 to v2 first if you use bundled data stores. Confirm the current version requirements in Langfuse's upgrade guide when you plan. SSO integration with your identity provider is another common outsourced item, because it is a one-time build with a defined set of settings to get right.

When you compare internal and partner quotes, ask each bidder to show which of these activities their price covers and which skills they assume your team already has. A quote that bundles initial sizing and architecture with a recurring operations retainer is easier to compare than one that only names a go-live date. Ask who will hold the ClickHouse administration and the on-call duties after handover, and what the Enterprise support plan would add on top of that work. Keep a written split of ownership in the implementation plan so that operations, schema, access and upgrade responsibilities are not left open at go-live.

A cost of ownership quote for self-hosted Langfuse is only as accurate as the inputs behind it. Before you request one, collect the facts that decide how much infrastructure, support and internal time the deployment needs. Most of the cost swings in a quote come from a short list of unknowns: where the platform will run, how many traces it will ingest and keep, which features need an Enterprise license key, and whether historic data has to move. Gathering these first is the fastest way to get a quote you can compare and approve.

Start with the hosting environment. Name the target cloud account, data center or air-gapped network, and state which Kubernetes or virtual machine standards your platform team already runs. Langfuse documents Docker Compose on a single VM for testing only, and Kubernetes with Helm or Terraform for production on AWS, Azure and GCP. The Langfuse scaling guide lists minimum resources for the web, worker, PostgreSQL, Redis or Valkey and ClickHouse containers. Tell the partner which managed or self-run services you prefer for PostgreSQL, ClickHouse, Redis and S3-compatible blob storage, because that choice changes both the build effort and the recurring operating cost.

Next, describe the expected load and the data you must keep. Estimate trace volume per day or month across environments, the typical size of prompts and completions, and the retention period each team needs. Retention drives ClickHouse disk and blob storage, so ask finance and the application owners to agree on one number per data class rather than a single guess. Also state the number of teams and applications that will send traces, and whether they will use native Langfuse SDKs or OpenTelemetry. Each additional team adds onboarding, instrumentation and support work that the quote should show separately.

Then gather the requirements that decide the edition. Record your identity provider (for example Okta, Entra ID or Keycloak), whether password sign-in must be disabled, and whether you need SCIM provisioning or project-level roles. Each of these features requires an Enterprise license key under Langfuse's documentation, so the edition decision follows from them. List the compliance drivers too, such as the audit logs, retention policies or data masking your security and compliance leads expect, and the evidence they will ask for. Settle backup and recovery expectations, including recovery time and recovery point targets, and say whether historic data must migrate from another tool. A clear edition decision made early keeps the quote from being reopened later, when a missing key or a migration requirement changes the scope.

Finally, name an accountable owner for finance, platform and security. The finance owner confirms budget categories and how one-time and recurring costs will be approved. The platform owner confirms the cluster, storage and networking standards. The security owner confirms identity, network exposure and retention rules. Ask the partner to estimate the implementation effort, infrastructure sizing, support and internal time in writing, and to show which figures depend on your inputs. You supply the trace volume, retention, identity and compliance facts, the owners and your environment details. The partner estimates the build effort, sizing, licensing lines and recurring support in the written quote, with each assumption stated so you can challenge it.