Migrate from Langfuse Cloud to self-hosted Langfuse without losing history
Langfuse documents this move in a data migration cookbook that includes Python scripts for transferring traces, prompts and datasets from Langfuse Cloud to a self-hosted instance. The effort depends on three things: the Langfuse versions on each side, the retention settings applied to your Cloud project, and which Enterprise features your team uses. The self-hosted code is the same codebase that runs Langfuse Cloud, and the core features and APIs are available under the MIT license without limits. The enterprise directories (ee/, web/src/ee/ and worker/src/ee/) fall under a separate license, so that license applies only to the features that live there. Start by listing those three inputs, because they decide which steps apply to you.
The migration has three parts. The first is planning: choosing the target deployment, sizing its components, and deciding which history moves and what stays in Cloud during cutover. A self-hosted Langfuse runs Langfuse Web and Langfuse Worker alongside PostgreSQL, ClickHouse, Redis or Valkey, and S3-compatible blob storage, so the plan has to cover every store that will hold migrated data. The second is data transfer, where the cookbook scripts move traces, prompts and datasets between the two instances. The third is repointing applications. Every service that sends traces or reads prompts needs its Langfuse host and API keys changed to the new instance. Plan this part early, because it touches code, pipelines and configuration that often belong to several teams.
Settle the versions before anything else. Langfuse Cloud deploys continuously and can run ahead of the latest self-hosted release, so a feature your team uses on Cloud may not yet ship in the version you plan to self-host. Check the target self-hosted version against every feature and SDK in use, and check the SDK versions your applications pin, since newer SDK majors require a minimum Langfuse version. Langfuse's versioning documentation describes the supported combinations. Confirm the target version with Langfuse before you size infrastructure, and treat any later major upgrade of the new deployment as a separate project with its own data model changes.
Retention and Enterprise features shape the scope as much as versions do. Retention policies, project-level RBAC, protected prompt labels, audit logs, server-side data masking and UI customization need an Enterprise license key on a self-hosted instance. List which of these your Cloud organization uses today, and which ones your security or compliance team will require on the first day. Then compare the retention configuration on Cloud with the one you intend to run, because history that Cloud settings kept may not map cleanly onto the target instance without a decision. Ask Langfuse to confirm how each setting carries over before the scripts run against production data.
Use these inputs to write the scope that a quote depends on. Include the Cloud projects and data types to migrate, the approximate volume of history in each, the target deployment model, the applications to repoint, the cutover window, and the validation you will accept, such as comparing trace counts and sampled prompt versions between the two instances. State who owns each step on your side, because the migration needs your application owners and security team as much as it needs the scripts. DeployOpen does not publish a price list. The quote follows from that written scope.
What maps cleanly from Langfuse Cloud and what needs a decision
This table compares each Langfuse Cloud capability with its self-hosted equivalent and the step it needs. Read the last column for what to decide or verify before cutover. Core features are available without a license key, but Enterprise features and SSO need a license or a rebuild, and Cloud can run ahead of the self-hosted release.
| Capability on Langfuse Cloud | Self-hosted Langfuse | Migration note |
|---|---|---|
| Traces and observations | Same codebase and data model, stored in ClickHouse in your infrastructure | Cookbook scripts transfer traces between instances. Confirm volume, date range and ClickHouse capacity before copying. |
| Prompts and prompt versions | Prompt management is a core feature with no license key needed | Transfer with the cookbook. In a test project, confirm which versions and labels arrive as expected. |
| Datasets | Core feature available without a license key | Migrate with the cookbook. Check dataset items and linked runs after the copy, since the script scope needs confirming. |
| Scores and evaluations | Core feature available without a license key | Confirm whether the cookbook copies scores with traces. Recreate evaluator configuration by hand if it does not. |
| Projects and organizations | Projects are core. Organization creators and the org management API need a license key | Map each Cloud project to a self-hosted project and agree the org structure before the first copy. |
| API keys and SDK configuration | Keys are issued in your instance. SDK host settings must point to your URL | Plan to issue new keys in each self-hosted project. Python SDK v5 and JS/TS SDK v6 need Langfuse v4.59.0 or later. |
| Enterprise features: project RBAC, protected prompt labels, retention policies, audit logs, masking, SCIM, instance management API | Each needs an Enterprise license key on self-hosted Langfuse | List which of these your Cloud projects use now. Settle the license decision before cutover, since retention and masking affect data handling. |
| SSO configuration | Rebuilt as Auth.js provider configuration on your instance, such as Entra ID, Okta or generic OIDC | Create each provider again and test sign-in. Enforce SSO by email domain only after testing succeeds. |
Which documented paths move the data
The documented paths split into two jobs: moving stored history into your deployment, and repointing applications that still send traces to Cloud. Each path has a different owner and failure mode, so decide which job you need before you run anything. The cards below name what each path moves and what your team must verify first.
Data migration cookbook scripts
Langfuse's data migration cookbook includes Python scripts that transfer traces, prompts and datasets between Langfuse Cloud and a self-hosted instance, or between two instances. Use it to copy stored history after your target deployment is running. Before you run it, confirm which object types the scripts cover, test them against a non-production project, and check that the target instance has enough storage and ClickHouse capacity for the volume you are copying.
FAQ on migrating between instances
The Langfuse FAQ answers how data moves between Langfuse instances and is the entry point for confirming the supported direction before you pick a script. Read it alongside the cookbook, since it does not replace a test run in your environment. Before you rely on it, confirm with Langfuse how project identifiers, API keys and user accounts are handled on the target, because those decide what your applications and team must reconfigure after the move.
OpenTelemetry OTLP endpoint
Langfuse accepts OpenTelemetry traces over OTLP at its /api/public/otel endpoint, so applications instrumented with OpenTelemetry, or frameworks such as LangChain, LlamaIndex, CrewAI and AutoGen, can be pointed at your self-hosted instance. This path moves live traffic going forward, not history. Before switching, confirm the self-hosted URL and keys, run both endpoints side by side for a short window, and check that spans, attributes and trace structure arrive as expected.
Self-hosting deployment docs
The self-hosting documentation describes the components the target instance needs: Langfuse Web, Langfuse Worker, PostgreSQL, ClickHouse, Redis or Valkey, and S3-compatible blob storage. It documents Docker Compose on a single VM for testing, which has no high availability, and Kubernetes with Helm or Terraform for production on AWS, Azure and GCP. Check that the destination is sized, backed up and topped by the availability level you need before any data lands in it.
Versioning and compatibility docs
Langfuse Cloud deploys continuously and can run ahead of the latest self-hosted release, so a feature your projects use on Cloud may not yet exist on your instance. The versioning documentation explains how self-hosted releases relate to the Cloud build. Before the move, list the Cloud features in use, confirm the self-hosted version that supports them, and check SDK requirements, since Python SDK v5 and JS/TS SDK v6 need Langfuse v4.59.0 or later.
What to settle before you copy a single trace
The target Langfuse version sets everything else, so settle it before you export anything. Langfuse Cloud deploys continuously and can run ahead of the latest self-hosted release, which means a feature your team uses on Cloud may be enabled there before it ships in a self-hosted build. Check each feature in use against Langfuse's versioning and compatibility documentation, then choose a target release that carries all of them. Record the exact version number, because it determines the migration scripts, SDK versions and infrastructure you need. The latest release listed on the Langfuse GitHub releases page at the time of writing is v4.63.0, but confirm the release you deploy against on the day you start. If your applications use Python SDK v5 or JS/TS SDK v6, the target must be Langfuse v4.59.0 or later.
Retention decides how much history you carry, and therefore how much ClickHouse and blob storage you must provision and back up. Decide whether you will move everything the source project holds, only traces inside a date window, or only current prompt versions and datasets. Ask Langfuse to confirm what history the source project actually contains before you size anything, since that figure drives the migration volume. Then decide whether the target needs retention policies. Data retention policies are an Enterprise feature that requires a license key on self-hosted Langfuse, so if you want automatic deletion from the first day, the license decision moves forward. If you plan to delete data manually or add a policy later, write that down so the target is not sized for history you will never keep.
Enterprise features in use are the third scope decision. Self-hosted Langfuse gates project-level RBAC roles, protected prompt labels, audit logs, server-side data masking, UI customization, organization creators, and the organization management API with SCIM behind an Enterprise license key. Inventory which of these your Cloud organization relies on: role assignments per project, prompt labels that only certain people may change, masking applied to trace data, and any user provisioning through SCIM. For each one, decide whether it must work at cutover, can be configured after cutover, or will be dropped on purpose with the consequence recorded. Masking and audit logs have compliance implications, so the control owners should sign off on any decision to drop them, not only the platform team.
These three answers set the data volume, the deployment shape and whether an Enterprise license is needed from day one. Full history over a long window means more ClickHouse disk. Langfuse's v3 to v4 guide advises about 3x ClickHouse disk headroom when backfilling historic data, so a version move and a backfill together multiply the storage you need. The same guide requires ClickHouse 25.12 or later (26.4 recommended), PostgreSQL 15 or later and Redis 7.0 or later. Langfuse documents Docker Compose on a single VM for testing without high availability, so a production target points toward the Kubernetes path with Helm or Terraform on AWS, Azure or GCP. Write the answers into one scope document, and have the people who own each control review it before anyone runs a copy script.
How the migration runs: inventory, pilot, parallel run and cutover
This sequence moves a Langfuse Cloud workload into a self-hosted deployment in stages that can each be checked. Inventory sets what has to move and which Enterprise features depend on it. A pilot, a parallel run and a history transfer prove the data and integrations before SDK configuration changes. The result is a self-hosted instance that receives live traffic and holds verified history, with Cloud access retired only after the checks pass.
Inventory projects, prompts, datasets and features
Your team lists every Cloud project, its prompts and labels, datasets, API keys, SSO configuration and any Enterprise features in use. Features such as protected prompt labels, data retention policies and audit logs need a license key on self-hosted, so they must be costed before the build starts. Confirm the Cloud version in use and the Langfuse version you plan to deploy, because Cloud can run ahead of the latest self-hosted release. Record trace volumes and retention needs per project. Done when the inventory is signed off and each item has a named owner.
Size and deploy the self-hosted stack
Your platform team deploys Langfuse Web, Langfuse Worker, PostgreSQL, ClickHouse, Redis or Valkey and S3-compatible storage in infrastructure you control. Docker Compose on a single VM suits testing only because it has no high availability, so production usually runs on Kubernetes with Helm or Terraform. The documented minimums are 2 CPU and 4 GiB each 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. Done when all containers are healthy and SSO sign-in works.
Pilot with a copy of a non-production project
Copy one non-production project into the new instance using the cookbook scripts. Then compare trace counts, prompt versions and dataset items against the source for the same time window. Include one prompt with several versions and one dataset with linked items, since these cases tend to expose mapping errors. Send a test trace from a sample application and confirm it displays with its scores attached. Done when counts match and any differences are documented and signed off in writing.
Run both systems in parallel over OTLP
Configure selected applications to send traces to Langfuse Cloud and to the self-hosted instance through the OTLP endpoint at /api/public/otel, so each request reaches both systems. Use a separate key for the self-hosted project so access can be revoked independently later. Compare trace counts and a sample of scores between the two systems for the same applications and time windows. Done when every gap has a known explanation, such as sampling settings, failed exports or instrumentation differences.
Transfer history with the cookbook scripts
Run the cookbook scripts for the full history in scope, covering traces, prompts and datasets. Log each run with source project, target project and item counts. Check prompt versions and labels individually, confirm dataset item counts and open a sample of dataset items. Compare a sample of scores by trace ID across both systems. Confirm ClickHouse disk capacity before large transfers. Done when each project's counts reconcile or each difference has a recorded cause.
Cut over SDK configuration and keys
Switch each application's host, public key and secret key to the self-hosted instance, one service at a time, starting with the pilot project. Confirm that installed SDK versions meet the minimum your Langfuse release requires before each switch. Store the new keys in your secrets manager and remove the Cloud keys from configuration after each service is verified. Confirm new traces appear in the self-hosted UI and that prompts are fetched from the new instance. Done when production traffic no longer reaches Cloud and the rollback steps are documented.
Decommission Cloud access after verification
After the verification period set in the plan, remove Cloud project members and revoke the remaining Cloud keys. Confirm that no service still sends to Cloud by reviewing key usage and endpoint traffic. Export a final record of the Cloud projects, prompts and datasets as evidence for your change log. Agree with your compliance lead how long any Cloud account stays open for read access to historic data. Done when the change record shows Cloud access closed and retention decisions are documented.
What drives the effort and cost of a Langfuse Cloud migration
This table lists the main drivers of effort and cost in a Langfuse Cloud migration, with what raises each one and what keeps it down. Read it before requesting a quote, because your answers set the scope of the written proposal and the infrastructure you need to provide. Each driver is worth inventorying in your own environment first, since most of the cost comes from storage, application updates and internal ownership decisions.
| Driver | What increases effort or cost | What keeps it down | Who pays |
|---|---|---|---|
| Trace history and ClickHouse headroom | Large history volume; the v3 to v4 guide advises about 3x ClickHouse disk headroom for backfill | Migrate only the date range you need and confirm disk headroom before backfill starts | Infrastructure (your cloud or data center); DeployOpen scopes the sizing |
| Projects and organizations | Each project or organization adds mapping, access setup and verification work | Agree a written project and organization mapping before the migration scripts run | DeployOpen for scoping and delivery; internal owners confirm mappings |
| Prompts and datasets | Many prompt versions, labels and large datasets lengthen transfer and checks | Archive stale datasets and remove unused prompt versions before transfer | Internal application owners decide what moves; DeployOpen runs the transfer |
| Enterprise features in use | Protected labels, project RBAC, retention, audit logs and SCIM need an Enterprise license key | List features in use early and remove any you do not need from scope | Licenses (Enterprise plan, custom-priced by Langfuse); DeployOpen for configuration |
| SSO and SCIM integration | Each identity provider, SCIM provisioning and domain enforcement adds configuration and testing | Settle one identity provider and test sign-in and provisioning before cutover | Your identity team; DeployOpen configures and tests |
| SDK versions across applications | Python SDK v5 and JS/TS SDK v6 need Langfuse v4.59.0 or later, so older applications need updates | Inventory SDK versions per application and schedule updates before cutover | Internal application owners make code changes and redeploy |
| Infrastructure ownership and Kubernetes skill | Teams without Kubernetes, ClickHouse or PostgreSQL operations experience need more build and runbook work | Reuse an existing cluster, backup tooling and staff who already run these stores | Your infrastructure budget covers hosting; DeployOpen delivery scales with the skills gap |
| Parallel run | Running Cloud and self-hosted side by side doubles ingestion checks and infrastructure for the overlap | Set a short cutover window with a documented rollback; confirm whether a parallel run is required | Infrastructure for both systems during overlap; internal teams verify output |
What usually goes wrong in a Cloud to self-hosted move and how to prevent it
Most failed moves from Langfuse Cloud trace back to decisions made late or not at all: the target version, the size of the data stores, and what the team assumed would carry over. Each card names one failure and one prevention step to settle before the first real import. Review them together with the team that owns the Cloud project and the team that will run the instance.
Target version behind Cloud features
Langfuse Cloud deploys continuously and can run ahead of the latest self-hosted release, so a feature your team uses on Cloud may not exist in the version you install. Before choosing a target, list the features, APIs and SDK calls in use on the Cloud project and check each one against the release notes for the candidate version. If a gap exists, either select a newer release or change the workflow first. Record the chosen version in the migration plan so every later decision uses it.
ClickHouse undersized for backfill
The import writes historic traces into ClickHouse, and the v4 upgrade guide advises about 3x ClickHouse disk headroom when backfilling historic data. Size the volume from the trace volume you plan to import, measured on a sample run of one project, and confirm the minimums in the scaling guide: 2 CPU and 8 GiB for ClickHouse, with at least 16 GiB of memory for larger deployments. Take and restore a test backup of that sample before the first real import.
Enterprise features assumed to be free
Core features and APIs are available in the MIT-licensed open source version, but several governance features need an Enterprise license key. These include project-level RBAC roles, protected prompt labels, data retention policies, audit logs, server-side data masking, UI customization, and the SCIM and instance management APIs. Inventory which of these your Cloud project relies on, and confirm the licensing position with Langfuse before cutover so the gap does not surface in production.
SDK versions out of step with the release
Python SDK v5 and JS/TS SDK v6 need Langfuse v4.59.0 or later. Applications pinned to older SDKs can fail against a self-hosted target, and the mismatch often appears only after traffic moves to the new instance. List the SDK version in every application and service that sends traces, plan each upgrade alongside the target release, and test ingestion from each application in staging before production traffic is redirected.
Prompts and datasets copied without versions
Prompt management depends on versions and labels, and a copy that keeps only the latest text can break applications that fetch a specific label. Before running the cookbook scripts for prompts and datasets, record the version history and labels for each prompt, then confirm the imported copy shows the same versions and labels. Check that dataset items and their links to runs are intact in staging, and keep the source project unchanged until these checks pass.
Cutover that leaves Cloud settings behind
Two items often survive cutover unchanged. Sign-in is configured per instance, so the self-hosted deployment needs its own SSO connection, and users cannot sign in until it is rebuilt with the redirect URLs for your domain. Applications may also keep Cloud API keys and base URLs. Keep a list of every service that holds a Langfuse key or endpoint, and update and test each one during a scheduled cutover window.
Which self-hosted version to target and what the v4 requirements mean
Fix the target version before you size infrastructure or schedule the data copy. The Langfuse GitHub releases page lists v4.63.0, published October 16, 2026, as the latest release at the time of writing. Because Langfuse ships frequently, confirm the current release on that page when you plan, and record the exact tag you intend to deploy. The target is a release you pin, not whichever image happens to be latest when the deployment runs. The v3 to v4 upgrade guide sets the floor for your data stores. It requires ClickHouse 25.12 or later, with 26.4 recommended, PostgreSQL 15 or later, and Redis 7.0 or later. If your current self-hosted stack runs older components, those upgrades become prerequisites with their own change windows. Ask your platform team which versions are running today for ClickHouse, PostgreSQL and Redis or Valkey, and whether those versions are supported by your vendor or distribution channel. Version 4 also moves ClickHouse to an observations-first data model. Your existing trace history will be reshaped during the upgrade, and the guide advises about 3x ClickHouse disk headroom when backfilling historic data. Treat that headroom as a planning input for the target cluster, not a footnote. Confirm the disk and memory numbers with the current guide, since they affect how much storage you provision before any migrated data arrives. If you deploy with Helm and use the bundled data stores, the chart itself must move from v1 to v2 before you upgrade Langfuse to v4. Plan that chart migration as its own step, with a rollback point, because it changes how the bundled PostgreSQL, ClickHouse and Redis are deployed. Teams using external managed data stores should still review the chart values for those connections, but the bundled-store step does not apply to them. The target must also match the SDK versions your applications use. Python SDK v5 and JS/TS SDK v6 need Langfuse v4.59.0 or later, so any service on those SDKs cannot send traces to an older self-hosted target. Inventory every application, notebook and pipeline that writes traces, and note its SDK version. Keep the major upgrade planned separately from the data copy: finish and verify the upgrade on an empty or test instance first, then run the copy against the stable target.
Questions teams ask before moving from Langfuse Cloud
What does moving from Langfuse Cloud to self-hosted cost?
The move is paid for in four parts: the Langfuse license tier, the infrastructure you run, the implementation scope and your internal staff time. The open source version has no license fee for core features, since Langfuse makes those available without limits under the MIT license. Features such as RBAC roles, data retention policies and audit logs need an Enterprise license key, and Langfuse prices that plan custom. Infrastructure is the main recurring cost: web, worker, PostgreSQL, Redis or Valkey, ClickHouse and blob storage run in your cloud account or data center, so data volume and sizing drive the bill. DeployOpen does not publish a price list. A quote follows the written scope, so ask for one-time and recurring items to be listed separately, with the data volume, features in use, environments and SSO requirements stated in the scope.
How long does a migration from Langfuse Cloud take?
Duration follows the scope, and no fixed figure applies to every team, so confirm the timeline in the written scope before work starts. The main drivers are the volume of trace history you need to carry over, the number of projects, prompts and datasets, and whether you need historic traces or only traces from cutover onward. Deployment target matters: a single VM is used for testing without high availability, while production usually means Kubernetes with Helm or Terraform. SSO setup, retention decisions and sign-off from the people who own those decisions also set the pace. If the move also needs a major Langfuse upgrade, that adds a separate phase. Ask for the timeline as phases with dependencies and named decision points.
Can our team migrate Langfuse Cloud data alone using the cookbook?
Your team can move the data alone if it has engineers comfortable running Python scripts and operating the stack. Langfuse's data migration cookbook includes scripts for transferring traces, prompts and datasets between Langfuse Cloud and a self-hosted instance. The harder work surrounds those scripts: deploying and sizing the stack, configuring SSO, setting up backups, choosing retention settings, checking that record counts match and switching application endpoints at cutover. Test the scripts on a non-production instance first, and confirm that the cookbook matches the Langfuse version you deploy. A partner adds implementation capacity and a written scope with deliverables, which helps when those tasks cannot be staffed internally during the migration window.
What does a Langfuse migration require from our team?
Name four owners before the work starts. The applications owner knows which services send traces, which SDK versions they use and which endpoints must change at cutover. The SSO owner manages the identity provider and the sign-in configuration, including whether password sign-in is disabled or SSO is enforced for specific email domains. The infrastructure owner provides the cloud accounts or servers, Kubernetes or VM access, PostgreSQL, ClickHouse, blob storage and backup targets. The sign-off owner decides how long traces, prompts and datasets are kept and approves masking and deletion settings, since retention policies need an Enterprise license key. Also plan a test window and confirm who can access the Cloud project during reconciliation.
Can traces be lost during the parallel run?
Yes, they can be lost if the cutover is not designed to prevent it, so confirm the approach in your own test before relying on it. Loss risk usually comes from three sources: traces sent to only one destination during the parallel period, ingestion paused while history is copied, and SDK retries or batching that fail to reach the new endpoint. Reduce the risk by sending traces to both instances where your applications allow it, comparing trace counts per project and time window, and keeping Langfuse Cloud access until reconciliation passes. Keep an exported record of the Cloud data until the new instance has been verified. Ask the team that writes the scope to show how the chosen copy method handles traces written during the parallel window.
Do Enterprise features need to be bought before moving?
Only the features you use need an Enterprise license key. Core features and APIs are available in the MIT-licensed open source version, and self-hosted deployments use the same codebase as Langfuse Cloud. Features that need a key include project-level RBAC roles, protected prompt labels, data retention policies, audit logs, server-side data masking, UI customization, organization creators, the organization management API with SCIM and the instance management API. Check which of these your Cloud organization uses today, because a missing key can change access or retention behavior after cutover. Langfuse's self-hosted pricing page describes the Self-Hosted Enterprise plan as custom-priced, adding a named support engineer, solutions architect access and a support SLA. Confirm the plan terms with Langfuse before the scope is signed.
Must we upgrade Langfuse to a new version during the move?
No, a version upgrade is not required by default, but the version gap decides how much risk you take on by combining the two. Langfuse Cloud can run ahead of the latest self-hosted release, so a feature you use on Cloud may not yet ship self-hosted, which you should check on the versioning and compatibility page before choosing a target. Major upgrades such as v3 to v4 change infrastructure and the data model. The v4 guide requires ClickHouse 25.12 or later (26.4 recommended), PostgreSQL 15 or later and Redis 7.0 or later, and advises about 3x ClickHouse disk headroom for backfilling historic data. Helm users with bundled data stores must upgrade the chart first. Most teams plan the move and the major upgrade as separate phases with their own change windows.
How DeployOpen scopes, delivers and supports the migration
DeployOpen plans the move from Langfuse Cloud to a self-hosted Langfuse in your own infrastructure, starting with the versions, retention settings and Enterprise features your team relies on. The data transfer follows Langfuse's documented migration cookbook, and the work is delivered as a fixed scope agreed in writing before any build begins.
How we scope
- Inventory which Langfuse Cloud projects, traces, prompts and datasets must move, and which can be left behind.
- Confirm the Langfuse version on Cloud and the self-hosted release you will run, since Cloud can run ahead of self-hosted releases.
- Identify Enterprise-licensed features in use, such as RBAC roles, protected prompt labels or data retention policies, and record the license key decision.
How we build
- Size and deploy the self-hosted stack in your infrastructure: Langfuse Web, Langfuse Worker, PostgreSQL, ClickHouse, Redis or Valkey and S3-compatible blob storage.
- Run the cookbook transfer scripts for traces, prompts and datasets, first against a test instance and then for the cutover window.
- Test migrated data with your team, checking trace counts, prompt versions, dataset items and SDK connection settings before switching applications over.
How we hand over
- Deliver written documentation of the scope, architecture, configuration, migration steps and open decisions for your team to retain.
- Walk your operators through backups, restores, retention settings and the procedure for applying updates within a major version.
- Record the cutover runbook, rollback steps and verification checks so that future changes can be made without DeployOpen.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer, scoped separately from the migration.
- Plan later major Langfuse upgrades as separate work, since they change infrastructure requirements and data models.
- Confirm with Langfuse which self-hosted support tier, if any, your organization needs alongside a DeployOpen retainer.
