Langfuse vs LangSmith: when each one fits
If your LLM traces must stay inside your own network, the first question is whether self-hosting requires a paid license. For Langfuse, the answer is no for the core product: code outside its ee directories is MIT licensed and Langfuse states that all core features and APIs are available in the open source version without limits. Langfuse fits teams that want to run the stack themselves and are ready to operate its components: the web and worker containers, PostgreSQL, ClickHouse, Redis or Valkey, and S3-compatible blob storage. The license key is needed only for specific add-ons such as project-level RBAC, data retention policies, audit logs, server-side data masking and SCIM provisioning, so check that list against your requirements before you assume you need one.
LangSmith fits a different set of conditions. It suits teams already built on LangChain, teams that are comfortable with a cloud-first product and Google or GitHub sign-in, and buyers who will accept the Enterprise plan to self-host. LangChain documents self-hosted LangSmith as an add-on to that plan, requiring a license key and running in your Kubernetes cluster with ClickHouse, PostgreSQL and Redis. The LangSmith pricing page lists custom SSO, ABAC and RBAC only on Enterprise, and it is cloud only below that tier. Ask LangChain for the current self-hosted terms in writing, since the commercial structure is custom priced and you cannot estimate the cost from public pages alone.
The decision turns on four things. First, residency rules: if traces may not leave your environment, LangSmith self-hosting means the Enterprise add-on, while Langfuse self-hosting does not. Second, identity requirements: confirm which SSO and role model you need and whether it sits in a tier you can afford. Third, in-house Kubernetes skills, because self-hosted LangSmith runs on Helm charts, while Langfuse also offers a single-VM Docker Compose path for testing without high availability. Fourth, which Enterprise features you actually need, since the Langfuse key and the LangSmith Enterprise plan gate different capabilities. Write these four answers down before requesting quotes.
Which platform fits which scenario
This table maps common team situations to the platform that usually fits better, the condition that drives the choice, and what to confirm with each vendor. Read each row against your own residency, stack and licensing constraints before shortlisting.
| Scenario | Better fit | Condition that drives the choice | Confirm with each vendor |
|---|---|---|---|
| Data residency with strict on-premises rules | Langfuse | Self-hosting the MIT edition needs no license key for core features, so traces stay in your infrastructure without an Enterprise contract. LangSmith self-hosting is an Enterprise add-on that requires a license key. | Langfuse: which features in your plan need an Enterprise key. LangSmith: whether self-hosted Enterprise is available in your region and environment, and the license terms for running it in your cluster. |
| LangChain-heavy stack | LangSmith, if the Enterprise path is acceptable | Native integration with LangChain and LangGraph reduces instrumentation work. Langfuse also accepts OpenTelemetry and SDK tracing, so the gap narrows if your code already emits OpenTelemetry spans. | LangSmith: current tracing setup for your LangChain version. Langfuse: which SDK or OpenTelemetry path covers your framework calls. |
| Small cloud-hosted prototype | LangSmith Developer or Plus plan, or Langfuse Cloud | A single seat with a small trace allowance suits early work. Cloud sign-in options and trace retention differ by tier, so the cheapest route depends on volume and how long you must keep traces. | LangSmith: trace limits and retention for your expected volume, and which sign-in methods your team can use. Langfuse Cloud: plan limits and data regions. |
| Regulated team needing SSO and RBAC | Depends on the Enterprise terms you can accept | LangSmith lists custom SSO, ABAC and RBAC on Enterprise. In Langfuse, project-level RBAC, audit logs and SCIM sit behind an Enterprise license key on self-hosted deployments, so the cost of that key is a deciding factor. | Langfuse: which SSO methods and roles your key covers, and what happens to features if the key is removed. LangSmith: SSO protocols, ABAC scope and the support SLA in writing. |
| No Kubernetes or ClickHouse operations skills | Neither as a self-run stack without support; LangSmith Enterprise or Langfuse Cloud shift more operation to the vendor | Self-hosted LangSmith runs on Kubernetes with Helm and ClickHouse. Self-hosted Langfuse needs ClickHouse, PostgreSQL, Redis or Valkey and blob storage, and a single VM Compose setup is documented for testing only, not high availability. | Ask both vendors who operates upgrades, backups and ClickHouse tuning. Ask DeployOpen or another implementer to scope the operating model in writing. |
| Team expecting to change platforms later | Langfuse, for code and data portability | Langfuse's MIT core and self-hosted data in your own PostgreSQL, ClickHouse and blob storage keep exit options open. LangSmith is a commercial product, so the exit path depends on its export and API terms. | LangSmith: data export formats, API access and retention on exit. Langfuse: export options and whether any feature you rely on needs the Enterprise key. |
How each platform is built and what it means for operations
Both platforms store traces in ClickHouse and transactional data in PostgreSQL, so the operating questions are less about which databases exist and more about who runs them, how they scale and how upgrades touch them. The cards below cover the components, the deployment shapes and the upgrade and scaling decisions that set the day-two workload for each.
Langfuse web and worker containers
A self-hosted Langfuse deployment runs two application containers: Langfuse Web serves the UI and APIs, and Langfuse Worker processes asynchronous events. Behind them sit PostgreSQL, ClickHouse, Redis or Valkey and S3-compatible blob storage, so you operate four stateful services in addition to the app. Check who owns backups, restores and patching for each one before you commit, because the Langfuse containers themselves are the smallest part of the job.
Compose on one VM versus Kubernetes
Langfuse documents Docker Compose on a single VM for testing, and states that this setup has no high availability. Its production guidance points to Kubernetes with Helm or Terraform on AWS, Azure or GCP. LangSmith's self-hosted option is Kubernetes-only, so a team that must run production on a single VM cannot use that path. Decide early whether a test instance will be promoted, since moving data between shapes adds work.
LangSmith Helm deployment in your cluster
Self-hosted LangSmith runs on Kubernetes with Helm charts inside the customer's cluster, and it is delivered as an add-on to the Enterprise plan that requires a license key. Its footprint is ClickHouse for trace and feedback data, PostgreSQL for transactional data, Redis or Valkey for queues and caching, and S3, Azure Blob or Google Cloud Storage for artifacts. Ask LangChain which chart version and Kubernetes versions it supports, and who maintains the cluster-level components the chart depends on.
Shared ClickHouse and PostgreSQL footprint
Both platforms rely on ClickHouse for analytical trace data and PostgreSQL for transactional records, which makes the database layer the main operating commitment. Langfuse's scaling guide lists 2 CPU and 8 GiB for ClickHouse, with at least 16 GiB of memory for larger deployments. Your DBA and platform team need backup, restore and capacity plans for both engines, and your data residency review should cover where those volumes live.
Upgrades and the v3 to v4 ClickHouse requirements
Langfuse applies database migrations automatically at startup for updates within a major version, but major upgrades follow dedicated guides. The v3 to v4 path 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 data model. The guide also advises about 3x ClickHouse disk headroom when backfilling history, so plan that disk before the upgrade window.
Helm and scaling decisions set the load
Langfuse recommends scaling worker containers on CPU load and, under heavy ingestion, splitting langfuse-web into separate ingestion and user interface deployments. LangSmith's Helm chart fixes more of that layout for you but still leaves sizing of the queue, storage and database tiers to your team. Ask each vendor which settings change under load, which are safe to tune yourself, and which need a support engagement to change.
Feature and licensing comparison
This table compares how each platform is licensed, what it costs to self-host, and which features depend on a paid tier. Read each cell with its condition attached, since several Langfuse features need an Enterprise license key and several LangSmith features sit on higher plans or require the Enterprise add-on.
| Row | Langfuse | LangSmith |
|---|---|---|
| License | MIT outside the ee directories, with a separate commercial license for code inside them | Commercial LangChain product, not open source |
| Self-hosted availability | Free open source edition runs self-hosted on the same codebase as Langfuse Cloud | Self-hosted only as an add-on to the Enterprise plan, which requires a license key |
| Core features in the free edition | All core features and APIs available without limits in the MIT edition | Developer plan at $0 for one seat with up to 5,000 base traces per month (cloud only) |
| Paid-only features | Project-level RBAC, protected prompt labels, data retention policies, audit logs, server-side data masking, UI customization, org management API with SCIM and instance management API need an Enterprise license key | Self-hosted and hybrid deployment, custom SSO, ABAC, RBAC and support SLA sit on the Enterprise plan at custom pricing |
| Identity options | SSO is available in self-hosted deployments; SCIM sits behind the Enterprise license key | Google and GitHub sign-in below Enterprise; custom SSO and ABAC on Enterprise |
| RBAC availability by plan | Project-level RBAC roles require an Enterprise license key; confirm which base roles apply in the open source edition | Role-based access control on Plus and Enterprise; ABAC on Enterprise |
| Data retention options | Retention policies require an Enterprise license key; confirm retention controls in your edition before relying on them | Base traces kept 14 days; extended traces kept 180 days at extra cost |
| Deployment targets | Docker Compose on a single VM for testing (no high availability); Kubernetes with Helm or Terraform on AWS, Azure and GCP for production | Self-hosted on Kubernetes with Helm charts in your cluster |
| Infrastructure needs | Web and worker containers plus PostgreSQL, ClickHouse, Redis or Valkey and S3-compatible storage; ClickHouse at least 2 CPU and 8 GiB | ClickHouse for traces, PostgreSQL for transactional data, Redis or Valkey for queues, and S3, Azure Blob or Google Cloud Storage for artifacts |
What each license and edition covers
Langfuse is open core. Code outside its ee directories is MIT licensed, and the project 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 the free edition is not a reduced build. The commercial license applies only to code inside the enterprise directories, and a small set of administrative and governance features depends on an Enterprise license key.
- MIT core: Code outside the
eedirectories,web/src/ee/andworker/src/ee/is MIT Expat licensed, which permits internal use, modification and hosting without a royalty. - Gated features: Project-level RBAC roles, protected prompt labels, data retention policies, audit logs, server-side data masking, UI customization, organization creators, and the org management API with SCIM and the instance management API need a license key.
- Free open source plan: Langfuse's self-hosted pricing page lists a free open source plan with no feature limits on the core product.
- Self-Hosted Enterprise plan: Custom-priced. It adds a named support engineer, solutions architect access and a support SLA. Ask for the SLA terms in writing.
- Operating cost: Licensing does not cover the PostgreSQL, ClickHouse, Redis or Valkey and blob storage you run yourself.
Before you rely on the open edition for audit or identity needs, confirm which controls your compliance and access rules require, and check whether each one sits in the core or behind the key.
LangSmith is a commercial LangChain product, not open source. Its Developer and Plus plans are cloud only. Self-hosted and hybrid deployment appear on the Enterprise plan, which LangChain documents as an add-on that requires a license key and runs in your Kubernetes cluster. Self-hosting is therefore a contract decision, priced through a custom quote rather than a published tier.
- Developer plan: $0 for one seat with up to 5,000 base traces per month, then pay-as-you-go, per the LangChain pricing page.
- Plus plan: $39 per seat per month with up to 10,000 base traces per month, then pay-as-you-go. Role-based access control is included here, while single sign-on is limited to Google and GitHub below Enterprise.
- Retention tiers: Base traces keep 14 days of retention. Extended traces keep 180 days and cost extra.
- Enterprise plan: Custom pricing. It adds self-hosted and hybrid deployment, custom SSO, ABAC and RBAC, and a support SLA.
- Self-hosted license key: The key gates the self-hosted deployment itself, so a buyer should ask what the key covers, what happens at renewal, and what runs if it lapses.
Ask LangChain for the Enterprise order form, the list of features the license key enables, and the support SLA terms before you compare costs with a self-hosted Langfuse stack.
Both products separate what is free from what is paid, but they draw the line in different places. Langfuse keeps the full core in the open edition and gates governance features. LangSmith gates the entire self-hosted deployment behind the Enterprise contract. A buyer comparing the two should translate each vendor's edition table into a list of the controls their own environment requires.
- Access controls: Confirm whether project-level RBAC, SSO and SCIM are in the free tier, the license key, or the Enterprise contract.
- Data governance: Confirm whether retention policies, masking and audit logs are available without a key, and how long traces persist at each tier.
- Continuity: Ask what happens to a running deployment if a license key expires or is removed, and whether data remains accessible.
- Support: Compare named support, architect access and SLA terms in writing, not from the marketing summary.
- Scope of the quote: Ask each vendor which components the price covers and which you must run yourself.
Bring these questions to both vendors and get the answers in writing before you finalize the shortlist.
What drives the running cost of each
Both platforms are paid for in infrastructure, staff time and vendor fees, but the split differs. Langfuse Self-Hosted is a free MIT edition you run yourself, with optional Enterprise fees, while LangSmith self-hosting sits inside a custom-priced Enterprise contract. Use the cards below to separate one-time setup from recurring spend before asking for a quote.
Infrastructure footprint to run
Langfuse documents 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. LangSmith self-hosting runs on Kubernetes with ClickHouse, PostgreSQL and Redis or Valkey, but the vendor's sizing guidance is in its documentation and your quote should state it. Ask for the sizing for your expected trace volume, and for who owns the cloud spend for those nodes.
Skilled staff for ClickHouse and Kubernetes
Both stacks depend on ClickHouse for trace data, so someone on your team must be able to monitor disk, backups and query performance. Langfuse's Compose path on one VM is documented for testing without high availability, which pushes production work toward Kubernetes with Helm or Terraform. Staff time is usually the largest recurring cost in a self-hosted deployment, so count the hours for on-call coverage and upgrades, not only the first install.
Enterprise support tier fees
Langfuse's self-hosted pricing page lists a custom-priced Self-Hosted Enterprise plan that adds a named support engineer, solutions architect access and a support SLA. LangSmith's Enterprise plan includes a support SLA alongside self-hosted deployment, at custom pricing. Ask each vendor for the exact response commitments, what is included in the SLA, and whether support is priced per year or per deployment, since this is the only recurring vendor fee with a support commitment attached.
Per-seat and trace-volume pricing
LangSmith's cloud plans price by seat and by base traces: the Plus plan lists $39 per seat per month with up to 10,000 base traces per month, then pay-as-you-go. Extended traces with 180-day retention cost extra. Langfuse self-hosted has no seat or trace fee in the MIT edition, so its costs scale with your infrastructure instead. If you compare cloud LangSmith to self-hosted Langfuse, model seats and trace growth over the contract term.
Upgrade effort and migrations
Langfuse says minor updates within a major version apply database migrations automatically at startup, while major upgrades follow dedicated guides. 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. Budget staff time and temporary storage for each major move, and ask LangChain what upgrade work its Helm charts and Kubernetes version changes require.
Edition fees and license key costs
In Langfuse, some features such as RBAC roles, data retention, audit logs and SCIM need an Enterprise license key, so the fee is the cost of unlocking those controls, not of running the software. LangSmith self-hosting requires a license key as an add-on to its Enterprise plan. Ask whether the key is per deployment, per user or per year, what happens at renewal, and whether removing the key changes access to data you already store.
Moving traces and prompts between the two
This sequence shows a team how to move LLM tracing, feedback and prompt management from LangSmith to Langfuse, or back, without losing track of what was measured and why. It ends with a tested cutover and a record of what had to be rebuilt by hand.
Inventory instrumentation and SDK calls
The application or platform engineer lists every place the code sends data to the current tool: LangChain or LangGraph callbacks, direct SDK calls, OpenTelemetry exporters, environment variables and any proxy or base URL settings. Each call is tagged with the service that owns it and whether it sends traces, feedback, datasets or prompts. The step is done when the list covers every production and staging service and a reviewer has checked it against a recent deployment manifest. Ask each vendor which instrumentation path it supports for the language and framework your team uses, since the mapping depends on that choice.
Map trace and feedback fields
The engineer builds a field map that pairs each trace, span, run, metadata key, tag, user identifier and feedback score in the source tool with its equivalent in the target. Some fields will have no direct match, such as run types, nested run structures or feedback categories, and those are written down as exceptions. The output is a reviewed mapping document that a second engineer has signed off. Confirm with each vendor what the export format contains, including whether feedback and metadata are included, before assuming the map is complete.
Decide historic data retention
The platform owner and the compliance lead decide which historic traces, feedback and datasets must move and which can stay in the source system for its retention window. This decision follows the data classification and any data residency rules that apply to LLM inputs and outputs, which may contain personal data. Be aware that LangSmith's base and extended trace retention settings differ, so the retention period already applied to each dataset affects what is worth exporting. The step closes with a written retention decision and an owner for the archive. Confirm the export limits and format with each vendor before committing to a bulk move.
Rebuild dashboards, evaluations and prompt management
The team recreates the dashboards, alert queries, evaluation datasets and scoring jobs in the target tool, then moves prompts and their versions by hand or through the export path the vendors support. Prompt labels, versions and any approval workflow usually need manual review because the two tools model them differently. Some features tied to a paid tier, such as certain access controls or retention settings, may not exist in the destination at the same level. The step is complete when each dashboard and evaluation reproduces the results of a known sample run. Record every item that was rebuilt rather than transferred.
Run both tools in parallel
The team sends the same traffic to the source and the target for a defined test period, so that trace counts, latency, cost attribution and feedback scores can be compared side by side. The engineer checks for dropped spans, mismatched metadata and missing feedback, and logs each gap with its cause. The output is a comparison report that shows where the two tools agree and where they do not, reviewed by the team that owns the dashboards. Set the length of the test period against your own traffic volume and risk tolerance rather than a fixed number.
Cut over and confirm the source is quiet
The engineer switches the production instrumentation to the target, removes the source exporters from each service, and confirms that no new data reaches the old tool. Alerting and on-call runbooks are updated to point at the new dashboards. The platform owner signs off on the cutover after the parallel report shows no unresolved gaps. The step is done when a test trace from each service appears only in the target and the runbook has been walked through once with the on-call team.
Retain the archive and close the source
The owner keeps the exported archive and any remaining source data for the retention period set in the earlier decision, then removes access and the subscription or deployment once that period ends. The compliance lead records where the archive is stored, who can read it and how deletion will be evidenced. The output is a closure record that lists what moved, what was rebuilt, what was left behind and when the source was retired. Confirm with the vendor what happens to data at the end of a plan, in writing, before the archive is accepted as complete.
Where implementation projects usually run long
The longest stretches in a Langfuse rollout are usually sizing and version alignment, not the first deployment. Self-hosted Langfuse runs a web and a worker container on top of PostgreSQL, ClickHouse, Redis or Valkey and S3-compatible blob storage. The Langfuse scaling guide lists minimums 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. Teams that size from those minimums often revisit the design once trace volume arrives. If you plan to move to v4, confirm your ClickHouse version first: the v3 to v4 guide requires ClickHouse 25.12 or later (26.4 recommended), PostgreSQL 15 or later and Redis 7.0 or later. It also advises about 3x ClickHouse disk headroom when backfilling historic data, so an upgrade with a large history can stall on storage before it stalls on code.
Identity and the Enterprise license key decision are the other common sources of delay, and they tend to surface late. Project-level RBAC roles, data retention policies, audit logs, server-side data masking and the SCIM-based org management API all require a license key on self-hosted Langfuse. Decide before the pilot which of these your controls depend on, and confirm with Langfuse what happens to the features if the key is later removed. Set up SSO against the Langfuse authentication and SSO documentation early, because identity changes often require a second round of testing with the identity team.
LangSmith's self-hosted path has its own dependencies. It is an add-on to the Enterprise plan, requires a license key and runs in your Kubernetes cluster with Helm charts, backed by ClickHouse, PostgreSQL, Redis or Valkey and object storage. Delays typically come from procurement for the license, cluster capacity and the Helm values for data residency, including where artifacts land in S3, Azure Blob or Google Cloud Storage. Ask LangChain to confirm the current chart version, supported Kubernetes versions and SSO options for your identity provider before committing to a timeline, since the pricing page lists custom SSO only on the Enterprise plan.
Questions buyers ask before choosing
Does self-hosted Langfuse need a license key?
No, not for the core product. Langfuse states that all core features and APIs are available in the MIT-licensed open source version without limits, and self-hosted deployments run the same codebase as Langfuse Cloud. A license key is needed only for specific add-on features in the enterprise directories, including project-level RBAC roles, protected prompt labels, data retention policies, audit logs, server-side data masking, UI customization, the org management API with SCIM and the instance management API. Confirm which of these your security or compliance requirements depend on, because those are the features that carry a commercial cost. Check the Langfuse license key documentation before you assume a feature is free.
What does self-hosted LangSmith cost commercially?
Self-hosted LangSmith is an add-on to the Enterprise plan, and LangChain documents that it requires a license key. The Enterprise plan is listed at custom pricing with a support SLA, custom SSO, ABAC and RBAC, so the commercial terms come from a negotiated quote rather than a public price. Ask for the price of the self-hosted add-on separately from the seat and trace terms, and ask which features are included in the self-hosted build. Note that LangSmith is a commercial product, not open source, so the license governs what you can run and change. Compare this with the self-hosted LangSmith documentation and the LangChain pricing page.
How much effort does running ClickHouse take for Langfuse?
The effort depends on sizing, backups, upgrades and how much trace data you keep. Langfuse's scaling guide lists minimum resources of 2 CPU and 8 GiB for ClickHouse, with at least 16 GiB of ClickHouse memory for larger deployments. Langfuse's v3 to v4 guide requires ClickHouse 25.12 or later (26.4 recommended) and advises about 3x ClickHouse disk headroom when backfilling historic data, so plan storage before you migrate. Both Langfuse and LangSmith use ClickHouse for trace data, so the database skill is shared, but you own it fully when self-hosting Langfuse. Ask your team whether they already operate ClickHouse, and confirm the sizing with Langfuse against your expected trace volume.
Can our team implement Langfuse without outside help?
Yes, if your engineers can operate Kubernetes or a Docker host, a managed PostgreSQL, Redis or Valkey, a ClickHouse cluster and S3-compatible storage. Langfuse documents Docker Compose on a single VM for testing, without high availability, and Kubernetes with Helm or Terraform for production on AWS, Azure and GCP. Outside help is useful when the rollout must meet internal security baselines, when you need SSO and RBAC configured correctly on day one, or when no one on staff has run ClickHouse before. DeployOpen implements, hardens, backs up and documents self-hosted platforms inside your own infrastructure under a fixed scope agreed in writing, so you can choose to hand over the full build, part of it, or a support retainer.
How long does a Langfuse rollout take, and what drives it?
No duration is published here, so ask for a timeline in the written scope rather than relying on a generic estimate. The main drivers are the deployment target (a single VM for testing or Kubernetes for production), whether you use managed or self-run PostgreSQL, ClickHouse and object storage, the identity and SSO integration, how many applications send traces, and whether you need to backfill historic data. Each of these changes the number of decisions and checks before go-live. Ask the implementation partner to list the milestones, the environments they will build and the acceptance tests that close each one.
What skills does the work need from our staff?
Plan for platform engineers who can run the six components Langfuse needs: web, worker, PostgreSQL, ClickHouse, Redis or Valkey and S3-compatible storage. Your team also needs someone who can instrument applications with the SDK or OpenTelemetry, and someone who owns access control and data retention decisions. Langfuse recommends scaling worker containers on CPU load and, under heavy ingestion, splitting langfuse-web into separate ingestion and user interface deployments, so capacity planning is an ongoing skill rather than a one-time setup. LangSmith reduces the infrastructure work because LangChain runs the cloud service, but your data then sits in that service unless you buy the self-hosted add-on.
How hard is switching between Langfuse and LangSmith later?
Switching is easier when your instrumentation is vendor neutral, and harder when your prompts, evaluations and datasets live only inside one platform. Langfuse supports OpenTelemetry tracing, which keeps the application side portable, but the stored traces, scores and prompt versions still need an export and import plan. Ask each vendor for its export formats and API access for traces, datasets and prompts before you commit. Also check how each platform handles retention, since LangSmith lists base traces with 14-day retention and extended traces with 180-day retention at extra cost, and any history you do not export will not follow you.
How DeployOpen helps you choose and implement
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For Langfuse vs LangSmith, we help you test both options against your data residency rules, your identity requirements and the infrastructure you already run before you commit to either.
How we scope
- Written scope covers which Langfuse features you need and whether they fall in the MIT edition or need an Enterprise license key.
- Scope records the target environment, such as Docker Compose on one VM for testing or Kubernetes for production.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
How we build
- We deploy the web, worker, PostgreSQL, ClickHouse, Redis or Valkey and blob storage components inside your infrastructure.
- We size each component against Langfuse's published minimum resources and document the scaling decisions we make.
- We configure SSO, retention and access controls to match your policies, then test trace ingestion end to end.
How we hand over
- You receive architecture notes, runbooks for upgrades and backups, and a record of every configuration choice made.
- Upgrade procedures cover in-major-version updates and the dedicated migration guide for each major version change.
- Handover includes a side-by-side record of the LangSmith self-hosting and cloud terms you requested, for your own review.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Retainers can cover monitoring of the ClickHouse and PostgreSQL footprint, capacity reviews and version upgrades.
- Ask us to confirm any licensing, SLA or support terms directly against the vendor's current documentation before signing.
