Langfuse customization: when teams need outside help to shape the platform
Customizing Langfuse is mostly the work of agreeing conventions and building scores, evaluations and integrations on the public API. Many teams do this in-house when they have an engineer who knows both Langfuse and the applications being traced. The short answer is that the work can stay in-house when one or two people can own the conventions and the code, and a partner becomes worth considering when the change crosses several teams or needs skills your staff does not yet have. Most teams starting from a working self-hosted instance find that traces arrive, but trace names, metadata, score definitions and prompt versions differ from one team to the next.
Three triggers usually signal that outside help will save internal time. The first is multiple product teams with different trace shapes. One team may nest spans for each agent step while another logs a single generation per request, so dashboards and scores cannot compare them. The second is an evaluation pipeline that must run outside the UI, such as a scheduled job that reads traces through the API, writes scores back and blocks a release when a threshold fails. The third is a change that touches Enterprise-only features, where the team must decide whether to buy a license key before building anything on top of it.
Core features and APIs are included in the MIT-licensed open source version without limits, and self-hosted deployments run the same codebase as Langfuse Cloud. Most customization therefore needs no license purchase. Some features do need an Enterprise license key, including 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. Confirm with Langfuse which key applies before you design a control around one of these, because code in the enterprise directories falls under a separate license.
Before requesting a quote, write down the decisions that the work depends on: the naming scheme for traces, the user and session attributes to propagate, score definitions with allowed values, prompt label rules, and which controls must be enforced in the UI versus in application code. Ask any partner to state which items rely on Enterprise features, who maintains the evaluation jobs after handover, and how changes are tested in a staging instance before they reach production. Also confirm the Langfuse version you run, because API and data model behavior can change between major versions.
What customization work includes and what you receive
Customization work sits on top of a running self-hosted Langfuse instance and changes how your teams send, score and version LLM data. Each work package below ends in a named deliverable, and each depends on decisions and access that only your team can provide. The exact list is fixed in the written scope before work starts, and anything outside it is quoted separately.
Instrumentation conventions and SDK wiring
We agree a naming standard for traces, spans, users, sessions and tags, then wire the in-scope applications to Langfuse using the native SDKs or OpenTelemetry over OTLP at the /api/public/otel endpoint. Your input is the list of applications in scope, their runtimes, and the attributes your analysts need to filter on. Check that trace names match your naming standard in a staging project before production traffic is switched on.
Custom scores and evaluation jobs
We design the score taxonomy, such as groundedness, policy compliance or human review outcomes, and build the scoring module and any evaluation jobs that write scores back to traces. Your input is the written definition of each score, its value range, and who is allowed to set it. Confirm which scores are computed automatically and which are entered by reviewers, since the two need different validation and access rules.
Prompt management conventions and labels
We set the rules for prompt naming, versioning, environment labels such as staging and production, and who may promote a prompt. Your input is the owner of each prompt family and the release process your application teams already follow. Protected prompt labels require an Enterprise license key, so confirm which labels must be restricted before the convention is written, not after.
Public API scripts or internal tooling
We build tested scripts against the public API for tasks such as exporting traces, bulk-updating datasets or syncing prompts from source control. Your input is the list of tasks, the service account that will run them, and the environments they must reach. Each script is reviewed for error handling and for secrets handling, and its behavior is checked against a non-production instance.
Documentation and handover session
We deliver a runbook covering the conventions, score definitions, prompt labels, scripts and how each one is tested and rolled back, plus a handover session with the teams who will maintain them. Your input is the named maintainers, their availability for the session, and the internal wiki or repository where the documents will live. Confirm that the runbook covers any change that would need a Langfuse upgrade check, since SDK and server versions must stay compatible.
What drives customization cost and duration
This table lists the factors that change how much work a Langfuse customization takes, why each one matters and how to keep it contained. Read each row against your own estimate of applications, environments and features before asking for a quote. The main takeaway is that instrumentation breadth, Enterprise-only features and the state of the existing deployment usually move scope more than the customization itself.
| Driver | Why it matters | How to keep it down |
|---|---|---|
| Applications and frameworks instrumented | Each application, agent or framework needs its own trace setup, naming and verification, so effort grows with every service that sends traces. | Start with the highest-value applications and reuse one instrumentation pattern across services that share a framework. |
| Trace shapes and user or session models | Distinct trace structures and user or session attributes multiply the mapping rules and the test cases needed to confirm them. | Agree a small set of trace conventions and attribute names in writing before instrumentation starts. |
| Scores and evaluators, and where they run | Custom scores and evaluators that run in code add jobs, queues and load on worker containers, while UI-defined scores need less engineering. | Use UI-based scores where they meet the need and limit code-based evaluators to a short list with clear owners. |
| Projects, teams and role separation | Each project and team that needs its own access model adds configuration and review. Project-level roles require an Enterprise license key. | Confirm the role model with the client before build, and keep the number of projects to the boundaries that matter for access. |
| Environments that must match | Development, staging and production each need the same instrumentation, scores and prompt conventions, which multiplies deployment and verification work. | Manage configuration as code and promote changes through environments instead of rebuilding them in each one. |
| Enterprise-only features | Project-level RBAC, protected prompt labels, UI customization, server-side data masking and audit logs need an Enterprise license key and add design and test steps. | Confirm early which features are required, since the MIT open source version covers core features and APIs. |
| Existing Langfuse version and data stores | An older version or a bundled data store may need a chart or major version upgrade before customization starts, and ClickHouse and PostgreSQL versions must meet the upgrade guide requirements. | Check the deployed versions and data store releases against the current upgrade guide before scoping customization work. |
| Custom evaluation load on workers | Heavy custom evaluation jobs raise CPU load on Langfuse Worker, and the scaling guide advises scaling workers on CPU load. | Size worker capacity against the planned evaluation volume and review the scaling guide before adding evaluators. |
How a customization project moves from conventions to handover
The sequence starts from what your teams already record in Langfuse and ends with engineers who can run the customizations without us. Each phase closes with a named output, and the duration of each phase is set in the written scope.
Discover current traces, prompts and scores
We inventory the traces, prompt names, prompt versions and scores your teams already produce, and we interview the people who read them. We record inconsistent names, missing metadata and evaluations that are still run by hand. The output is a discovery register that lists each gap, its owner and the workflow it affects. The step is complete when the client has signed off the inventory and the gaps are ranked by the workflows they block.
Write the convention set
Working with your engineering and analytics leads, we write the convention set that every instrumentation change must follow. It covers trace names, metadata keys, user and session attributes, score names and prompt label rules, including which labels promote a prompt toward production. Where a rule depends on an Enterprise-only feature, such as protected prompt labels, the set says so and names the decision owner. The output is a versioned document approved by the client. Any attribute rules that depend on OpenTelemetry handling are detailed in the OTEL integration work and referenced here.
Build changes in a non-production environment
Engineers implement the instrumentation changes and the scoring or evaluation jobs in a non-production Langfuse environment that matches the planned production deployment. The Langfuse version in use determines which SDK and API versions the build targets, so the version recorded in the scope sets the client libraries and endpoints. Each change is traced back to a rule in the convention set. The step closes when the jobs write scores from sample traffic and the client's engineers can reproduce the results in their own environment.
Build API tooling and automated tests
We build the scripts and services that read and write through the public API, such as bulk score imports, prompt synchronization and dataset maintenance. Automated tests check that names, metadata keys and attribute types match the convention set, and that a failed API call is logged and retried. The output is a tested code repository with a readme and a test report. The step is complete when the tests pass in the non-production environment and the client has run them once with its own credentials.
Review the build against the convention set
A reviewer who did not write a change checks each instrumentation change, score definition and tool against the convention set, item by item. Each finding is logged with a severity, an owner and a fix. Changes that alter a name already used in production are flagged for a migration decision, because existing dashboards and evaluations depend on those names. The output is a signed review record in which every finding is either closed or accepted by the client's named owner.
Roll out to production with monitoring
We deploy the approved changes to production in the sequence agreed in the scope, typically starting with one application or team. Monitoring covers trace arrival, dropped or rejected events, score volume and the error rates of the scoring jobs, with alert thresholds agreed with the client. Before the change reaches all traffic, a rollback path is tested. The output is a rollout log and a monitoring baseline recorded at go-live, and the step closes when the baseline holds for the monitoring period set in the scope.
Hand over with runbooks
We transfer the code, configuration and documentation to the client's team and walk through the runbooks for common tasks: adding a score, changing a prompt label, rotating API keys and diagnosing missing traces. Each runbook names an owner and the check that confirms the fix worked. Whether ongoing support is covered by a retainer or left to the client's team is stated in the scope. The step closes when the client's engineers have performed each runbook themselves.
Naming conventions for traces, prompts and metadata to settle before code
Settle naming before the first line of instrumentation ships, because trace names, observation names and metadata keys become the history your team filters, scores and reports against. Renaming them later splits dashboards, breaks saved queries and leaves two generations of data that nobody wants to reconcile. Agree on one pattern for trace names that describes the business operation, such as an illustrative checkout.summarize_order, and a separate pattern for observations that describes the step inside it, such as a retrieval call or a model call. Write the rules in a short document that engineering, data science and operations sign off together. Include who may add a new name and how new names are reviewed.
Metadata needs the same discipline. Keep a shared registry of metadata keys, with a definition, allowed values and an owner for each key. Typical candidates include the deployed environment, the application release identifier, the tenant or business unit and the feature flag set in effect for a request. Decide casing once, for example lowercase with underscores, and enforce it in code review and in any shared helper library, so a Python service and a TypeScript service write the same key for the same meaning. Ask each team which keys it sends today and which it needs. Confirm with the SDK version you plan to deploy where metadata attaches, at trace or observation level, because placement determines which filters work in the UI and through the API.
User and session identifiers decide whether you can answer questions about a single customer journey later. Choose an identifier that stays stable for the life of the account and reveals little to people reading a trace, such as a salted hash or an internal subject identifier from your identity provider. Do not use email addresses or display names unless your data protection review has approved them. Session identifiers should group the turns of one conversation or workflow run. Generate them in the first service that handles the request and pass them to every downstream call. Document the propagation path across the frontend, gateway, backend and any OpenTelemetry context, then test it with a request that crosses all of them before any dashboard depends on it.
Prompt management needs its own naming rules. Give each prompt a name that describes its job and its owning team, and avoid names tied to a model or vendor, since the model will change more often than the task. Decide what a new version means. A new version should be created for each content change you want to compare, and the release identifier that deployed it should be recorded in the prompt or its metadata, so a regression seen in a trace can be traced back to a release. Labels such as production or staging need written meanings and a named owner for promotion. Protected prompt labels require an Enterprise license key, so confirm early whether your approval process needs them, because that answer changes how promotion works.
Scripts that read or write prompts and scores should use the public API and be written against the Langfuse version you actually run. Confirm endpoints, request fields and SDK method names in the documentation for that version, and do not copy examples from older blog posts or forum answers, since names and fields change across major versions. SDK compatibility also depends on the server. The upgrade guides state that Python SDK v5 and JS/TS SDK v6 need Langfuse v4.59.0 or later. Pin SDK versions in each service, record which Langfuse version each script was tested against, and run a small read and write check against a non-production instance after every upgrade.
How customization differs by starting point and environment
A new self-hosted instance with no traces yet gives the most freedom in how conventions are set. Naming of trace types, score names, prompt labels and project structure can be decided before the first event arrives, so the work is mostly design and instrumentation rather than translation. The main risk is deciding conventions too early without the application owners who will live with them, which produces names that drift once a second team starts sending data.
What changes in the work:
- Trace, span and generation naming is agreed once and written down before any application is instrumented.
- Custom scores and evaluation definitions are created alongside the first use case, not retrofitted later.
- Prompt management conventions, including label meanings and how prompts move between environments, are set up front.
- Your team chooses between native SDK instrumentation and generic OpenTelemetry tracing for each application.
Risks that rise:
- Inconsistent naming across the first two or three applications, which is expensive to correct after data exists.
- Evaluations that are defined before anyone has agreed what a good output looks like.
Inputs to provide:
- A list of the applications to instrument in the first phase and their owners.
- Naming and scoring conventions, or the people who can approve them.
- The language stack of each application, so the instrumentation approach can be confirmed.
Check that the naming standard is signed off by the team leads who will send the first traces.
When an instance replaces another observability tool, existing trace shapes must be mapped onto Langfuse's model before dashboards, scores and evaluations can be rebuilt. The customization work is therefore a translation exercise: each source field needs a destination, and some concepts will not match one to one. The migration itself is a sibling service, so this tab covers only what changes in customization.
What changes in the work:
- A mapping of existing trace attributes, span types and feedback fields to Langfuse equivalents is required before instrumentation changes are made.
- Historical scores or feedback in the old tool may need to be represented as custom scores, which requires a decision on names and value types.
- Prompts stored elsewhere must be reconciled with Langfuse prompt versions and labels.
- Teams often run both tools for a period, so instrumentation must be dual-sent or switched in a planned order.
Risks that rise:
- Loss of meaning when a field in the source tool has no direct counterpart.
- Two sets of conventions running in parallel, so reports disagree.
Inputs to provide:
- An export or schema description of the current trace and feedback data.
- The dashboards and alerts that must be reproduced, ranked by importance.
- The owners who can confirm that a mapped field means the same thing.
For the data movement itself, see the Langfuse migration service, which covers the transfer and the architecture changes Langfuse requires.
When several product teams share one deployment, customization shifts from configuration of a single workflow to governance of many. Project separation decides who sees which traces, scores and prompts, and roles decide who can change them. The technical setup is modest; the design decisions about boundaries and ownership carry most of the risk.
What changes in the work:
- Projects are defined per team or per product, with a rule for when a new project is created.
- Role assignments are mapped to the teams' existing identity groups, which ties this work to SSO.
- Shared score definitions and prompt conventions are kept in one place, with local extensions allowed where needed.
- Access to protected prompt labels and project-level roles may require an Enterprise license key.
Risks that rise:
- Teams inventing their own score names, so cross-project comparison fails.
- Over-broad roles that let one team change another team's prompts in production.
Inputs to provide:
- The list of teams, their projects and the people who should administer each one.
- Decisions on which conventions are shared and which are local.
- Confirmation of which features your edition covers, checked against the license key documentation.
Confirm before go-live that every project has a named owner and that the role model matches your access policy.
In a regulated or air-gapped environment, everything customization depends on must run inside the boundary. That includes instrumentation libraries, build pipelines for custom scripts, container images, and any model used for LLM-based evaluations. Each of these becomes a supply chain and approval question, and the evaluation models are often the least obvious item. The work also needs stronger evidence of what was changed and by whom.
What changes in the work:
- Client libraries, scripts and evaluation tooling are mirrored into internal repositories and built inside the boundary.
- Model-based evaluations are only possible if an approved model endpoint is reachable from inside the boundary, so the choice of model is a design decision.
- Custom scripts for exports, score backfills and prompt syncing are reviewed and version-controlled like other production code.
- Features such as audit logs, data masking and retention controls may need an Enterprise license key, which must be confirmed before design is frozen.
Risks that rise:
- Evaluations that silently fail because an external model endpoint is unreachable.
- Dependency updates that cannot be pulled quickly during a security response.
Inputs to provide:
- The internal artifact sources and approval process for libraries and images.
- The approved model endpoints for evaluations and the data classification they may receive.
- The change control and evidence standards that customization scripts must meet.
Confirm which evaluation models and dependencies your security team will approve before any custom evaluation is designed.
What usually goes wrong in Langfuse customization projects and how to prevent it
Most Langfuse customization problems are not technical failures of the platform. They come from naming, capacity, release and ownership decisions that were made informally and then left to drift. Each card names one pattern, the step that prevents it, and the role that should hold that step.
Inconsistent trace and score names
When each team names traces, observations and scores in its own style, dashboards and filters stop comparing like with like. Set a naming convention for trace names, observation names, score names and metadata keys before the first team instruments its application, and record it in a shared document. Review new names in instrumentation pull requests. Owner: the platform lead who owns the Langfuse project.
Evaluations added without capacity planning
Custom evaluations run through the worker container, so every new evaluator adds asynchronous load alongside ingestion. Langfuse recommends scaling workers on CPU load, and teams often add evaluators without checking that worker capacity still holds. Before enabling an evaluator on production traffic, measure its cost on a representative trace sample, set a scaling rule for the worker, and watch ingestion lag after the change. Owner: the platform engineer who runs the Kubernetes or Compose environment.
Prompt labels without a release process
Moving a production label to a new prompt version changes what the application runs without a code deployment. Without a release step, prompt changes reach users unannounced and cannot be traced to a reviewer. Define who may move the production label, require a review and a test run against saved examples before the move, and record the change in the team's release log. Protected prompt labels are an Enterprise feature, so if only the open source version is deployed, this control must be a written process. Owner: the product owner for the AI feature, with the engineering lead approving.
Scripts written for a different API version
Scripts that call the public API are often written against documentation or an SDK release that does not match the deployed Langfuse version. Failures can be silent, such as fields that are ignored or endpoints that return different shapes. Pin the Langfuse version and SDK versions in one place, check the release notes of the deployed version before writing new scripts, and run scripts against a staging instance first. Owner: the engineer who maintains the integration scripts, with the platform lead confirming the version.
Scores defined in the UI and duplicated in code
When a score is created in the Langfuse interface and the same score is also written by application code under a slightly different name or data type, the project holds two sources of truth and aggregations split. Decide for each score whether it is defined in the UI for human review or created by code for automated evaluation, and document that choice in the naming convention. Audit existing score names periodically for near duplicates. Owner: the evaluation lead who designs the scoring model.
Masking and retention assumed but not licensed
Teams often assume that data masking and retention policies are available in every self-hosted deployment, then discover that server-side masking and retention policies need an Enterprise license key. Confirm which controls the compliance requirements depend on before go-live, check them against the Langfuse license key documentation, and either obtain the key or implement the control in the application before traces are sent. Record the decision with the reviewer. Owner: the information security lead, with procurement confirming the edition.
Handover that leaves no one able to change conventions
Conventions are often documented once and then owned by no one, so when the original builders move on, teams invent workarounds rather than request changes. Name a convention owner, give that person write access to the naming document and the evaluation configuration, and schedule a review at each Langfuse upgrade. Confirm during handover that at least two people can explain how traces, scores and prompts are structured. Owner: the engineering manager responsible for the platform, with the convention owner named in the handover record.
Which customizations need the Enterprise license key
Langfuse states that all core features and APIs are available in the MIT-licensed open source version without limits, and that self-hosted deployments run the same codebase as Langfuse Cloud. Most customization work, including instrumentation, custom scores, evaluations, prompt management and use of the public API, does not depend on a license key. The exceptions are a specific set of self-hosted features that Langfuse documents as requiring an Enterprise license key: project-level RBAC roles, protected prompt labels, data retention policies, audit logs, server-side data masking, UI customization, organization creators, the org management API with SCIM, and the instance management API.
The practical question is which of your conventions the platform must enforce and which your teams can follow by agreement. A prompt convention such as "only reviewers promote a prompt to production" can be written down without a key, but it is enforced only if the protected label feature is available. Similarly, a rule that sensitive fields never reach storage can be applied in application code before traces are sent, or it can be enforced by server-side masking, which needs a key. Both approaches can be valid. The choice affects who must maintain the control and how an auditor would test it, so record the decision for each convention before the build starts.
Build a short register that maps each planned convention to one of three outcomes: enforced by the open source version, enforced by a key-gated feature, or handled by process and client code. For access control, confirm with Langfuse what the open source version allows at project level compared with the project-level RBAC roles that need a key, and test that result in your own environment. For retention, decide whether deletion will rely on a policy that needs a key or on an operational job you own. Treat any item in the register that depends on a key as a dependency on the license decision, and do not let engineers assume a feature is active because the UI shows it.
The enterprise directories in the repository (ee/, web/src/ee/ and worker/src/ee/) fall under a separate enterprise license, while the rest of the repository is MIT Expat licensed. If your customization touches those paths, through a fork, a patch or a build that modifies them, the terms for that code differ from the rest of the project. Before you commit to a design, read the Langfuse LICENSE file on GitHub and the Langfuse license key documentation, confirm the current terms in writing with Langfuse, and ask your legal or compliance team to review them. The editions and cost comparison for these features is covered on the cost of ownership and editions page.
Which customization parts teams keep in-house and which they outsource
This table compares each customization part of a self-hosted Langfuse setup with its usual owner, the skills it needs and when a partner is worth bringing in. Read it row by row to see where your own team is already strong and where a gap would slow the work. Most teams keep convention ownership and application changes internal while a partner builds the evaluation and tooling layer.
| Work part | Usual owner | Skills needed | When to outsource |
|---|---|---|---|
| Convention design | In-house | Product and platform leads with domain knowledge of trace naming, user and session attributes, and tagging | Rarely needed, but a partner can facilitate workshops if leads disagree on conventions |
| Instrumentation changes in application code | In-house | Application engineers who own the services and LLM call paths | Outsource only when the code base is owned by a vendor or an external team that cannot make changes |
| Custom score and evaluation jobs | Often shared, with a partner for new designs | Evaluation design, data science and backend engineering against the Langfuse API | Often outsourced when the evaluation method is new to the team and needs design and validation |
| Public API tooling and tests | Split between platform and partner | Backend engineering, API client work and automated test design | Useful when reporting or sync tooling must be built quickly and tested against your data model |
| Prompt management workflow and labels | In-house | Prompt owners, product managers and release engineers who define review and promotion steps | Outsource the initial workflow design if no owner has defined labels or review rules yet |
| Enterprise feature configuration and governance decisions | In-house, with the license decision made by leadership | Security, compliance and platform leads who set RBAC roles, protected labels, retention and audit needs | Advisory support is useful to map which features need an Enterprise license key before purchase |
| Documentation and handover | In-house owner with partner drafting support | Technical writing, platform operations and clear runbook habits | Partner drafting helps, but the internal owner must maintain the documents after handover |
Questions buyers ask before hiring help for Langfuse customization
What drives the cost of customizing Langfuse?
Scope drives cost most, and a quote follows from the written scope. The main cost is the engineering time needed to deliver the agreed work, which is paid to the implementation partner, plus internal time your teams spend reviewing conventions, providing access and testing. Cost drivers: the number of applications to instrument, whether custom scores and evaluations must be built or only defined, how many prompt management conventions must be written, whether the public API will feed other systems, and whether UI customization or other Enterprise-only features are in scope. Infrastructure and any Enterprise license are recurring costs, while instrumentation and convention design are usually one-time. Ask each quote to list deliverables, the environments covered, who performs each task, assumptions about your systems, and which costs are one-time and which recur.
How long does Langfuse customization usually take?
Duration depends on scope and on how settled your existing conventions are. A project with a few instrumented services and documented naming for traces, scores and prompts moves faster than one where teams have no shared trace structure yet. Ask for a phased plan that shows instrumentation, custom scores and evaluations, prompt conventions, validation in a non-production environment and handover. Schedules should name their assumptions, such as how quickly reviewers respond and when access is granted. Dependencies outside the build, including identity integration decisions and any Enterprise license procurement, can add waiting time, so ask the partner to show where these fall in the plan.
What do we need to provide before Langfuse customization starts?
Four inputs decide whether the work stays on schedule. Application access: repositories or deployment pipelines for the services being instrumented, plus credentials for a staging environment. A named owner for conventions: one person who can approve trace names, user and session attributes, score definitions and prompt labels. A non-production environment: a Langfuse instance that mirrors production closely enough to test SDK changes, evaluations and any upgrade. Decisions on Enterprise features: a clear answer on whether RBAC, protected prompt labels, audit logs, data masking, retention or UI customization are required, because these need a Langfuse Enterprise license key. Agree these inputs in writing so that delays can be traced to a specific party.
Can our internal team customize Langfuse without an implementation partner?
Yes, an internal team can do much of the work if it has the right skills and time. The core skills are Python or TypeScript for SDK instrumentation, familiarity with LLM application architecture, a working understanding of the Langfuse data model (traces, observations, scores and prompts), and evaluation design. Someone must also own conventions and review evaluation results. Container and Kubernetes skills matter only if your team also runs the deployment. Teams most often struggle with evaluation design and convention governance, not with SDK calls. A partner is worth considering when the scope spans many services, when internal staff lack time, or when you want a documented baseline that your team can maintain afterward.
Does customizing Langfuse affect future upgrades?
It can, and the risk depends on how the customization is built. Work that uses the public API, the supported SDKs and the OpenTelemetry endpoint is generally less exposed to upgrades than changes inside the codebase, direct database writes or edits to bundled Helm values. Langfuse applies database migrations automatically at startup within a major version, while major upgrades such as v3 to v4 follow dedicated migration guides. Those guides list requirements such as ClickHouse 25.12 or later, PostgreSQL 15 or later and Redis 7.0 or later, and Helm users with bundled data stores must upgrade the chart from v1 to v2 first. Document each customization, test it against the target version in a non-production environment, and check the release notes before every upgrade.
Can DeployOpen support Langfuse after customization is complete?
Yes, ongoing support is available as a retainer that can cover upkeep, upgrades and continuous testing after go-live. Scope the retainer in writing: which environments it covers, how requests are raised, what response expectations are agreed, and whether it includes upgrade planning, SDK compatibility checks and convention reviews. Langfuse also offers its own Self-Hosted Enterprise plan, which adds a named support engineer, solutions architect access and a support SLA. That plan is a separate, custom-priced contract with Langfuse and is not something DeployOpen sells. Request a quote for each option and compare what each one covers before deciding.
How DeployOpen scopes, delivers and hands over Langfuse customization
DeployOpen approaches Langfuse customization as a written scope agreed before work starts, covering instrumentation, scores, evaluations and prompt conventions inside your own infrastructure. We build against the public API and the open source codebase, document what we changed, and hand the work to your team with a clear record of which features depend on an Enterprise license key.
How we scope
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
- We map the trace, score and prompt workflows your teams need, and which instrumentation paths each application uses.
- We check each requested feature against the license key list so the written scope states clearly what needs an Enterprise key.
How we build
- We implement instrumentation in your applications, using native SDKs or OpenTelemetry where the team has chosen that path.
- We define custom scores and evaluation workflows and test them against representative traces in a non-production Langfuse instance.
- We set prompt management conventions, such as naming, labels and versioning rules, and verify them through the public API.
How we hand over
- We deliver documentation covering each instrumentation pattern, score definition and API integration built for your environment.
- We walk your engineers through the code, configuration and test evidence so they can extend the work without us.
- We record the open source and Enterprise feature dependencies in the handover so your team can plan future license decisions.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer, scoped separately from the original work.
- Retainers can cover changes to instrumentation and scores when your applications or Langfuse versions change.
- Confirm with us in the quote which post-handover tasks are included and how requests are prioritized and tracked.
