Which open-source option replaces LangSmith prompt management?
Teams leaving LangSmith's prompt hub and playground usually choose between two self-hosted options: Langfuse prompt management, which stores versions centrally and uses labels to move prompts between environments, or Opik's prompt library with its playground. The licensing difference decides many of these conversations. Langfuse's repository is MIT licensed except for the ee directories, and it states that all core features and APIs are available in the open-source version, while some features such as protected prompt labels, project-level RBAC and audit logs need an Enterprise license key. Opik is Apache-2.0 licensed, and its README states that the full platform, including prompt management, can be self-hosted without a commercial license.
Prompt management is only one part of the move. A prompt registry without traces tells you which version is deployed but not how it behaves, so the same decision covers tracing and evaluations. Langfuse links prompts to traces so you can analyze performance by prompt version, and its SDKs cache prompts client-side so retrieval adds no latency. Confirm that the tracing SDK you already use (LangChain or LangGraph callbacks, OpenTelemetry, or a custom decorator) sends the prompt version metadata your dashboards need, and test that a deliberately weaker prompt shows up as a regression before you cut over.
Before you choose, check the operating footprint. Self-hosted Langfuse runs Langfuse Web, Langfuse Worker, PostgreSQL, ClickHouse, Redis or Valkey, and S3-compatible storage, and Docker Compose on one VM is documented for testing only, not high availability. Opik uses ClickHouse, MySQL and Redis, with Docker Compose for local use and Helm charts for production. Ask your team which stack it can operate, who owns upgrades (Langfuse v3 to v4 requires ClickHouse 25.12 or later and PostgreSQL 15 or later), and whether a Enterprise key or support contract is needed for the controls your auditors will ask about.
How LangSmith prompt features map to open-source options
This table maps each LangSmith prompt feature to its Langfuse and Opik equivalent and notes what each needs in your environment. Read the license column first, because several Langfuse governance controls sit behind an Enterprise license key while Opik needs confirmation on its own governance features.
| Prompt feature | Langfuse (open source core) | Opik (Apache-2.0) |
|---|---|---|
| Prompt hub versioning | Central prompt store with version history, available in the MIT-licensed core | Prompt library with versioning; confirm version history and rollback behavior in your release |
| Labels or deployment tags | Labels move a version across environments such as staging and production, in the core | Confirm how Opik expresses environment tags for prompts in your deployed version |
| Protected prompt labels | Requires a Langfuse Enterprise license key; blocks unauthorized edits to designated labels | Confirm whether equivalent label protection exists; do not assume parity with Langfuse |
| Playground | Prompt testing in the UI with model selection, available in the core | Prompt playground is documented in the Opik README; confirm model and provider coverage |
| Prompt-to-trace linking | Traces link to prompt versions so you can compare performance by version, in the core | Confirm that traces record the prompt version used in each run in your setup |
| Client-side caching | SDK caches prompts client-side so retrieval adds no latency; test cache TTL in your services | Confirm SDK-side prompt caching and fallback behavior before production use |
| Project RBAC | Project-level roles require a Langfuse Enterprise license key | Confirm role granularity in the self-hosted Opik edition you deploy |
| Audit logs | Require a Langfuse Enterprise license key; plan storage and review for them | Confirm whether audit logging is available and where events are stored |
| Data retention controls | Retention policies require a Langfuse Enterprise license key; storage sizing follows retention | Retention is governed by your own ClickHouse storage; confirm purge tooling |
Langfuse or Opik: which fits which team
Both platforms cover prompt versioning and link prompts to traces, so the choice depends on licensing, the features you need behind a key, and how much data infrastructure your team wants to run. The cards below cover where each one fits and what to verify before you move prompts off LangSmith.
Langfuse prompt versions and labels
Langfuse stores prompts centrally, versions them, and uses labels to point each environment at a specific version. The SDK caches prompts client-side, so retrieval adds no latency at call time. Prompts are linked to traces, which lets you compare performance by prompt version after a change. Check that your deployment process promotes a label, not a hard-coded version number, so rollbacks stay a single label move.
Protected labels need an enterprise key
Protected prompt labels, which restrict who can move a production label, are listed among the self-hosted features that need an Enterprise license key. If your LangSmith workflow relies on controlled promotion to production, confirm whether you need that control on day one or whether a review step in your deployment pipeline is enough. Ask Langfuse which features your planned setup requires before you budget for the key.
Opik prompt library and playground
Opik includes prompt management with a playground, so teams can iterate on prompts in the same platform that stores traces and evaluations. The full platform, including prompt management, is Apache-2.0 and can be self-hosted without a commercial license. Check how Opik versions and labels prompts for your release process, since its labeling model differs from Langfuse and should be tested against your deployment steps before migration.
Licensing for the whole platform
Langfuse is MIT licensed outside its ee directories, which fall under a separate enterprise license. Opik is Apache-2.0 across the platform, including prompts and evaluations. If your compliance review treats any feature gate as a procurement event, Opik's single license is simpler to explain. If you already expect to buy support, Langfuse's enterprise tier adds a named support engineer and a support SLA.
Langfuse infrastructure footprint
A production Langfuse deployment runs Langfuse Web and Langfuse Worker, with PostgreSQL, ClickHouse, Redis or Valkey, and S3-compatible blob storage. Langfuse documents Docker Compose on a single VM for testing only, and Kubernetes with Helm or Terraform for production. Plan for four stateful services to back up and upgrade, and size ClickHouse memory early, since the scaling guide sets a 16 GiB ClickHouse memory minimum for larger deployments.
Opik infrastructure footprint
Opik runs on ClickHouse, MySQL and Redis, with Docker Compose through its opik.sh script for local use and Helm charts for Kubernetes production. Your team therefore operates three data services rather than Langfuse's four, since Opik does not list a separate blob store in its infrastructure. Confirm with Comet how attachments and exports are stored in your setup, and test Helm upgrades against a staging copy before committing to production.
How to keep prompt regressions visible after the move
The prompt name and version must be attached to every trace before you cut over, or regressions disappear into an undifferentiated stream of LLM calls. In Langfuse, prompts fetched through the SDK are linked to the generations they produce, so you can filter traces and dashboards by prompt version. Set the prompt name and version in your instrumentation for each call path, then run a test trace per prompt and confirm it appears under the right version in the Langfuse UI before you retire any LangSmith tracing. The same check applies to Opik's prompt library: confirm that the prompt identifier and version show on the traces your application sends, not only in the prompt catalog.
Use labels to decide what runs in each environment. Langfuse labels such as production and staging let you promote a version without redeploying code, because the SDK resolves the label at fetch time and caches the result client-side so retrieval adds no latency. Confirm three behaviors in your chosen version: how quickly a label change reaches running services after the SDK cache refreshes, whether a label can be protected from accidental reassignment (protected prompt labels need an Enterprise license key in self-hosted Langfuse), and how a rollback works if you move a label back to an earlier version. Record these results in your release runbook. Opik's label and environment handling should be checked the same way against the release you deploy.
After each change, compare latency, cost, error and evaluator scores grouped by prompt version, not by a single aggregate. Keep one evaluation set and run it against the old and new versions before promotion. Be aware of what breaks if SDK calls to the old LangSmith hub are not replaced: applications that still pull prompts from LangSmith keep serving the last version they fetched or fail at startup, and new versions you edit in Langfuse or Opik never reach them. Inventory every call site with a search for the LangSmith prompt client and treat any remaining call as a release blocker. Once all call sites are switched, monitor version-level dashboards for at least one full release cycle so a regression introduced by the move itself is visible.
Moving prompts and versions from LangSmith
This sequence moves your prompt library and its version history from LangSmith's prompt hub to a self-hosted store, so each production call can be traced back to the exact prompt version that produced it. It ends with a cutover that you can reverse if regressions appear.
Inventory prompts and playground usage
Engineering and the prompt owners list every prompt in the LangSmith hub, including which versions are live, which tags or commit references each application pulls, and which prompts are only tried in the playground. Record the model settings, variables and output parsers attached to each prompt, since these travel with the text. The step is done when every production prompt has an owner, a current version and a named application that calls it.
Confirm the prompt export method
Ask LangChain how prompt versions can be exported from your plan and tenant. LangSmith's documented bulk export covers trace data written as Parquet to an S3-compatible bucket, not prompt objects, so do not assume it carries prompt history. If no documented export exists, plan to recreate prompts through the API or by hand from the inventory. The step is done when the export method is written down and the team knows whether version history is preserved or only the current text.
Recreate prompt versions in the target store
Create each prompt in self-hosted Langfuse or Opik, then add the versions in order, starting with the version currently in production. Keep the original LangSmith version identifier in the commit message or metadata so the lineage stays traceable. Where history cannot be imported, record a single baseline version and note the date it was created. The step is done when each production prompt exists in the new store with the same text, variables and model settings as the source.
Map LangSmith tags to labels or prompt entries
Build a table that links each LangSmith tag or commit reference to a Langfuse label, such as production or staging, or to an Opik prompt entry and version. Langfuse uses version control and labels to manage deployments across environments, so a label like production can point to the version your application should load. Mark which labels should be protected from accidental edits, and confirm whether your Langfuse license tier includes protected prompt labels. The step is done when every LangSmith reference used in code has a documented equivalent.
Update SDK fetch calls and cache settings
Change each application's prompt fetch to the new SDK and set the client-side cache duration deliberately. Langfuse caches prompts in the SDK so retrieval adds no latency per request, which means a label change takes effect only after the cache expires, so set the duration to match how fast you need updates to reach production. Add a fallback to a bundled copy of the prompt for startup or outage cases. The step is done when a test deployment loads the expected version through the new SDK and the cache behavior is documented.
Link prompt versions to traces and run in parallel
Attach the prompt name and version to every trace in the new system, so latency, cost and quality can be compared by prompt version. Langfuse links prompts to traces for this analysis. Run LangSmith and the self-hosted store side by side on a shared slice of traffic or in staging, and compare scores from the same evaluation set for both versions. The step is done when a dashboard or query shows each trace tagged with its prompt version and the team has reviewed a regression check on a known change.
Cut over and keep the rollback path
Switch production applications to the self-hosted prompt labels in a controlled release, with the LangSmith prompt references still available in code until the new path has run without errors. Confirm with the prompt owners that outputs match the reviewed baseline, and assign someone to watch regression metrics after the switch. Keep LangSmith access until the export and history questions are settled, and document the date of cutover. The step is done when production reads only from the new store, the rollback has been tested, and the cutover record is filed.
Running prompt management beside the rest of the LLM stack
Prompt management works best as one store that tracing, gateways and evaluations all point to, not a fourth copy of the prompts. The cards below cover the integration points that decide whether a prompt version stays linked to the traces it produced after the move from LangSmith.
Keep LangChain and LangGraph callbacks
Existing LangChain and LangGraph applications send traces through callbacks, so the first decision is whether those callbacks move to the new backend or keep sending to LangSmith during a transition. Running both at once doubles trace volume and makes it harder to compare results. Confirm that the integration you choose attaches prompt version metadata to each run, because a trace without that link cannot show which prompt produced a regression.
Log gateway calls to Langfuse
If the team routes model calls through LiteLLM, the gateway can log requests to Langfuse, which places prompt versions and gateway spend in one trace view. The prompt itself should still be fetched from the Langfuse prompt store by the application, not copied into gateway configuration. Check which fields the gateway forwards, since the link between a prompt version and a gateway request depends on the metadata that survives that hop.
Portkey gateway and prompt stores
Portkey's gateway is MIT licensed and can run in your own infrastructure, but its repository lists prompt management among the enterprise features outside the open-source gateway. Teams that already use Portkey's gateway for routing should decide whether prompts stay in Langfuse or Opik, and avoid keeping the same prompt in both places. Ask Portkey and your own environment which features your deployment would use.
Map existing OpenTelemetry monitoring
If your platform team already runs OpenTelemetry collectors and dashboards, the LLM tracing backend should receive spans through the same pipeline rather than a separate agent. Langfuse and Opik both accept OpenTelemetry traces, so prompt version attributes can be added to spans your APM already stores. Confirm which span attributes your collector forwards and whether prompt content is allowed to leave your network in that pipeline.
Evaluations read prompt versions
Evaluators, datasets and annotation queues should reference prompt versions by ID or label rather than by copied text. When a new version is promoted, the evaluation history should still show which version each score belongs to. Decide before migration which system is the source of truth for prompt text, because evaluation tools that hold a second copy will drift from the production prompt over time.
One prompt store, one owner
Assign one team and one system as the owner of each prompt, and make every other tool read from it. Duplicate prompt stores in a gateway, an evaluation tool and application code are the most common cause of a prompt being edited in one place and tested in another. Set a rule for who may promote a label such as production, and confirm that your chosen platform's role model supports that separation without an enterprise key.
Questions teams ask before moving prompt management
What drives the cost of self-hosting prompt management instead of using LangSmith?
The main cost is the infrastructure and the people who run it, not a per-seat license. A self-hosted Langfuse deployment runs Langfuse Web, Langfuse Worker, PostgreSQL, ClickHouse, Redis or Valkey, and S3-compatible blob storage, so your cloud or data center bill covers compute and storage for each of them. Langfuse's 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 grow with prompt count, trace volume, retention and the number of SDK integrations that need changes. Ask any partner for a quote that splits one-time work (migration, SDK changes, hardening) from recurring work (hosting, upgrades, support).
Can our engineers move prompts to self-hosted Langfuse without outside help?
Yes, a team with Kubernetes and database experience can run the platform alone, and the Langfuse self-hosting docs cover Docker Compose for testing and Helm or Terraform for production on AWS, Azure and GCP. The harder parts are sizing ClickHouse, planning upgrades and wiring prompt retrieval into each application. Langfuse says updates within a major version are non-disruptive and apply database migrations automatically at startup, while major upgrades such as v3 to v4 follow dedicated migration guides that require ClickHouse 25.12 or later, PostgreSQL 15 or later and Redis 7.0 or later. Teams without that operations capacity often bring in an implementation partner. DeployOpen plans, implements, hardens, backs up and upgrades self-hosted platforms in your own infrastructure under a written, fixed scope.
How long does a prompt management migration take?
The duration depends mostly on how many prompts you have, how many applications fetch them, and how much history you need to keep. Each application that retrieves prompts from LangSmith needs an SDK change and a test, so an estimate built from the list of integrations is more reliable than one built from prompt count alone. No researched duration is available for this migration, so ask for a timeline in the written scope and confirm which prompts, environments and integrations it covers. Ask the vendor or partner to list the dependencies that could extend the schedule, such as cluster provisioning, approval of network access and the upgrade path for ClickHouse.
Which Langfuse Enterprise features need a license key?
Langfuse states that all core features and APIs are available in the MIT-licensed open source version without limits. Self-hosted features that need an Enterprise license key include 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. For prompt management, protected prompt labels matter most, because they restrict who can change the label that production applications fetch. Confirm with Langfuse which of these you need before you plan access control, since a missing key changes the governance design.
Do we need a Langfuse Enterprise plan to self-host prompt management?
No, the core prompt management features, including versions, labels, client-side caching and linking prompts to traces, are part of the open source version. The Enterprise plan is needed only for the features listed by the license key documentation, such as protected labels or SCIM. Langfuse's self-hosted pricing page lists a free open source plan and a custom-priced Self-Hosted Enterprise plan that adds a named support engineer, solutions architect access and a support SLA. Whether you need that support is a decision about your operating model, so compare it against your internal on-call capacity before committing.
What should a quote for this migration include?
A useful quote lists every component and every recurring item in writing before work starts. Ask for the scope of prompts, environments, SDK integrations and trace links to be migrated, the sizing assumptions for web, worker, PostgreSQL, ClickHouse and Redis or Valkey, and the blob storage and backup design. Include the cost of the upgrade path you expect over the next year, the testing approach that proves prompt versions still link to traces, and the handover documentation. Also ask who pays for each cloud resource, whether a Langfuse Enterprise key is included, and which support hours are recurring. DeployOpen does not publish a price list, so a quote follows from the written scope.
How do we keep prompt regressions visible after the move?
Keep prompt versions linked to traces from the first day in production, so you can compare performance by version after each change. Langfuse links prompts to traces and lets you analyze performance by prompt version, and the SDK caches prompts client-side so retrieval adds no latency. Use labels for environments, such as a staging label and a production label, and promote a version only after a test run shows no drop in your key metrics. Confirm during planning that every application sends the prompt identifier and version with its traces, because a trace without that link cannot show a regression.
Is Opik a better fit than Langfuse for prompt management?
Opik is a valid option when you need the whole platform, including prompt management, evaluations and tracing, under the Apache-2.0 license without a commercial key. Its README states that the full platform can be self-hosted without a commercial license, and it offers a prompt library and playground. Opik runs on ClickHouse, MySQL and Redis, so the operational stack differs from Langfuse's PostgreSQL-based design. Compare the two on the prompt features your teams use daily and on the infrastructure your operations team already runs, then confirm the choice in a written scope.
What the self-hosted prompt platform costs to run
Running self-hosted Langfuse for prompt management means paying for infrastructure, for the people who operate it, and optionally for an Enterprise license key. The minimum figures in the Langfuse scaling guide are 2 CPU and 4 GiB each for Langfuse Web, Langfuse Worker and PostgreSQL, 1 CPU and 1.5 GiB for Redis or Valkey, and 2 CPU and 8 GiB for ClickHouse, with at least 16 GiB of ClickHouse memory for larger deployments. These are floors, not sizing advice. Your infrastructure bill is driven mostly by ClickHouse memory and disk, which grow with trace volume and retention, and by blob storage for uploads and exports. Ask your platform team to price these as recurring cloud or hardware costs, and ask whether your Kubernetes cluster already carries the Helm operations and monitoring overhead.
The one-time costs are the initial deployment, the prompt migration and the rebuilding of integrations. Moving prompts is small, but the Langfuse self-hosting documentation describes a dependency set of PostgreSQL, ClickHouse, Redis or Valkey and S3-compatible storage that your team must provision, secure and back up before go-live. If you backfill historic data into ClickHouse, the Langfuse v3 to v4 upgrade guide advises about 3x ClickHouse disk headroom, so budget temporary storage for the backfill window, then release it. Major upgrades are also a repeating cost: the guide requires ClickHouse 25.12 or later, PostgreSQL 15 or later and Redis 7.0 or later, so plan for version changes on each major release. Minor updates within a major version apply migrations at startup, but they still need a tested rollback path.
The recurring costs are infrastructure, upgrades, backups, monitoring and staff time, and the largest is usually staff time. Someone owns the Kubernetes deployment, the database patching, the ClickHouse retention settings and the on-call rota. An Enterprise license key adds a subscription with features such as protected prompt labels, project-level RBAC and audit logs, and its pricing is custom. The Langfuse self-hosted pricing page describes the Enterprise plan as adding a named support engineer and a support SLA, but it does not publish a price, so request a written quote. Before you decide, confirm which features your governance model needs, because protected labels are the control most relevant to prompt changes in production.
Trade-offs that change the decision
Moving prompt management off LangSmith changes more than the interface. The upgrade path, the release pace, the features locked behind keys and the evaluators you must rebuild all affect how much work the move becomes. Each card below names one risk and one check to make before committing.
Langfuse v4 infrastructure floor
Langfuse's v3 to v4 guide requires ClickHouse 25.12 or later, PostgreSQL 15 or later and Redis 7.0 or later, and moves to an observations-first ClickHouse data model. If your existing ClickHouse, PostgreSQL or Redis versions sit below these floors, the upgrade becomes a platform project. Check your current versions against the guide before you choose a target release.
Backfill needs spare disk
The v3 to v4 guide advises about 3x ClickHouse disk headroom when backfilling historic data. Teams that plan the migration around current disk usage can run out of space mid-backfill, which stalls both the upgrade and live ingestion. Size the ClickHouse volume for the backfill window before you start, not after.
Opik release cadence
Opik publishes releases frequently, and the latest release on the GitHub releases page at the time of research was 2.2.103, published October 16, 2026. Frequent releases mean your team must set a pinned version, a test environment and an upgrade schedule rather than tracking the main branch. Confirm which release you will pin and who owns each upgrade.
Prompt governance behind enterprise keys
Self-hosted Langfuse reserves protected prompt labels, project-level RBAC, audit logs and server-side data masking for an Enterprise license key. A team that depends on locking production prompt labels or proving who changed a prompt may find that the open tier does not cover the control. Map each governance requirement to a feature in the open tier before you commit to the migration.
Evaluators must be rebuilt
Prompt versions and deployment labels move with the prompt library, but LangSmith evaluators, online rules and annotation queues do not carry over automatically. Without a plan, a prompt change can ship while the regression check that used to run against it is silently missing. Inventory every LangSmith evaluator tied to a prompt and assign it a replacement before cutover.
Trace links must survive the move
Langfuse links prompts to traces so you can compare performance by prompt version, but only traces instrumented with the new SDK carry that link. Historical LangSmith traces keep their old identifiers, so comparisons across the cutover can show a gap that looks like a quality change. Test that a new prompt version appears on a live trace in your staging project before you retire the LangSmith hub.
How to scope a pilot before committing
A short, written pilot tests whether self-hosted prompt management keeps prompt versions linked to traces and catches regressions before any production traffic moves. Each step ends with an output your team can review, and scope, deliverables and timelines are agreed in writing before work starts.
Agree the pilot scope in writing
Your team and DeployOpen agree in writing on one application, the handful of prompts it uses, the platform under test (Langfuse or Opik), the environment where it runs, and the deliverables. Named owners from engineering, security and the prompt authors sign off, and timelines are fixed in the same document before any work starts. The step is done when the signed scope lists what is in and out of the pilot.
Deploy the platform in your environment
The platform is installed inside your own cloud account, data center or private network, using the supported deployment path for the pilot, such as Docker Compose on a single VM for testing. Pilot deployments carry no high availability, so the pilot environment is not a production design. The step closes when the web UI and API respond, and the storage dependencies (PostgreSQL, ClickHouse, Redis or Valkey, and S3-compatible storage for Langfuse) are confirmed reachable from the application host.
Import the chosen prompts as versions
The selected prompts are moved into the platform's prompt management, with each change stored as a version. Prompts are tagged with deployment labels such as staging and production, and the team confirms which labels the application will request. Export the current prompts from LangSmith's prompt hub first so the original text is preserved. The step is done when each pilot prompt has a version history and a label that matches the environment it will serve.
Switch the application to fetch prompts from the platform
The application's SDK is changed to retrieve prompts by label, with client-side caching enabled so retrieval adds no latency at request time. Your team checks that the application falls back to a known-good version if the platform is unreachable. The step is done when a test request returns the expected prompt text and the calls appear in the platform's logs.
Run parallel tracing against LangSmith
The application sends traces to the self-hosted platform while LangSmith continues to receive them, so both systems record the same requests. The team compares trace counts, token usage, latency and the prompt version attached to each trace. Differences in how the two tools count tokens or group steps are written down so they are not mistaken for regressions. The step closes when a sample of traces from both systems matches on the fields that matter for the pilot.
Check prompt versions against regressions
A fixed set of test inputs is run against the previous prompt version and the candidate version, and the outputs are scored with the criteria your team agrees in advance. Each result is linked to its prompt version so the platform can show performance by version. The step is done when the team can state, for each pilot prompt, whether the candidate version passed or failed, and the evidence is stored with the scope document.
Review results and plan the production rollout
The pilot results, including gaps, licensing questions and any features that need an enterprise license key, are reviewed by security, platform and the prompt owners. Decisions are recorded: which prompts move next, which features stay on LangSmith during transition, and what the production deployment, backup and upgrade plan must include. Ask for a written quote based on this scope before any production work is committed. The step is done when the go or no-go decision and the rollout scope are signed.
Official sources for prompt management and self-hosting
Start with the Langfuse prompt management overview, because it defines the mechanics your migration depends on: prompts stored centrally, versioned, moved between environments with labels, cached client-side in the SDK, and linked to traces so you can compare performance by prompt version. Read it alongside the Langfuse self-hosting documentation, which covers the Docker Compose and Kubernetes paths, the dependencies (PostgreSQL, ClickHouse, Redis or Valkey, and S3-compatible storage), and the two application containers you will operate. Confirm with your own platform team which deployment path matches your availability needs, since the Compose option is documented for testing without high availability.
Before you commit to a feature, check the license boundary in the Langfuse LICENSE file and the Langfuse license key documentation. The MIT license covers code outside the ee directories, and the key documentation lists which features need an Enterprise key, including protected prompt labels and project-level RBAC roles. If your change control depends on protected labels, ask Langfuse in writing whether that feature is in scope for your deployment, and record the answer before you migrate. For Opik, the Opik GitHub repository and its Apache-2.0 license state that the full platform, including prompt management and its playground, can be self-hosted without a commercial license. Ask Comet to confirm the same in writing for the release you plan to deploy.
Plan upgrades before you go live, not after. The Langfuse upgrade guide explains that updates within a major version apply database migrations at startup, while major versions require dedicated migration 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. Use the Langfuse scaling guide to size the stack for your prompt and trace volume, and schedule a staging upgrade rehearsal so your prompt labels and trace links survive the version change.
How DeployOpen scopes and delivers prompt management replacement
DeployOpen plans, implements, integrates, hardens, backs up, documents and supports self-hosted open-source platforms inside the client's own infrastructure. For LangSmith prompt management, that means moving prompt versions, deployment labels and trace linkage onto a platform such as self-hosted Langfuse or Opik, in your cloud account or data center.
How we scope
- Inventory every LangSmith prompt, version, playground use and consuming service before choosing a target platform.
- Agree in writing which environments, labels and SDK caching behavior the new prompt store must support.
- Engagements are fixed-scope, with deliverables and timelines confirmed in writing before any work starts.
How we build
- Deploy the chosen platform in your infrastructure, with its database, cache and blob storage components sized to your scope.
- Rebuild prompt labels and SDK retrieval so production services fetch the same versions they used on LangSmith.
- Test trace-to-prompt-version linkage and run regression checks before any service is switched over.
How we hand over
- Document the prompt workflow, label conventions, rollback steps and the mapping from old LangSmith prompts to new versions.
- Walk your engineering and platform teams through deploying prompt changes and reading performance by prompt version.
- Deliver configuration, runbooks and test evidence so your team can operate the platform after handover.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Ask whether your scope includes upgrade planning for major Langfuse or Opik releases, and who owns that work.
- Confirm with DeployOpen which enterprise features, such as protected labels or SSO, your scope needs and who pays for any license keys.
