Is self-hosted LangSmith cost lower than LangSmith Cloud or self-hosted Langfuse?
The Langfuse software carries no license fee for its core features, so self-hosting it moves the cost into infrastructure, operations and any enterprise key you choose to buy. Langfuse's repository is MIT licensed outside its enterprise directories, and the project states that core features and APIs are available without limits in the open source version. Teams usually reach this comparison at a renewal, when a per-seat or per-trace bill grows with usage, or when longer retention pushes them onto a higher tier. Self-hosted LangSmith is different. It is an add-on to LangChain's Enterprise plan, needs a license key and deploys to your Kubernetes cluster with Helm or Terraform, as described in the LangSmith self-hosting documentation. Its cost is set by the enterprise contract, which DeployOpen does not price, so get the written terms before comparing totals.
A self-hosted Langfuse deployment runs Langfuse Web, Langfuse Worker, PostgreSQL, ClickHouse, Redis or Valkey, and S3-compatible blob storage. The Langfuse scaling guide lists minimum resources 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. Recurring costs include compute for these components, database operations, and blob storage that grows with trace volume. Storage growth is driven mainly by retention period, so set it deliberately before you size disks. Major upgrades are a planned project: the v3 to v4 guide requires ClickHouse 25.12 or later, PostgreSQL 15 or later and Redis 7.0 or later, and advises about 3x ClickHouse disk headroom when backfilling historic data.
Langfuse's enterprise key covers features such as project-level RBAC, data retention policies, audit logs, server-side data masking and SCIM. Its self-hosted pricing page describes a custom-priced Self-Hosted Enterprise plan with a named support engineer, solutions architect access and a support SLA. Confirm which of those features you need before budgeting, because a deployment that needs only core tracing carries no key cost. Ask LangChain whether the Enterprise add-on includes the support scope you expect and whether bulk export is available to your account, since export is Enterprise-only for customers who signed up after August 3, 2026. Then request both quotes on the same basis: infrastructure at your planned retention, upgrade effort, staff time and support, over the same period.
Which cost lines change when you move from LangSmith to self-hosted Langfuse
This table sets each LangSmith cost line beside its self-hosted Langfuse counterpart and marks whether it is one-time or recurring. Use it to see which spend moves to your own infrastructure and which effort stays with your team. Ask for line-item quotes, since the largest changes usually sit in storage growth, operations staffing and the optional Langfuse enterprise key.
| Cost line | Commercial side (LangSmith) | Self-hosted side (Langfuse) | One-time or recurring |
|---|---|---|---|
| Software license | Per-seat and per-trace subscription under a LangChain plan; self-hosting requires an Enterprise add-on with a license key | Core features are MIT licensed with no feature limits; enterprise license key only for listed advanced features | Recurring for LangSmith; none for core Langfuse |
| Trace or seat fees | Charged by seats and traces, so cost rises with team size and ingestion volume | No per-trace or per-seat fee; cost follows the infrastructure you run to store and query traces | Recurring for LangSmith; infrastructure-driven for Langfuse |
| Extended retention | Longer trace retention is a paid tier or add-on, so keeping data longer adds spend | Retention is set by your ClickHouse and blob storage capacity; data retention policies need an enterprise key | Recurring |
| Kubernetes or VM hosting | Included in the managed service; not your cost | Compute for Langfuse Web and Worker, run on Kubernetes with Helm or Terraform for production; a single VM is for testing only | Recurring |
| PostgreSQL, ClickHouse, Redis or Valkey | Not visible to you | Four data services to size, patch and back up; ClickHouse memory and disk are usually the largest sizing items | Recurring, with a one-time sizing exercise |
| S3-compatible storage | Bulk export to your own bucket is a separate concern, available by plan | Blob storage holds events and media and grows with retention; price it against your provider or on-premises storage | Recurring, growing with retention |
| Implementation and migration | Limited to SDK changes and exports when you stay on the hosted service | Deployment, network design, LangChain or LangGraph callback changes and historical data import; scope is fixed in writing before work starts | One-time |
| Support | Included in the LangChain plan or bought as an enterprise contract | Community support is free; the Self-Hosted Enterprise plan is custom-priced and adds a named support engineer, solutions architect access and a support SLA | Recurring if you buy a plan or retainer |
| Upgrades | Handled by the vendor on the hosted service | Minor updates within a major version apply database migrations at startup; major versions follow migration guides and need ClickHouse 25.12 or later and extra disk headroom for backfills | Recurring, with a one-time major upgrade cost |
| Internal skills | Limited to application integration | Kubernetes, PostgreSQL, ClickHouse and object storage operations; confirm whether your team has these or needs external support | Recurring staff time |
| Backups and disaster recovery | Managed by the vendor within the service terms | You back up PostgreSQL, ClickHouse and blob storage and test restores; define recovery targets before go-live | Recurring, with a one-time design |
What pushes the self-hosted Langfuse bill up or down
Self-hosted Langfuse has no license fee for its core features, so the bill is set by infrastructure, people and the choices that size them. The cards below cover the inputs that move those costs most, and what to check before you compare the total with LangSmith's per-seat and per-trace pricing.
Trace volume and ingestion peaks
Trace volume sets how much ClickHouse disk and memory you need, and peaks in ingestion set how many worker and web containers must run at once. Langfuse recommends scaling worker containers on CPU load and, under heavy ingestion, splitting langfuse-web into separate ingestion and user interface deployments. Measure your peak trace rate per minute, not your monthly average, before you size the cluster.
Retention length and storage growth
Retention is the main driver of storage growth, because every extra month of traces adds to ClickHouse disk and blob storage. Data retention policies are an Enterprise license key feature in self-hosted Langfuse, so a team that wants per-project retention rules must budget for the key. Ask what retention your compliance team needs, then model disk use for that window with headroom for migrations.
Number of users and enterprise key features
The core Langfuse feature set is MIT licensed with no user limits, but project-level RBAC roles, protected prompt labels, audit logs and SCIM provisioning need an Enterprise license key. Count the people who need restricted roles or audit trails, since that headcount determines whether the key is a cost line. Confirm the key terms and the Self-Hosted Enterprise support scope with Langfuse before you assume either is included.
Availability needs and deployment shape
Docker Compose on a single VM is documented for testing and has no high availability, so it suits a pilot but not a production tracing service. Production runs on Kubernetes with Helm or Terraform on AWS, Azure or GCP, which adds cluster, load balancer and managed database or storage costs. Decide early whether trace loss during an outage is acceptable, because that answer determines how much redundancy you pay for.
In-house operations skills
Someone on your team must run PostgreSQL, ClickHouse, Redis or Valkey and S3-compatible storage, then apply upgrades. Major upgrades follow dedicated migration guides, and the v3 to v4 path requires ClickHouse 25.12 or later and advises about 3x ClickHouse disk headroom for backfills. If no one has run ClickHouse in production, price in training, an external operator or a support retainer, and ask what each option costs in writing.
How to build the LangSmith versus Langfuse model with your own numbers
This sequence turns LangSmith's invoices and your own trace volumes into a like-for-like cost model against self-hosted Langfuse, so the comparison rests on your inputs rather than list prices. Every input should be confirmed with your LangSmith account team, your cloud provider and your internal owners before totals are compared.
Collect current LangSmith invoices and usage
Finance and the platform owner pull the last several LangSmith invoices and the account's seat count, trace counts and any extended retention or add-on line items. Ask your LangChain account contact to confirm how each charge is metered, including whether seats, base traces and extended-retention traces are billed separately. The step is done when every recurring line on the invoices maps to a metered unit you can reproduce.
Define the retention window and its tier
Engineering and compliance agree how long traces, datasets and prompt history must stay queryable, and for which projects. Confirm with LangSmith which plan includes the retention you need, since extended retention is a paid option on some tiers. The output is a single retention figure per data class, with the tier that covers it written next to it.
Measure trace volume and storage growth
The team exports a representative sample of real traces, measures average payload size per trace and per observation, and multiplies by expected monthly volume. Use that figure to project ClickHouse storage growth across the retention window you set, and add headroom for backfills or upgrades, which Langfuse's v3 to v4 guide advises at about 3x ClickHouse disk. The check is a monthly storage projection that your team can explain line by line.
Price the self-hosted infrastructure
Platform engineering takes the Langfuse component list (web, worker, PostgreSQL, Redis or Valkey, ClickHouse and S3-compatible blob storage) and sizes each against the minimums in Langfuse's scaling guide, then prices those instances, disks, backups and egress using your cloud or data center rates. Quote the sizing as separate lines so the cluster, storage and network costs can be changed independently. The output is a monthly infrastructure figure with its assumptions recorded.
Decide which enterprise features you require
Security and governance leads list which controls are needed, such as project-level RBAC, data retention policies, audit logs, server-side data masking and SCIM provisioning. Langfuse documents these as features that need an enterprise license key, so ask Langfuse whether a key or a support contract is required for each one and price it separately. The step closes with a yes or no for each feature and the quoted cost for those marked yes.
Add people time for upgrades and on-call
The platform team estimates the recurring effort to apply minor and major Langfuse upgrades, run database migrations, monitor the stack and respond to incidents, and records who carries each task. Consider whether internal staff, a retainer partner or Langfuse's paid support plan covers the on-call gap, and ask each option for its written scope. The output is an hours-per-month estimate with a named owner and a stated source for each rate.
Compare totals over the same period
Finance places the LangSmith total and the self-hosted total on the same time window, including one-time migration work, recurring licenses, infrastructure, support and internal time. Run the model at your current volume and at a higher volume to see which inputs move the result most, and document every assumption so it can be revisited at renewal. The check is a side-by-side table that the CFO and engineering lead have both reviewed.
Why ClickHouse storage and retention decide the long-term cost
Retention is the setting that most often decides the long-term cost of a self-hosted Langfuse deployment, because trace data accumulates for as long as your retention window allows. A longer window grows the ClickHouse disk that holds observations and scores, and it grows the S3-compatible blob storage that holds event payloads and exports. Neither curve is flat, so a cost estimate built on today's trace volume alone will understate what the platform holds a year from now. Measure your current daily ingestion in bytes (not just trace count), multiply by each retention window you are considering, and add headroom for growth in traffic and in prompt and output length.
Backfilling history adds a one-time cost that is easy to miss. The Langfuse v3 to v4 upgrade guide advises about 3x ClickHouse disk headroom when backfilling historic data, and it also requires ClickHouse 25.12 or later (26.4 recommended), PostgreSQL 15 or later and Redis 7.0 or later. If you plan to move years of LangSmith history into Langfuse, plan the disk for the backfill as well as for steady state, and run the migration against a copy of a representative slice first. Ask your platform engineers which ClickHouse volumes, storage class and snapshot policy will hold that peak, because the peak, not the steady state, is often what forces a storage expansion.
Retention policies are also a licensing decision. In self-hosted Langfuse, data retention policies are one of the features that require an Enterprise license key, alongside audit logs, server-side data masking and SCIM, so the open-source build does not give you a per-project retention control in the same way. Confirm with Langfuse, before you commit to a design, which retention behavior the community build provides and which requires a key, and document how deletions propagate to ClickHouse and blob storage. Price the key and support as a separate recurring line, and compare it with the storage and operations cost of the retention window you actually need.
Upgrades, support and the enterprise key in the Langfuse budget
Upgrades are the recurring cost most often missed in a self-hosted budget, and the Langfuse documentation separates them into two kinds. Updates within a major version are described as non-disruptive, and database migrations run automatically at startup. Major upgrades, such as v2 to v3 or v3 to v4, follow dedicated migration guides, and the v3 to v4 guide is the one that changes infrastructure. It requires ClickHouse 25.12 or later (26.4 recommended), PostgreSQL 15 or later and Redis 7.0 or later, and it moves to an observations-first ClickHouse data model. Your team pays for the staff time to rehearse that migration on a copy of production data, and for any ClickHouse upgrade that the migration forces on your cluster.
The guide also advises about 3x ClickHouse disk headroom when backfilling historic data, so ask your team to size that headroom before scheduling the upgrade rather than discovering it during the cutover window. Confirm the current supported versions and the migration steps against the Langfuse upgrade guide and the release notes on GitHub before you commit to a date. Budget for a staging environment that mirrors your ClickHouse sizing, because a failed backfill on production is the expensive outcome.
Support is the one line where Langfuse's model departs from paying for the software itself. The core features and APIs are available without limits under the MIT license, so you do not need a contract to run the product. The Self-Hosted Enterprise plan is custom-priced and adds a named support engineer, solutions architect access and a support SLA. Decide whether your organization needs those commitments in writing, and if so, ask Langfuse for the plan terms, the SLA response targets and what the solutions architect time includes. Separately, the enterprise license key unlocks features such as project-level RBAC, audit logs and data retention policies, so ask whether you need those features, which is a separate question from support. An independent implementation partner, including DeployOpen, can cover upgrades, testing and runbooks under a fixed-scope agreement, and the quote should list each upgrade and support task explicitly.
Questions buyers ask before comparing LangSmith and Langfuse costs
What does self-hosting Langfuse cost compared with LangSmith?
The total depends on the components you run and who runs them, so compare cost lines rather than headline prices. LangSmith's cost is driven by its plan, seats, trace volume and paid retention, and self-hosted LangSmith also requires an Enterprise contract with a license key. Self-hosted Langfuse replaces those lines with infrastructure and labor: compute and storage for Langfuse Web and Worker, PostgreSQL, ClickHouse, Redis or Valkey, and S3-compatible blob storage, plus the engineers who operate and upgrade them. Ask any vendor, including DeployOpen, for each line item, what is one-time and what recurs, and which volume and retention assumptions the quote uses.
How much does storage grow when I keep traces longer?
Storage grows with trace volume multiplied by retention period, so longer retention scales ClickHouse disk and blob storage roughly in proportion to the days kept. On LangSmith, longer retention is a paid option, while on self-hosted Langfuse you set the window yourself, subject to the Enterprise key for data retention policies. Size ClickHouse disk from your measured ingestion rate, and remember that Langfuse's v3 to v4 guide advises about 3x ClickHouse disk headroom when backfilling historic data. Confirm your expected trace size and retention with the vendor before sizing.
Can we run self-hosted Langfuse without outside help?
Yes, if your team has the skills to operate it, and many teams start with in-house staff. You need working knowledge of Kubernetes and Helm (or Terraform on AWS, Azure or GCP), PostgreSQL, ClickHouse, Redis or Valkey, object storage, backups and monitoring. Docker Compose on a single VM is available for testing but has no high availability, so production needs the Kubernetes path. Assess who will be on call, who owns upgrades and whether those skills exist in-house before deciding. A fixed-scope engagement from DeployOpen can cover planning, deployment, hardening, backup setup and documentation, with ongoing support available as a retainer.
Do we need the Langfuse enterprise license key for RBAC or retention?
Yes for several controls. Langfuse's core features and APIs are in the MIT-licensed open source version, but project-level RBAC roles, data retention policies, audit logs, server-side data masking, SCIM and the management APIs need an Enterprise license key. Protected prompt labels and UI customization are also key-gated. If your governance requirements depend on these controls, price the key into the comparison, and confirm the current list on Langfuse's license key documentation before you commit. Without the key, you can still set retention by other means, but confirm that approach with your compliance team.
How often does Langfuse ship upgrades, and what do they require?
Langfuse publishes releases on GitHub, and updates within a major version are non-disruptive, with database migrations applied automatically at startup. Major upgrades, such as v2 to v3 or v3 to v4, follow dedicated migration guides and need more planning. The v3 to v4 guide requires ClickHouse 25.12 or later (26.4 recommended), PostgreSQL 15 or later and Redis 7.0 or later, and moves to an observations-first ClickHouse data model. Budget staff time for reading the guide, testing in a non-production environment, taking backups and scheduling the change. Check the release notes for each version before you upgrade.
How long does a migration from LangSmith take, and what drives it?
Migration length depends on how much LangSmith usage you have, which is driven by the number of LangChain or LangGraph applications, the volume of traces you need to keep, how many evaluators and datasets must be rebuilt, and how many prompts and teams are involved. Export is a separate step: LangSmith bulk export writes Parquet to an S3-compatible bucket, and for accounts that signed up after August 3, 2026 it requires the Enterprise plan, while earlier Plus customers keep access until February 1, 2027. For the steps, plan limits and callback changes, read the sibling topic on migrating from LangSmith to Langfuse.
What should we ask for in a fixed-scope quote for this work?
Ask for a written scope that names each deliverable: the deployment target (Kubernetes with Helm or Terraform, and which cloud or data center), sizing for web, worker, PostgreSQL, Redis or Valkey and ClickHouse, storage and retention settings, backup and restore testing, SSO and RBAC configuration, and whether the Enterprise license key is in scope. Also ask which application integrations are included, how historic data is handled, what documentation and knowledge transfer you receive, and what ongoing support or upgrade retainer is offered separately. DeployOpen agrees scope, deliverables and timelines in writing before work starts and does not publish a price list, so the quote follows from that scope.
How DeployOpen scopes a fixed-price Langfuse cost review and deployment
DeployOpen is a Chainscore Labs company that plans, implements, hardens, backs up and documents self-hosted open-source platforms inside your own cloud accounts or data centers. For a LangSmith cost review and a Langfuse deployment, we start from a written scope that sets out what is measured, what is built and what your team receives before any work begins.
How we scope
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- The written scope lists your current LangSmith plan, seat count, trace volume and retention needs as the inputs to the cost comparison.
- We confirm which Langfuse features you need, since some, such as RBAC roles, data retention policies and SCIM, need an enterprise license key.
- The scope names the cloud or data center where PostgreSQL, ClickHouse, Redis or Valkey and blob storage will run.
How we build
- We deploy Langfuse Web and Langfuse Worker on Kubernetes with Helm or Terraform in your environment, following the self-hosting documentation.
- We size PostgreSQL, ClickHouse, Redis or Valkey and blob storage against your projected trace volume and retention period.
- We reconfigure LangChain and LangGraph tracing so application traces reach the new Langfuse project, and we test each path before cutover.
- We test backups, restores and the upgrade path, including the ClickHouse headroom needed for major version migrations.
How we hand over
- You receive architecture diagrams, sizing notes and a storage growth model that your finance and platform teams can review.
- Runbooks cover upgrades, scaling of the worker and web containers, and the steps for rotating keys and restoring data.
- Compliance evidence and configuration records are organized for your auditors, who issue any reports or certifications.
- Knowledge transfer sessions with your engineers are included in the written scope, so your team can operate the stack.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- A retainer can cover Langfuse version upgrades, capacity reviews as trace volume grows and periodic restore tests.
- Support terms, response expectations and any service levels are set out in the written agreement, so you can confirm them before signing.
- Langfuse's own Self-Hosted Enterprise plan is a separate commercial decision that we will help you compare against your written scope.
